CISA's Updated Software Ingredient List Rules Change What Knowing Your Code Actually Means

Key points

• CISA and international partners published updated 2026 Minimum Elements for an SBOM, expanding the original 2021 standard to cover open-source software, AI components, and cloud-hosted software services for the first time.
• The new guidance incorporates feedback from more than 90 public comments and adds requirements around component hashes, tool provenance, and documentation of what a software scan deliberately left out.
• Security architects writing in CSO Online warn that even a fully compliant SBOM cannot tell you what software is allowed to do, leaving permissions, AI agent access, and live deployment state invisible.
• The EU Cyber Resilience Act separately requires a machine-readable SBOM covering at least top-level dependencies from manufacturers selling products with digital components into Europe.
• Practical pilots suggest a 90-day programme covering one critical service is enough to expose dangerous gaps between what an approved architecture says and what the live system actually does.

For years, the phrase "know what's in your software" sounded simple. Then a single flaw in a widely used logging tool called Log4j sent thousands of organisations scrambling in December 2021, trying to work out whether any of their products contained it. Many could not answer that question for weeks.

The government's answer to that chaos was the Software Bill of Materials, or SBOM: a structured list of every ingredient a piece of software is built from, so that when a dangerous component is identified, you can search the label rather than tear apart the product.

CISA, the US Cybersecurity and Infrastructure Security Agency, along with international partners, published revised 2026 minimum requirements for what an SBOM must contain. The update builds on a 2021 baseline and adds meaningful new ground: for the first time, the rules explicitly cover open-source software, software run as a cloud service, and software that includes AI components. Producers must now record cryptographic hashes (unique fingerprints confirming a component has not been altered), details about which scanning tool generated the list, and what the tool could not see. That last requirement matters more than it sounds.

Why a complete ingredient list is still not enough

Knowing what is in your software does not tell you what your software can do. That gap is where real incidents live.

When a critical library flaw is disclosed, the question senior leaders actually ask isn't "how many ingredient lists have we collected?" It's: which products are affected, is the vulnerable code reachable by an attacker, which customers could be exposed, and who owns the fix? No single inventory answers all of that. The decision crosses software components, cryptographic dependencies, identity records, deployment state, and runtime evidence.

Security architects writing in CSO Online put the problem plainly: a component list describes what exists. It says nothing about what permissions that software holds, whether an AI agent running inside the product can call production databases or approve transactions without a human, or whether the version deployed to customers today still matches the version approved last quarter. We covered the operational side of this exact gap in "The Race to Answer 'Are We Exposed?' Is Getting Harder" on 17 September.

The failure mode in practice is fragmentation. One team owns the component inventory, a second owns cloud permissions in IAM, a third owns AI model records, and none share a common identifier for the same running service. When an incident hits, the evidence exists but can't be connected fast enough to matter.

The proposed fix isn't six separate programmes. It's a single shared contract: a small agreed envelope of fields that lets each specialised record point to the others, so an incident leader can follow one path through the evidence rather than make six phone calls.

Should you worry about the EU angle?

If you buy software from vendors subject to the EU Cyber Resilience Act, or from US federal contractors, the pressure to maintain accurate ingredient lists is now legal, not optional. Vendors who previously filed a rough component list and called it done face real scrutiny. Our coverage of the CRA's 24-hour vulnerability reporting requirement, published on 2 October, found that almost no one has the internal processes to move that fast. An incomplete or stale SBOM makes that problem worse.

For anyone buying software for a business, the practical question to put to your vendor isn't "do you have an SBOM?" but "how was it generated, how old is it, and what did the scanner miss?" The 2026 rules make those questions answerable. Whether vendors answer them honestly is a different matter.

The postmortem will say, every time, that the data was somewhere. The real question is whether the owners named inside the evidence graph were the right people, with the right update cadence, to surface it before the incident rather than after.