A gaggle of government partners from around the world has released new guidelines for the minimum elements that organizations should include in a software bill of materials (SBOM).
The document, published this week, was authored by the US Cybersecurity and Infrastructure Security Agency (CISA) and 16 other government entities spread across four continents. It 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. This updated version was first drafted in 2025, and was then informed by suggestions from 90 commenters, including major organizations like Google, Microsoft, and Amazon Web Services (AWS) to create the resulting document.
An SBOM is essentially an “ingredients list,” detailing the building blocks and supply chains that make up a given piece of software. This could include proprietary or open source software components, APIs, utilities, and more. As a risk management tool, it aims to provide visibility into where vulnerabilities exist in a software stack and how to prioritize patching, among other things.
There’s nothing revolutionary in this latest spruced-up framework, which follows SBOM policy revisions earlier this year, but it introduces 10 new data fields, and a dozen or so updates to existing elements, which range from major to minor significance. Though the changes might be directionally positive, Jeff Williams, founder of OWASP and founder and CTO of Contrast Security, argues that these minor procedural changes miss the bigger picture.
“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. CISA should be actively seeking ways to enable vendors to make their security transparent. But unfortunately, as in most things security, the perfect is the enemy of good.”
In other news, a day after releasing its new SBOM guidance, CISA published a relevant but separate guidance concerning best practices for open source software (OSS) security.
What’s New With SBOMs
SBOMs are now to include 10 newly defined elements, such as a digital signature proving an SBOM’s integrity and authenticity, and the name and version of the tool an organization uses to generate it in the first place.
Some previously defined elements are also changing, some trivially and some meaningfully. Among the most notable changes, for instance, is a semantically vague but operationally significant replacement of the “depth” element in SBOMs with “coverage.” In short, SBOMs should now include not only the top layer of dependencies a program actively pulls from, but also those dependencies’ dependencies, with no limit to how deep the rabbit hole can go.
“The shift from ‘depth’ to broader dependency ‘coverage’ is directionally right, and capturing generation context and tool versions is useful, but I don’t expect any of it to make a significant difference,” Williams thinks, explaining that in practice, existing SBOM standards already support these “transitive dependencies,” and most SBOM tools try to capture it, as well as the generation context. “CISA is mostly writing down what the standards and tooling ecosystem already do,” he says.
What the New Guidance Is Still Missing
More than any specific new elements, revisions, or whatnot, Williams argues that there are deeper problems with the new issuance.
For example, it’s missing things. The new guidance doesn’t enshrine Vulnerability Exploitability eXchange (VEX), which is a common part of the SBOM process. VEX was developed by NTIA as a sister concept for SBOMs, to help contextualize not just whether supply chain vulnerabilities exist in a particular stack, but whether they’re actually exploitable, or otherwise uninvoked or unexposed.
On top of that, “CISA puts accuracy, completeness, and coverage assurance outside the scope of the document,” he adds. “But that’s almost the entire problem. We don’t need more agreement about which fields belong in an SBOM. We need to know whether the inventory is accurate, represents what was actually shipped or deployed, and can support a real security decision.”
Of course, there’s also the fact that CISA’s guidelines are not requirements enforceable by law. The buck lies with regulators and, more often, customers, to require that their suppliers follow best practices.
Without help from official regulation, “[organizations] have to require interoperable CycloneDX or SPDX SBOMs, establish measurable quality standards, require timely updates, and reject incomplete or unusable submissions. Most importantly, organizations would have to actually use the information in procurement, vulnerability management and incident response. Producing an SBOM can’t be treated as the security outcome.”
CISA’s Latest OSS Guidance
Central to any discussion of a software supply chain is open source software (OSS) — both the software components an organization uses directly, and those used by its vendors, and vendors of vendors. So as a spiritual follow-up to its 2026 Minimum Elements for a Software Bill of Materials, CISA released separate guidance for how to use, evaluate, and publish OSS.
Besides underscoring the importance of SBOMs and some other generally accepted best practices around OSS, the document pioneers new territory in a few respects. For one thing, it suggests that government agencies adopt a “default open source” approach for the things they develop. According to this mindset, instead of deciding whether a particular piece of custom-developed software should be open-sourced, government agencies should instead default to open-sourcing, or otherwise come up with some good reason why they shouldn’t.
CISA also takes a strict line on AI systems. It notes that AI model training data can be a source of any number of possible cyber risks, yet it’s not widely handled with the same level of transparency as, say, supply chain software components are in SBOMs.
“The guidance urges agencies to obtain sufficient transparency into all relevant components, including training data,” CISA wrote in a July 30 press release. “Only with transparency and access can agencies understand and study the software, analyze it for vulnerabilities, and remediate any found vulnerabilities or risks.”
