Operational explainer — no hostile actormedium
SBOM, the ingredient list changes: what the 2026 minimum elements contain
On 29 July 2026 CISA, together with NSA, FBI and international partners, published new minimum elements for a Software Bill of Materials. The document updates and replaces the 2021 NTIA minimum elements, incorporating more than ninety comments gathered in a public consultation. The new fields — among them the component hash algorithm, the licence, the name of the tool that generated the SBOM and the generation context — are not formalities: they are the three or four pieces of information that decide whether, on alarm day, that list helps you answer or merely exists.
The question that always lands on a Friday
An advisory drops on a library. Not a product: a library, one of those things that sit inside other things and have no desktop icon. And the question starts, always the same one: do we have it?
In most organisations the answer takes days, involves people emailing each other to find out what is inside a product they bought, and ends in an estimate. The SBOM — Software Bill of Materials — exists to turn that answer into a lookup rather than an investigation.
On 29 July 2026 CISA, together with the NSA, the FBI and international partners, published a new version of the minimum elements an SBOM should contain. The document updates and replaces the minimum elements published by the NTIA in 2021, incorporating feedback from a 2025 public consultation that drew more than ninety comments.
What changed since 2021
The framework holds: the revision preserves the core principles of the NTIA document and refreshes its content to reflect current SBOM tools and needs. The additions, though, are what change how the document is used.
It is worth understanding why these four fields matter, because at first glance they read like paperwork.
The component hash solves the most irritating problem of first-generation SBOMs: names. Two components can share a name and be different things; the same component can appear under different names in different ecosystems. The hash, together with the algorithm used to compute it, moves identification from "what it is called" to "what it is".
The licence brings into the same list a risk that usually travels on a separate track, handled by different people at a different time. Having it in one inventory means answering two different questions with a single query.
The tool name and generation context answer a question nobody used to ask and that turned out to be decisive: how much is this list worth? An SBOM produced from source analysis, one derived from build artefacts and one generated after the fact from a binary do not say the same thing, and are not equally complete. Without knowing how it was produced, the recipient cannot calibrate trust — and a list of unknown reliability produces the worst outcome of all: false assurance.
The scope widens
The point that changes most for software buyers is scope. The minimum elements in this revision apply to SBOMs for all software, including open-source software, AI software and software-as-a-service.
- 01Commercial and open-source softwarethe historical scope, confirmed
- 02Artificial intelligence componentsmodels and dependencies enter the inventory
- 03SaaSwhat you do not install is in scope too
Explicitly including AI and SaaS is the most interesting part, and the most demanding. Those are the two categories where it is easiest to lose track of what is actually in use: a model called through an API appears in no traditional software inventory, and a SaaS service is by definition a box someone else runs. Naming them in the minimum elements does not solve the problem, but it changes the contractual conversation: asking becomes legitimate.
How to use it without turning it into an endless project
A necessary caveat: this is joint guidance, not law. It does not directly bind a European company, and its value is that of a reference standard — which is exactly the kind of document that ends up, a few months later, in tender specifications and supply contracts. Better to read it now, while it is a choice, than later, when it is a customer requirement.
Three concrete uses, in increasing order of effort.
As a lens for what you already receive. If some suppliers already hand you an SBOM, compare it against the new list: hashes, licence and generation context are probably missing. You do not need to reject it — you need to know what it does not contain, and therefore which questions it cannot answer.
As a clause in new contracts. Asking for an SBOM conforming to the 2026 minimum elements is now a precisely defined request, with a public document to point at. It is far more effective than "provide documentation on software components", the kind of wording every supplier reads its own way.
As an internal inventory for the software you write. If you have a build pipeline, generating an SBOM is an automatable step. The value does not show on the day you generate it: it shows on the first Friday an advisory lands on a library and the answer to do we have it? takes two minutes instead of two days.
One last note, for honesty: an SBOM makes nothing secure. It is an inventory, and an inventory repairs nothing. It exists to shorten the time between "a problem exists" and "I know whether it affects me" — which is, in nearly every documented incident of recent months, the stretch where most time is lost.
