Jeff Williams says the rewritten minimum elements add ten fields and a digital signature, yet still omit VEX, accuracy, and any enforcement—while a companion OSS guidance pushes open-source defaults and AI transparency.
Source material: darkreading.com
Under the new guidance, the SBOM 'depth' element becomes 'coverage,' meaning the inventory must list every transitive dependency—dependencies of dependencies—with no explicit limit on how far down the chain to go. That is, a one-layer list of direct dependencies no longer meets the federal recommendation; the document must recursively capture the full dependency tree. In practice, most SBOM tools already attempt this, and existing standards for SBOMs (like CycloneDX and SPDX) have long supported transitive dependencies. Jeff Williams, who co-founded OWASP, says the shift is directionally right but unlikely to make a significant difference, because 'CISA is mostly writing down what the standards and tooling ecosystem already do.' He also notes that the new requirement to capture generation context and tool versions is similarly useful but already common. For organizations, the practical effect is mainly on compliance: they must now confirm their SBOMs include the full transitive closure, not just the top level. However, the security benefit may be marginal, since the tooling was already capturing this information.
The revised minimum elements add 10 new data fields. Two stand out for operational transparency: a digital signature that proves an SBOM's integrity and authenticity, and the name and version of the tool used to generate the SBOM. The signature provides a cryptographic proof that the SBOM came from the claimed source and was not tampered with, while the tool version lets recipients assess the reliability of the generator. For example, a known tool with a recent version may be more trustworthy than an obscure one. These fields are useful for procurement decisions, but they remain procedural. They don't tell you whether the software is actually secure — only that the inventory was produced by a known tool and wasn't altered. Williams sees these as positive but marginal additions, unlikely to move the needle on real-world risk reduction. Buyers can request these fields in contracts and verify them, but they must still do their own security validation.
The guidance does not enshrine the Vulnerability Exploitability eXchange (VEX), a companion concept developed by NTIA to contextualize whether a known vulnerability in a software stack is actually exploitable, uninvoked, or unexposed. Without VEX, an SBOM can list a vulnerable component but offer no clue about whether an attacker can reach it. A component might carry a critical CVE that is unreachable because the vulnerable function is never called, yet the SBOM lists it, prompting unnecessary alarm. VEX would let the vendor state that the vulnerability is not exploitable in that context. Williams calls this a deeper problem, because the goal of SBOMs is to prioritize patching based on actual risk. The omission means the framework still treats inventory as an end in itself, rather than a step toward understanding exploitability in a specific deployment. Practitioners must ask for VEX separately and incorporate it into their risk assessments.
Jeff Williams points out that CISA explicitly puts accuracy, completeness, and coverage assurance outside the document's scope. "We don't need more agreement about which fields belong in an SBOM," he says. "We need to know whether the inventory is accurate, represents what was actually shipped or deployed, and can support a real security decision." Without those assurances, even a perfectly formatted SBOM can be worthless if it doesn't reflect the real build. Williams argues that the real measure of success isn't how completely you catalogued the problem, but how effectively you reduced actual risk. "The perfect is the enemy of good," he adds, suggesting the focus on field definitions distracts from the harder question of whether the data is trustworthy.
CISA's guidance is not a legally enforceable requirement. The responsibility falls on regulators and, more often, on customers who purchase software. Williams argues that organizations have to require interoperable CycloneDX or SPDX SBOMs, establish measurable quality standards, require timely updates, and reject incomplete or unusable submissions. Most importantly, they must actually use the information in procurement, vulnerability management, and incident response. Producing an SBOM can't be treated as the security outcome itself. Contracts should specify the SBOM format, the level of detail, and the deadline for delivery. Customers should refuse SBOMs that are missing required fields or list only direct dependencies. The only teeth these guidelines have come from procurement: a buyer can condition payment on the supplier delivering an SBOM that meets the stated quality bar, and can reject any submission that fails to meet it. If they fail to do so, vendors have little reason to provide accurate inventory beyond a minimal checklist.
The document was authored by CISA and 16 other government entities spread across four continents, superseding the NTIA's 2021 guidelines. First drafted in 2025, it was shaped by suggestions from 90 commenters, including Google, Microsoft, and AWS. The update introduces 10 new fields and roughly a dozen modifications to existing ones, but the changes range from major to minor and are mostly incremental. The framework is nothing revolutionary and follows SBOM policy revisions from earlier this year. CISA should be actively seeking ways to enable vendors to make their security transparent, though Williams adds that 'as in most things security, the perfect is the enemy of good.' The process drew substantial industry input, but the resulting framework remains a recommendation, not a rule.
A day after the SBOM guidance, CISA released a separate document on open source software security. It urges government agencies to adopt a 'default open source' approach for custom-developed software: open-source unless there's a good reason not to. It takes a strict line on AI systems, noting that AI model training data can introduce cyber risks and is rarely handled with the same transparency as supply chain components. CISA wrote in a July 30 press release that agencies must obtain sufficient transparency into all relevant components, including training data, to understand, study, and remediate vulnerabilities. This extends the SBOM mindset to a new and often opaque layer of the stack, particularly for AI models where training data is often proprietary and inaccessible.
Where this came from. This breakdown is based on source material published at darkreading.com. Images above are used with the credits shown beneath each one.
