We’re glad to see the Cybersecurity Safety Review Board’s (CSRB) report on Log4j is a comprehensive and definitive review of what transpired in December 2021. The 54 pages of recommendations range from the continued risk of Log4j in organizations to how we can build a better software ecosystem.
As security leaders, developers and maintainers read this report, it is my hope that we can use it as a foundation to advance the discussion beyond Log4j to the broader security of open source software and the software supply chain.
Assessing the risk
Despite the report indicating that no critical infrastructure was significantly impacted by Log4j, it's important for the industry to not overlook the potential impact in the months and years to come. In fact, I’d predict that we're going to see some large scale breaches, like Equifax, years from now due to unpatched shadow IT.
Today, there are 9,912 instances of unpatched Log4j remaining in the open source Java Maven ecosystem (Source: Open Source Insights). Of course, that doesn’t mean all 9,912 instances can be exploited. But this is cause for concern for those who aren’t using best practices and hygiene for software production and open source consumption.
So what can we do today?
Software supply chain security is more than just unintended vulnerabilities, as bad as those are. 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 asking.
The SLSA framework can help organizations answer these questions and get the right foundations built within their organizations. Implementing a smart software signing mechanism is also something companies can do today. Sigstore is a great, free tool for this and can be easily deployed in your environment.
… and can SBOMs really help?
Software bills of materials or SBOMs offer the promise of faster vulnerability response. Despite this, the report found no instances of organizations using SBOMs to find vulnerable Log4j deployments, even among organizations that already use SBOMs. This proves that there is a lot more work that needs to be done to make SBOMs effective.
However, it's not all doom and gloom. The fact that some organizations even had SBOMs marks significant progress from where we were a year ago when very few people had even heard of an SBOM.
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, either. We can do the hard things – together. The result will be better and quicker remediation for the next Log4j.
Bring us on your supply chain security journey
Chainguard is working every day to develop tools and best practices that bake security into the development process by default, empowering developers and maintainers and supporting CISOs and their organizations as they seek to mitigate the risk of deploying vulnerable software. 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 – we still have a long road ahead. Chainguard understands that people and process are at the heart of tackling software supply chain security through automation and enforcement of organizational policies and we look forward to helping your organization on its journey.
Together, we can ensure that only secure software is eating the world.
