One year since Log4Shell, two since SolarWinds: What’s coming in 2023?

Hopefully, this December won’t bring us another global supply chain security crisis… But then again, it might. And if it does, will companies and governments worldwide be prepared any better than before? We sat down with Invicti experts to discuss the lessons from past cybersecurity scares and look for trends going into 2023.

When software supply chain security made the headlines

Prior to the SolarWinds Orion hack, awareness of the risk and potentially massive impact of software supply chain attacks was limited to the security community. Despite its objectively modest scope, the SolarWinds incident suddenly had companies and governments nervously asking questions about the origins, composition, and security of the complicated and interconnected systems that underpin our entire technological civilization. This increased cybersecurity awareness and scrutiny – but not much more.

A year later, the topic returned with a vengeance in the form of Log4Shell and subsequent vulnerabilities in the ubiquitous Log4j library. While the SolarWinds hack was mostly someone else’s problem, few users of enterprise Java software could be confident they were safe from attacks against Log4j. Even before patching or other mitigation, the bigger issue was discovering whether you even have Log4j in your application environments. Another holiday-season fixing frenzy made everyone realize that while application development heavily relies on open-source libraries, few organizations know all the components that make up their software, and even fewer know their security status.

It was the Log4j crisis that really got the ball rolling in terms of legislation and formalized cybersecurity guidance, with Executive Orders from the Biden administration followed up by more practical recommendations from CISA. The current drive towards specific mandates around the security of software, systems, and critical infrastructure focuses on bringing visibility into software composition and defining consistent cybersecurity requirements, starting with federal organizations.

We asked Invicti experts about the origins, progress, and anticipated future directions of current initiatives as they apply to application security.

Getting to grips with software bills of materials (SBOMs)

Borrowing practices from other industries, federal guidance now includes defining and maintaining software bills of materials as a first step to knowing all the components and dependencies that make up a piece of software. “I think the SBOM is a great start,” says Invicti CTO and Head of Security Research Frank Catucci. “We need a software bill of materials, we need to know what’s in our products, we need to know what licenses we’re on, we need to know what vulnerabilities we could be exposed to.”

Even assuming your bill of materials is accurate, the next step is to define ways of using it to actually benefit security. “We have an Executive Order for anyone who does business with the federal government which says you cannot release a software product with a known vulnerability,” Catucci says. “This is step one – right now, it’s only critical and high-severity vulnerabilities, and it’s only focused on federal organizations, but I can see that mentality spread, and I think it’s going to get traction. You’re eventually going to have internal company policies or even legislation saying that if you are selling software to us and it contains a known vulnerability, we’re not going to put it in our environment.”

As with any new mandate, there is always the risk of organizations ticking boxes without addressing the underlying issue. “You have to remember that an SBOM is just a statement of compliance,” explains Mark Townsend, VP of Professional Services at Invicti. “I think SBOMs are a simple way of saying ‘I did something,’ and a lot of CISOs need to check a box that they reviewed the components and construction. What you don’t often see is people doing the next step, which is to run a penetration test or a DAST scan against it to see if it’s really securely assembled.”

The long echoes of Log4j

Despite the impression that vulnerabilities related to Log4j are a closed chapter, the popularity of the library combined with the scale and inertia of enterprise application deployments means that Log4j can still be a security headache. “Log4j is something that was any easy patch, and we had this first initial wave of people who cared and were able to respond and fix it,” explains Invicti Distinguished Architect Dan Murphy. “At Invicti, we observed this flattening curve where we saw Log4j vulnerability detections go down a hundredfold in the span of a few weeks,” he says. But because it is such a useful and innocent utility, vulnerable instances of Log4j are still out there in huge numbers. “I am now more concerned about Log4j in the dusty systems that don’t have owners, that nobody knows how they work. Log4j is on the list of the top 10 exploits that global geopolitical actors are exploiting, so I don’t think it’s done,” says Murphy.

