A Sweeping Update to SBOM Guidance Falls Short of Real Risk Management Improvements
The US Cybersecurity and Infrastructure Security Agency (CISA) has released a comprehensive update to software bill of materials (SBOM) guidance, incorporating feedback from over 90 organizations, including tech giants like Google, Microsoft, and Amazon Web Services. The new framework introduces a dozen or so changes to existing elements and adds 10 new fields, aiming to make SBOMs more comprehensive and effective in managing software risks.
At its core, an SBOM is akin to an “ingredients list” for a piece of software, detailing the building blocks and supply chains that make it up. This includes proprietary or open-source components, APIs, utilities, and more. The purpose of an SBOM is to provide visibility into where vulnerabilities exist in a software stack, allowing organizations to prioritize patching and mitigate risks.
While the update is directionally positive, some experts argue that it misses the mark on real risk management improvements. Jeff Williams, founder of OWASP and Contrast Security, believes that CISA should focus on enabling vendors to make their security transparent rather than simply cataloging problems. “The perfect is the enemy of good,” he says, suggesting that procedural changes alone won’t significantly reduce actual risk.
One notable change in the new guidance is the shift from “depth” to “coverage” when it comes to SBOMs. This means that SBOMs should now include not only top-level dependencies but also their dependencies’ dependencies, with no limit to how deep the rabbit hole can go. However, Williams doubts that this change will make a significant difference in practice, as existing standards and tooling already support transitive dependencies.
Moreover, the new guidance is still missing some essential elements, such as Vulnerability Exploitability eXchange (VEX), which helps contextualize supply chain vulnerabilities and their exploitability. CISA’s failure to enshrine VEX as a standard component of SBOMs has raised concerns about the framework’s effectiveness in managing software risks.
The release of this updated guidance coincided with a separate publication from CISA on best practices for open-source software (OSS) security. While well-intentioned, these updates only scratch the surface of what’s needed to truly address software risk management.
In practical terms, organizations should be wary of treating SBOMs as a one-size-fits-all solution to their software risks. Instead, they should focus on implementing robust processes for managing vulnerabilities and prioritizing patching based on actual risk rather than simply relying on an updated framework. As Williams aptly put it, “the real measure of success isn’t how completely we catalogued the problem; it’s how effectively we reduced actual risk.”
Source: Dark Reading — 2026-07-31