Log4j and why it’s not safe to relax yet [Q&A]

The Log4j vulnerability first hit the headlines in December last year. Since then we’ve heard less about it, but it hasn’t gone away, like most vulnerabilities it has a long tail.

A recent report from the Cybersecurity Safety Review Board takes a comprehensive look at the vulnerability and what can be learned from it.

We spoke to Chainguard co-founder and CEO Dan Lorenc to find out more about the ongoing threat of Log4j and its broader implications for the security of open source software and the software supply chain.

BN: Why is Log4j still such a threat?

DL: While the report indicated that no critical infrastructure was significantly impacted by Log4j, organizations cannot overlook the potential impact that could occur in the months and years to come. It’s very possible we could see some large scale breaches, like Equifax, years from now due to unpatched shadow IT.

Based on data from Open Source Insights last month, there were 9,912 instances of unpatched Log4j remaining in the open source Java Maven ecosystem. This doesn’t mean all 9,912 instances can be exploited, but it’s a wake up call for those who aren’t using best practices and hygiene for software production and open source consumption.

BN: Do we need more focus on the software supply chain?

DL: Yes and here’s why. Software supply chain security is more than just unintended vulnerabilities like a Log4j. It’s also about continuously verifying the integrity of the software in your supply chain, which requires knowing what software you’re actually running, and where. At the center of this supply chain security evolution is the shift from trusting where the software artifacts are to trusting the artifact itself. Who published this binary? How was it built? What version of the tool was used? What source was it built from? Who signed off on this code? Was anything tampered with? These are the questions we need to be focusing on within our organizations.

BN: What role do software bills of materials (SBOMs) have to play?

DL: The Cyber Safety Review Board’s report on log4j found no instances of organizations using software bill of materials (SBOMs) to find vulnerable log4j deployments, even among organizations that already use SBOMs. This is discouraging because SBOMs offer the promise of faster vulnerability response and the finding proves that there is a lot more work that needs to be done to make SBOMs effective.

SBOMs can be valuable, but must be used carefully:

• Companies ought to focus on collecting the SBOMs that really matter, the software that is actually in production. This requires accurate asset inventory.
• Companies need to create high-quality SBOMs, preferably by using build tools that automatically generate SBOMs from source rather than unreliably recovering SBOMs from finished software products.

As an industry, we must go further and build and update tools that help ensure data interoperability so SBOMs deliver on their promise. That means industry-wide collaboration and standardization. These efforts aren’t easy but they don’t have to be deeply complex, and the result will be better and quicker remediation for the next Log4j.

BN: What are the greatest challenges to securing against these vulnerabilities?

DL: What we know from the CSRB report is that the companies that were successful in addressing Log4j had the in-house technical resources and mature processes for mitigating vulnerabilities. But that’s only a small percentage of public and private organizations impacted so how can we help the rest of the ecosystem?

Preventing another Log4j from occurring is possible, but it is going to require a fundamental shift in several critical areas. First there needs to be a groundswell of collective support in the open source community through resources and defining security standards across the industry. Second, private and public sector organizations need to have increased focus and prioritization around building security into their software development process and defining how they assess risk in the management of that software.

BN: What action do organizations need to take today?

DL: As an industry, we need to move towards building security ‘checkpoints’ and tools into the software development process — or more simply put — prioritizing security by default practices. The CSRB report calls out this direction and calls on both the open source community and commercial companies to prioritize these practices. We believe this is the future of software security and that developers and maintainers will reap the benefits of more time to build and innovate, while companies will save tremendous costs in mitigation and tools acquisition.

The Supply chain Levels for Software Artifacts framework (SLSA, pronounced ‘salsa’) can help organizations answer these questions and get the right foundations built within their organizations. SLSA currently consists of four levels and each level adds additional security requirements to help organizations and open source projects de-risk the software development lifecycle by following these guidelines across the develop, build, release cycle. The best thing about SLSA is that it’s adaptable for anyone or any project to use and it’s been designed with the wider security ecosystem in mind. As I mentioned earlier, the companies that were successful in addressing Log4j had the in-house technical resources and mature processes for mitigating vulnerabilities. The SLSA framework can be a great guide and industry standard for anyone looking to better secure a software supply chain. Implementing a smart software signing mechanism is also something companies can do today. Sigstore is a great, free tool for signing and verifying software artifacts through an easy, developer-friendly method. Sigstore can also help organizations protect software integrity as required by the SLSA and the National Institute of Standards and Technology’s Secure Software Development Framework (SSDF).

Photo Credit: Elnur / Shutterstock