Why Software Cannot Be Secured by SBOMs Alone

Actionable insights come from SBOMs plus additional information

Tim Miller

July 31, 2024

The CrowdStrike incident earlier this month caused massive IT outages across the globe. I’ve been asked “would a software bill of materials (SBOM) have helped prevent this?” The answer is “no,” but I understand why people ask. For good reason, industry and government have placed a big emphasis on creating and providing SBOMs, but this emphasis leads to people thinking SBOMs must be part of the answer to any question. When all you have is an SBOM, everything seems like a problem solved by SBOMs.

‍

SBOMs are an important part of securing your software supply chain; they tell you what components go into your stack. SBOMs are a starting point: you need SBOMs plus another data point to take action. For example, SBOMs plus CVE data will tell you what vulnerabilities you might be exposed to. SBOMs plus CVE data plus VEX data will tell you what vulnerabilities you’re actually exposed to. SBOMs help give you this information, but SBOMs alone don’t give you actionable insight.

‍

To go back to the CrowdStrike issue in particular, here’s why having an SBOM wouldn’t help. The problem wasn’t with a faulty dependency in the Falcon platform. According to CrowdStrike’s investigation, the outage came from a content update that caused a memory error when the platform tried to read it. A bug in the content validator caused tests of the flawed content to report as passing. This gets to the broader issue: your supply chain is more than just software. Alternatively: everything is software.

‍

Blank-as-code — configuration-as-code, infrastructure-as-code, etc. — is considered a DevOps best practice. This practice has improved the ability to roll out (and revert!) changes, taking the scariness out of a Friday afternoon deployment. But the “as code” model can’t stop with development and release of content. It has to extend to the sort of automated testing that we subject code-as-code to. This means subjecting your configuration changes to automated testing, staged rollouts, and so on. CrowdStrike rigorously tested their code, but the content was deemed safer and received much less testing.

‍

When you’re consuming these changes from a vendor, the same rules apply. If possible, you should roll the changes out to a small subset of systems before taking them to the entire infrastructure. Review the updates to make sure they align with your company policies and preferences. Of course, all of this relies on your vendor’s software to support this.

‍

“Treat your configuration like code” runs into a definitional problem: not every config change is a release. There’s a spectrum between “trivial configuration change” and “major configuration change”. Where you draw the line is a difficult question and depends on your specific needs and risk tolerances. Of course, it’s turtles all the way down: you need to test the tests so that a bug in the testing tool doesn’t let bad content through. Your usual risk calculus, based on probability and impact, can help guide you to decide which changes need the full release-equivalent treatment.

‍

There’s never going to be “one weird trick” or a single solution to all security problems, but leveraging a combination of tools and best practices can significantly enhance your security posture. The software supply chain space has many tools that can help. SBOM generators are important, of course, and in-toto attestations help you trust the steps that went into producing the software you use. Use verification tools like sigstore to ensure the components you get are the ones you expect (and if your providers aren’t digitally signing their artifacts, encourage them to do that). Embrace tools like GUAC that aggregate and connect the dots between disparate data sources give you actionable insights for securing your software supply chain.

‍

The CrowdStrike incident serves as a reminder that SBOMs, while essential for understanding the components of your software stack, are just the starting point. Securing your software supply chain requires integrating SBOMs with other information like CVE and VEX data to gain actionable insights. Additionally, adopting a holistic approach to configuration management and automated testing is crucial. The closer you can get to a comprehensive view of your software supply chain, the better equipped your organization is to prevent and efficiently respond.

Like what you read? Share it with others.