CISA Rewrites the Rules for Software Ingredients Lists. Critics Say It's Not Enough.
A 17-nation coalition has updated the global standard for tracking what goes into software. The framework is broader than its 2021 predecessor, but security experts argue it sidesteps the hardest questions.
Key points
- CISA and 16 government partners across four continents published updated minimum requirements for software bills of materials on 30 July 2025.
- The new guidance supersedes a 2021 framework from the National Telecommunications and Information Administration and adds 10 new data fields.
- Input from 90 organisations, including Google, Microsoft, and Amazon Web Services, shaped the final document.
- The guidelines are not legally enforceable; compliance depends on regulators and customers demanding them from suppliers.
- CISA published a companion document on the same week covering best practices for open-source software security.
Think of a software bill of materials, or SBOM, as the nutrition label on a food product. Instead of listing calories and vitamins, it lists every component that went into building a piece of software: off-the-shelf code borrowed from other developers, open-source libraries that anyone can download for free, and the tools used to assemble everything. The idea is that if a flaw turns up in one ingredient, you can quickly find every product that contains it and fix it.
CISA, the US Cybersecurity and Infrastructure Security Agency (the federal body responsible for protecting critical national infrastructure), published a new version of its SBOM framework this week alongside 16 government partners from Europe, Asia, and Oceania. The document replaces guidance that dated back to 2021.
What actually changed?
The update adds 10 new required data fields and revises a dozen existing ones. The most significant change replaces a concept called "depth" with "coverage." Under the old rules, a software label had to list only the top layer of borrowed components. Under the new rules, it must also list those components' own ingredients, and the ingredients of those ingredients, with no limit on how far down the chain you go.
Other additions include a digital signature, a kind of tamper-evident seal that confirms the ingredients list itself has not been altered, and a record of which tool was used to generate the list.
| Element | 2021 guidance | 2025 guidance |
|---|---|---|
| Dependency depth | Top layer only | All layers (full "coverage") |
| Digital signature | Not required | Required |
| Generation tool | Not required | Must be named and versioned |
| Transitive dependencies | Optional | Expected |
| VEX (exploitability context) | Referenced | Not formally included |
Jeff Williams, founder of the Open Worldwide Application Security Project (OWASP, a nonprofit that sets widely used security standards) and co-founder of security firm Contrast Security, told Dark Reading the changes are directionally right but miss the point. "The real measure of success isn't how completely we catalogued the problem. It's how effectively we reduced actual risk," he said.
Does the guidance have any teeth?
No. These are guidelines, not laws. No regulator can fine a company for ignoring them. Pressure has to come from customers refusing to buy software that arrives without a proper ingredients list, or from future legislation that makes the lists mandatory.
Williams flagged two further gaps. First, the guidance leaves out VEX, short for Vulnerability Exploitability eXchange, a companion standard developed to answer a harder question than "is this flaw present?". VEX answers whether that flaw can actually be triggered in the way the software is built and deployed. Knowing a vulnerable component exists is one thing; knowing whether attackers can actually reach it is another. Second, the guidance explicitly puts questions of accuracy and completeness outside its own scope. Williams's view is blunt: "We don't need more agreement about which fields belong in an SBOM. We need to know whether the inventory is accurate."
What about the open-source guidance published the same week?
A companion document, released a day later, covers how government agencies should handle open-source software, which is code that anyone can read, copy, and modify freely. CISA recommends that agencies treat open-sourcing their own software as the default choice, rather than something that needs a special reason. The document also breaks new ground by flagging AI training data as a supply-chain risk in its own right, one that deserves the same transparency as software components.
For ordinary users, these documents are upstream policy: they shape what software vendors will eventually be required to prove about their products. A stronger SBOM standard means better odds that a flaw like the one that caused the 2020 SolarWinds breach (where malicious code hidden inside a software update reached thousands of organisations) gets spotted before it spreads.
