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 and Microsoft, 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 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 available for free download, and the tools used to assemble everything. If a flaw turns up in one ingredient, you can quickly find every product containing it and fix it.
CISA, the US Cybersecurity and Infrastructure Security Agency, published a new version of its SBOM framework alongside 16 government partners from Europe, Asia and Oceania. We first reported the release on 29 July 2026 in "US and allies rewrite the software 'ingredients list' rulebook for 2026", and this story fills in what the critics are saying now that the full document is out.
What actually changed?
The update adds 10 new required data fields and revises roughly 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 trace those components' own ingredients too, with no floor on how far down the chain that goes.
Other additions include a digital signature, a tamper-evident seal confirming the ingredients list itself has not been altered, and a record of which tool generated it.
| 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 founder and CTO 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?
These are guidelines, not laws. No regulator can fine a company for ignoring them. Pressure must come from customers refusing to buy software that arrives without a proper ingredients list, or from future legislation making the lists mandatory.
Williams flagged two further gaps. First, the guidance leaves out VEX, short for Vulnerability Exploitability eXchange, a companion standard that answers a harder question than "is this flaw present?": whether that flaw can actually be triggered given how the software is built and deployed. Knowing a vulnerable component exists is one thing; knowing whether attackers can reach it is another. Second, the guidance explicitly places 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."
For defenders, that omission is the real story here. An SBOM that lists every ingredient but cannot confirm those ingredients match what was actually shipped offers limited protection when a SolarWinds-style attack buries malicious code inside a software update.
What about the open-source guidance published the same week?
A companion document, covered separately in "CISA Publishes Open Source Security Playbook for Federal Agencies", covers how government agencies should handle open-source software: code that anyone can read and modify freely. CISA recommends agencies treat open-sourcing their own software as the default rather than a special case. The document also flags AI training data as a supply-chain risk deserving the same transparency as software components, a genuinely new position for a federal agency.
For ordinary users, these documents are upstream policy. They shape what vendors will eventually be required to prove about their products. A stronger SBOM standard improves the odds that a dangerous hidden dependency gets spotted before it spreads.
