Informa TechTarget | SearchSecurity Cybersecurity Dive InformationWeek Channel Dive Explore our brands Dark Reading Resource Library Black Hat News Omdia Cybersecurity Advertise NEWSLETTER SIGN-UP Cybersecurity Topics World The Edge DR Technology Events Resources CYBERSECURITY OPERATIONS CYBER RISK APPLICATION SECURITY СLOUD SECURITY NEWS CISA Issues Fresh SBOM Guidance. Did They Get It Right? A couple-dozen changes to SBOM fields will make them more comprehensive, but some argue that the framework lacks real risk-management improvements. Nate Nelson,Contributing Writer July 31, 2026 5 Min Read SOURCE: ERHUI1979 VIA GETTY IMAGES 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. Related:Interpol Leverages Global System to Curtail Fraud Payments There's nothing revolutionary in this latest spruced-up framework, 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. Related:Claude Mythos — Hype vs. Reality: What Security Teams Need to Know "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. Related:Red Agents vs. Blue Agents: How to Make AI Better at Defense 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." About the Author Nate Nelson Contributing Writer Nate Nelson is a journalist and award-winning scriptwriter. In addition to Dark Reading he writes for Darknet Diaries, the most popular show in cybersecurity across all media. He began his career as a freelancer, ghostwriting Forbes and CNBC op-eds for executives in tech and finance. Then he transitioned to journalism at Threatpost, where he covered cybersecurity news and trends. Throughout those years he co-created a cybersecurity podcast, Malicious Life, which in its day climbed into the Top 20 technology podcasts charts on Apple Podcasts and Spotify. He holds degrees from New York University and Bard College. As a born and bred New Yorker, he enjoys a superiority complex, but is polite enough to keep it to himself. Want more Dark Reading stories in your Google search results? ADD US NOW More Insights Industry Reports The State of Cloud Security: The Latest Challenges How Organizations Are Managing Incident Response How Enterprises Are Developing Secure Applications How Enterprises Are Harnessing Emerging Technologies in Cybersecurity Ditch the Data Center: Understanding Flexible Cloud Infrastructure Security Management Access More Research Webinars Experts Explain How to Develop a Framework for Cyber-Fraud Fusion Prevention at Machine Speed: Hunting Beyond Known Detections 0-Day to 10x Discovery: Security at the Speed of Mythos When AI Becomes an Insider: Rethinking Risk in Critical Infrastructure Governing the Agent; Identity Security in the Age of Autonomous AI More Webinars You May Also Like CYBERSECURITY OPERATIONS Hand CVE Over to the Private Sector by Brian Martin JAN 27, 2026 CYBERSECURITY OPERATIONS China Imposes One-Hour Reporting Rule for Major Cyber Incidents by Robert Lemos OCT 01, 2025 CYBERSECURITY OPERATIONS CISA, FBI, NSA Warn of Chinese 'Global Espionage System' by Alexander Culafi AUG 28, 2025 CYBERSECURITY OPERATIONS Critical Zero-Days Crack Open CyberArk Password Vaults by Nate Nelson AUG 06, 2025 Black Hat USA Coverage APPLICATION SECURITY AI Harnesses Burst With Potential Exploit Opps byRobert Lemos JUL 30, 2026 4 MIN READ APPLICATION SECURITY When AppSec Scanners Become a Supply Chain Attack Vector byEricka Chickowski JUL 29, 2026 5 MIN READ CYBERSECURITY OPERATIONS Red Agents vs. Blue Agents: How to Make AI Better at Defense byRob Wright JUL 29, 2026 5 MIN READ Want more Dark Reading stories in your Google search results? Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox. SUBSCRIBE AUG 1-6 | MANDALAY BAY, LAS VEGAS USE CODE: DARKREADING & SAVE $200 ON A BRIEFINGS PASS OR $100 ON A BUSINESS PASS The premier cybersecurity event returns. GET YOUR PASS Discover More Black Hat