A Long-Overdue Update: CISA Issues Fresh SBOM Guidance, But Will It Make a Difference?
The US Cybersecurity and Infrastructure Security Agency (CISA) has released new guidelines for the minimum elements that organizations should include in a software bill of materials (SBOM). This move comes after months of consultation with major players like Google, Microsoft, and Amazon Web Services (AWS), as well as input from 90 commenters. The updated guidance supersedes the National Telecommunications and Information Administration’s (NTIA) 2021 guidelines, which laid out what an SBOM had to contain as far as the US government was concerned.
At its core, a software bill of materials is like an “ingredients list” for your favorite recipe. It details the building blocks and supply chains that make up a given piece of software, including proprietary or open source components, APIs, utilities, and more. The idea behind SBOMs is to provide visibility into where vulnerabilities exist in a software stack and how to prioritize patching.
The new guidance introduces 10 new data fields and a dozen updates to existing elements. While this might seem like progress, some experts argue that the changes are minor and don’t address the bigger picture. Jeff Williams, founder of OWASP and founder and CTO of Contrast Security, believes that these procedural tweaks miss the mark. “We should rethink the outcome we’re pursuing,” he says. “The real measure of success isn’t how completely we catalogued the problem. It’s how effectively we reduced actual risk.”
One notable change is the shift from “depth” to “coverage” in SBOMs. Instead of just detailing top-level dependencies, organizations are now expected to include those dependencies’ dependencies, with no limit to how deep the rabbit hole can go. While this might seem like a significant improvement, Williams thinks it’s largely unnecessary, as existing standards and tooling already support transitive dependencies.
But what’s more concerning is what’s missing from the new guidance. Williams argues that it fails to enshrine Vulnerability Exploitability eXchange (VEX), a crucial part of the SBOM process that helps contextualize whether supply chain vulnerabilities are actually exploitable or not. This omission raises questions about the effectiveness of the new guidelines in reducing actual risk.
CISA has also published separate guidance on best practices for open source software (OSS) security, which is welcome but somewhat tangential to the main issue at hand. While the updated SBOM guidance is a step in the right direction, it’s clear that more work needs to be done to address the deeper problems with vulnerability management.
So what does this mean for organizations? For now, it’s business as usual. But it’s essential to remember that SBOMs are just one tool in the arsenal of risk management. As Williams so aptly puts it, “The perfect is the enemy of good.” Organizations should focus on making security transparent and actionable, rather than getting bogged down in procedural tweaks.
In practical terms, organizations should keep pushing for more comprehensive guidelines that address real-world vulnerabilities. They should also prioritize integrating SBOMs into their existing risk management practices, rather than treating them as a standalone exercise. By doing so, they’ll be better equipped to tackle the complex challenges of software security and stay ahead of the threats.
Source: Dark Reading — 2026-07-31