Mark Townsend agrees but is more worried about the future: “Log4j is going to last as long as there’s unpatched software out there. More importantly, when you think about Log4j, it’s less about the current Log4j and more about the next one.” As long as ease and speed of software development take precedence over security, similar issues will be seen. “There will be another platform attack and they typically hit every 3–4 years. It’s hard to predict, but that’s the typical frequency of these types of industry-shaking events, and it’s all because of the ubiquitous use of a single platform and the very limited security mindset in the deployment,” Townsend anticipates.

Technical debt and other hidden security risks

The continued presence of exploitable Log4j vulnerabilities in public-facing systems is only one symptom of issues related to the security dark matter, including technical debt and other hidden risks. “One practice that keeps repeating itself is the fast speed at which we are spinning up systems and services. Because of this, vulnerabilities pop up in non-production environments with open ports and services running,” says Catucci. “They might by be short-lived, but it doesn’t matter – we’re not doing a good job of controlling and knowing exactly what is out there on our individual networks at any given time. The inventory and awareness of all those services, that attack surface management, is critical,” he stresses.

Dan Murphy is equally concerned about hidden attack surfaces but in the form of APIs: “Unlike with user interfaces that are tangible and might be visibly old and outdated, it’s hard for users or executives to make any value judgments about APIs. Once a vulnerable API is out and in production, nobody can see that it might be vulnerable, and it doesn’t take a masterful hacker to exploit it.” Combined with faster development, code reuse, and the reliance on existing components of uncertain quality, this is a surefire recipe for yet more security issues. “I worry that it’s the things we don’t see, and the mistakes we don’t see. As we get faster dev cycles, more churn, and code that lives beyond the attention of its original creator, I am concerned that processes today will put organizations at risk,” Murphy says.

Expecting more guidance in 2023

Given the momentum set by the Biden administration, our experts are in no doubt that once the foundations are in place, cybersecurity guidance will go far beyond SBOMs and beyond government agencies. “SBOMs are the start, the legislation for software released with high and critical vulnerabilities is the next piece of guidance, but I think that’s going to rapidly expand,” says Catucci. “Then there’s going to be further regulation or internal policy that prevents software vulnerabilities from essentially making their way into the consumer ecosystem.” According to Catucci, guidance or legislation could eventually evolve to require remediation timeframes for new vulnerabilities. “Your product is 100% vulnerability-free today, but a new vulnerability comes out tomorrow, a new Log4j – how long do you have to fix that? Are you contractually or legally bound to fix that within X amount of time? Am I now going to require SLAs from you?” Catucci asks.

Given current geopolitical instability, Dan Murphy expects legislation to prepare for future waves of cyberattacks. “We will see more global scale persistent threats from nation states,” he says. “I wouldn’t be surprised if we receive more guidance from the government as a result of that, and in a louder voice – especially if we have another Log4j – with more centralized coordination that translates into new requirements.” Overall, though, Murphy is cautiously optimistic: “Because of SolarWinds, things have been taken much more seriously, and the guidance from the government has helped communicate to decision-makers that cybersecurity is worth prioritizing.”

No more crying wolf

With the legal fallout from the SolarWinds hack continuing even now and governments worldwide issuing cybersecurity guidance, there is, at the very least, no doubt that cybersecurity is finally getting the attention it deserves. After years of security experts warning about insecure software supply chains and about critical infrastructure being vulnerable to cyberattacks, incidents such as SolarWinds, Log4j, and Colonial Pipeline (to name but a few) have proven conclusively that the security community is not crying wolf.

With that in mind, we leave you with Mark Townsend’s chilling prediction of what could happen if SBOMs become widespread but are treated as compliance checkboxes and not accompanied by systematic security testing: “I think that it’s going to take a major event to move the industry, and it will have to show that the SBOM looked great on the surface and everything looked fine, but unfortunately there was a hole – and it will need to be a significant loss event.”