Start with the everyday version. A packaged food product has an ingredient list on the side of the box: what is inside, in what proportions, and which bits are the common allergens. A Software Bill of Materials (SBOM) is that ingredient list, but for software. It is a written inventory of every component that went into a piece of software — every library, every framework, every reused chunk of code — along with who made each one and which version it is.
That sounds mundane until you realise how software is actually built today. Almost no application is written from scratch. Developers assemble them mostly out of code other people wrote — open-source libraries, frameworks, and third-party packages. Open source alone makes up roughly three-quarters of the average commercial codebase — Black Duck's 2025 Open Source Security and Risk Analysis found 77% — and each of those components pulls in its own components, which pull in theirs, several layers deep. The result is that most organisations genuinely do not know everything that is inside the software they ship or run.
Why that matters became a global, sleepless-weekend problem in December 2021, when a flaw nicknamed Log4Shell was found in a tiny, ubiquitous Java logging component called Log4j. The component was buried so deep inside so many products that, for most companies, the urgent question — "Are we even affected?" — took days or weeks to answer. The ones who could answer in hours had something the others didn't: an inventory of what was inside their software. That inventory is an SBOM.
This is a reference guide written for a general reader. It explains what an SBOM is, what it actually records, the standard formats and the laws now demanding it, and — the part that is genuinely new in 2026 — what changes when the "software" is an artificial-intelligence system. Acronyms are spelled out as they appear, and there is a glossary at the end.
- An SBOM (Software Bill of Materials) is an ingredient list for software: every component inside it, its supplier, and its version.
- It exists because modern software is mostly assembled from other people's code (≈77% open source), so most teams cannot otherwise answer "is this dangerous component inside our products?" quickly.
- The US set the baseline: a 2021 government report (from NTIA, a US Department of Commerce agency) defined the seven minimum pieces of information an SBOM should record for each component.
- There are two main machine-readable formats — SPDX (from the Linux Foundation) and CycloneDX (from the security non-profit OWASP). A third, SWID, is being phased out of the recommendations.
- SBOMs are now the law, not just good practice. In the EU, the Cyber Resilience Act makes them mandatory for digital products from 11 December 2027.
- The new frontier is AI. A normal SBOM can't capture what makes an AI system risky — what model is inside, what data it was trained on, where that data came from. In 2026 the G7 nations published the first guidance on an "SBOM for AI", built around seven clusters of information.
- Big caveat: an SBOM tells you what you have, not what's exploitable. It's the foundation, not the whole answer — you pair it with a companion called VEX to know which listed components actually need action.
What an SBOM actually is
The canonical definition comes from the US government. NTIA — the National Telecommunications and Information Administration, an agency inside the US Department of Commerce — describes an SBOM as "a formal record containing the details and supply chain relationships of various components used in building software." CISA — the Cybersecurity and Infrastructure Security Agency, the US government's main cyber-defence agency — sharpens it to "a formal, machine-readable inventory of software Components and Dependencies, information about those Components, and their relationships."
In plainer words: an SBOM is the ingredient list for a piece of software — every component, who supplied it, which version, and how the pieces fit together. Crucially, it covers not just the direct dependencies a developer deliberately chose, but the transitive ones pulled in underneath them — a library that your library depends on, that its library depends on. Those buried, transitive components are exactly the part teams almost always miss, and exactly where Log4Shell was hiding.
A dependency tree
What an SBOM records per component
Dependency Relationship
How this component relates to others (the graph).
The seven NTIA minimum data fields (July 2021).
CISA adds a caveat that is easy to skip and important to keep: an SBOM's inventory "should be as comprehensive as possible and should explicitly state where relationships cannot be articulated." In other words, an SBOM is an inventory, not a guarantee of completeness — a good one tells you where its own blind spots are. We return to that below.
The NTIA minimum elements
The reference point for "what belongs in an SBOM" is NTIA's "The Minimum Elements For a Software Bill of Materials," published 12 July 2021. It was not produced in a vacuum — it was mandated by Executive Order 14028, "Improving the Nation's Cybersecurity," which President Biden signed on 12 May 2021 and whose Section 4(f) directed the Department of Commerce/NTIA to publish SBOM minimum elements within 60 days.
The minimum elements come in three interrelated categories:
| Category | What it covers |
|---|---|
| Data Fields | The baseline information recorded for each component (the seven fields below). |
| Automation Support | Machine-readable formats so SBOMs can be generated and consumed at scale — NTIA names SPDX, CycloneDX, and SWID tags. |
| Practices & Processes | The operational side: how SBOMs are requested, generated, distributed, and used. |
The seven baseline Data Fields, recorded per component, are: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers (e.g. PURL, CPE, or SWID — standardised ways to name a component so two systems agree what it is), Dependency Relationship, Author of SBOM Data, and Timestamp. These seven remain the binding US baseline today.
An SBOM's minimum requirement is modest and common-sense: for every ingredient, write down who made it, what it's called, which version, a precise ID, how it connects to the others, who compiled this list, and when. That's it. Everything else in this article builds on those seven facts.
CISA has since iterated on the framing. Its 2024 "Framing Software Component Transparency" (3rd edition, 3 September 2024) added License and Copyright Holder as baseline attributes and mapped them across formats. In August 2025 CISA released a pre-decisional draft update to the minimum elements — adding four fields (Component Hash, License, Tool Name, Generation Context), renaming "Supplier Name" to "Software Producer," dropping SWID, and naming VEX and CSAF as companion advisories. That draft is not finalised as of mid-2026, so the 2021 seven fields still govern; treat the 2025 proposals as direction of travel, not current law.
The formats: SPDX, CycloneDX, and SWID
An SBOM is only useful at scale if a machine can read it. Three formats matter, and they are not interchangeable.
The short version: SPDX (stewarded by the Linux Foundation — the non-profit behind Linux and much of the open-source world — and standardised internationally as ISO/IEC 5962:2021) grew out of software-licence bookkeeping and has the broadest, most formal recognition. CycloneDX (a flagship project of OWASP, the Open Worldwide Application Security Project, a well-known security non-profit; now also an international standard, ECMA-424) was designed for security use cases from the start. SWID tags (ISO/IEC 19770-2) are really a way to identify installed software rather than a full SBOM-authoring format — which is why CISA's 2025 draft proposes dropping them, leaving SPDX and CycloneDX as the two practical choices.
You don't need to choose a format to understand SBOMs. Think of SPDX and CycloneDX as two file formats for the same idea, the way a document can be a .docx or a .pdf. SPDX came from the licensing world; CycloneDX came from the security world. Most modern tools can produce either.
The rules that now demand SBOMs
SBOM moved from best practice to obligation in under five years, on both sides of the Atlantic.
SBOM in regulation — a timeline
In the United States, EO 14028 (2021) made SBOMs a condition of selling software to the federal government, operationalised through OMB self-attestation guidance and CISA's minimum elements. Sector regulators followed — the FDA, for example, now expects an SBOM in premarket submissions for medical devices.
In the European Union, the Cyber Resilience Act (Regulation (EU) 2024/2847) makes an SBOM a legal requirement for products with digital elements placed on the EU market. The CRA entered into force on 10 December 2024, its reporting obligations apply from 11 September 2026, and its main obligations — including the SBOM requirement in Annex I — apply from 11 December 2027. Unlike the US model, which began as a procurement condition, the CRA is broad product-market law: if you sell digital products in Europe, the SBOM obligation reaches you regardless of who your customers are.
SBOMs used to be a nice-to-have. They aren't any more. In the US, you need one to sell software to the government; for medical devices, the FDA expects one too. In Europe, from late 2027, you will need one to legally sell almost any product with software in it — a smart thermostat, an industrial sensor, a phone app. The deadline is real and it is approaching.
For organisations consuming software, this regulatory shift turns SBOMs into a procurement and third-party risk lever: you can now reasonably ask vendors for one, and increasingly you should. (We cover that programme in third-party breaches doubled — how to build a real TPRM program and supply chain security and fourth-party risk.)
The new frontier: SBOM for AI
Here is where 2026 gets interesting. An AI system is software — so a normal SBOM still applies — but the things that make an AI system risky are largely invisible to a traditional SBOM. What model is inside? What data was it trained on? Where did that data come from, and is any of it copyright-protected or personal? A list of npm packages answers none of that.
In June 2025 the G7 Cybersecurity Working Group published a shared vision for an "SBOM for AI." The concrete guidance followed: "Software Bill of Materials for AI — Minimum Elements," co-led by Italy's ACN and Germany's BSI, with Canada's CSE, France's ANSSI, the US CISA, the UK's NCSC, and Japan's NCO, in collaboration with the EU Commission — the product of joint work between August 2025 and February 2026. It is the first multilateral attempt to define AI-system documentation as its own SBOM problem.
It defines seven clusters of minimum information. The Metadata cluster describes the SBOM document itself; the other six describe the AI system and are, in the authors' words, "equally important."
SBOM for AI — the seven clusters
G7 / BSI (Germany) / ACN (Italy) minimum elements · tap any cluster
Not mandatory and not a standard — additive guidance on top of the general SBOM minimum elements.
A normal ingredient list works for a sandwich because the ingredients are visible and stable. An AI model is more like a sourdough starter: what it became depends on what you fed it over time, and you can't fully reverse-engineer that from the final loaf. So an "SBOM for AI" has to record extra things a software list never needed — which model is inside, what data it learned from, where that data came from, and whether any of it was personal or copyrighted. The seven clusters above are simply a checklist for capturing those answers.
Two things deserve emphasis.
First, the Datasets Properties cluster has no real equivalent in a traditional SBOM, and it exists precisely because the hardest questions about AI risk are about data. It asks for dataset provenance — origin, collection methods (including web crawling and commercial agreements), preprocessing, curation, labelling, and, for synthetic data, how it was generated — and dataset sensitivity: whether the data includes PII, copyright-protected, or otherwise sensitive material.
Second, this guidance is deliberately modest. It is not mandatory, not a standard, and not legislation — it is additive guidance that sits on top of the general SBOM minimum elements. It is "open for further expansion to keep pace with the rapid development of AI technology." Notably, CISA's own 2025 draft explicitly declined to add AI-specific fields to the US minimum elements, saying the discussion is still ongoing. So for now the G7 seven-cluster model is the most concrete multilateral reference available — a template, not a rulebook.
The reasons an AI-SBOM is harder than a software-SBOM are worth stating plainly, because they are structural, not temporary:
- Training-data lineage is genuinely hard. Many datasets are scraped, merged, relabelled, or synthetic. Reconstructing provenance after the fact ranges from difficult to impossible — which is exactly why the guidance makes it a first-class field rather than assuming it can be filled in.
- Model weights are opaque. You cannot read a model's risks off its weights. The guidance captures models by hash and by "open weight / open architecture / open data / open training" flags — metadata about the artifact, not an inspection of it.
- AI changes constantly. Retraining and fine-tuning mean the "version" of a deployed model moves far more often than a software release, which strains any point-in-time inventory.
- Tooling and standards are immature. SPDX 3.0.1 has an AI Profile and CycloneDX has an ML-BOM, but both are young, and the G7 guidance itself is explicitly non-binding rather than a harmonised standard. Expect movement here as the EU AI Act's transparency obligations bite.
For teams reviewing AI vendors today, the practical move is to adopt the G7 seven clusters — especially the data-provenance and sensitivity fields — as the interim baseline for AI vendor questionnaires, exactly as we recommended in Regulatory Radar — May 2026.
An SBOM is necessary, not sufficient
A final, load-bearing caveat. Having an SBOM does not mean you are secure. It tells you what you have, not what is exploitable. A modern application can easily list hundreds of components, many carrying known CVEs that are not actually reachable or exploitable in your configuration. Drowning in that noise is its own failure mode.
The companion that makes an SBOM actionable is VEX (Vulnerability Exploitability eXchange) — and the related CSAF advisory format — which lets a producer state, per vulnerability, whether a listed component is actually affected. CISA's 2025 draft names both explicitly for this reason: VEX narrows the SBOM's inventory down to the components that genuinely warrant action. An SBOM without a way to triage it is a longer to-do list, not a shorter one.
An SBOM is the foundation of software-supply-chain transparency, not the whole building. It answers "what is in here?" Pair it with exploitability data (VEX) to answer "what should I do about it?", and pair both with a real third-party risk process to answer "should I have trusted this supplier at all?"
Turning SBOMs into supplier decisions. An SBOM is only as valuable as the vendor-review process around it. Orizon's third-party risk management services help mid-market organisations build SBOM and AI-component transparency into supplier onboarding and ongoing monitoring — so the inventory becomes a decision, not a document.
Glossary
- SBOM (Software Bill of Materials) — an inventory of all the components inside a piece of software: each component's name, version, supplier, and how they connect.
- Component / dependency — a reusable piece of code (a library or package) that software is built from. A direct dependency is one a developer chose; a transitive dependency is one pulled in underneath it, automatically.
- Open source — software whose source code is publicly available and free to reuse. The majority of most modern applications.
- NTIA — the National Telecommunications and Information Administration, a US Department of Commerce agency. It defined the SBOM minimum elements in 2021.
- CISA — the Cybersecurity and Infrastructure Security Agency, the US government's lead cyber-defence agency. It maintains and updates SBOM guidance.
- EO 14028 — a 2021 US Executive Order ("Improving the Nation's Cybersecurity") that first required SBOMs for software sold to the US government.
- CRA (Cyber Resilience Act) — EU Regulation 2024/2847, which makes SBOMs and other security requirements mandatory for digital products sold in Europe, fully from 11 December 2027.
- SPDX — a standard SBOM file format from the Linux Foundation; also the international standard ISO/IEC 5962:2021.
- CycloneDX — a standard SBOM file format from the security non-profit OWASP; also the international standard ECMA-424.
- OWASP — the Open Worldwide Application Security Project, a non-profit that publishes widely-used application-security resources.
- SWID — Software Identification tags (ISO/IEC 19770-2), an older way to identify installed software; being phased out of SBOM recommendations.
- PURL / CPE — standardised naming schemes that give a component a precise, machine-readable identifier so different tools agree which component is meant.
- VEX (Vulnerability Exploitability eXchange) — a companion document to an SBOM that says, for each known vulnerability, whether a listed component is actually affected — turning a long list into an action list.
- G7 — the group of seven major economies (Canada, France, Germany, Italy, Japan, UK, US). Its cybersecurity working group published the first "SBOM for AI" guidance.
- BSI / ACN — Germany's Federal Office for Information Security (BSI) and Italy's National Cybersecurity Agency (ACN), the co-leads of the G7 "SBOM for AI" work.
- AI-SBOM — an SBOM extended for AI systems, adding clusters for the model, the training data, and related properties that a normal SBOM can't capture.
Sources
- NTIA — The Minimum Elements For a Software Bill of Materials (SBOM) (12 July 2021)
- The White House — Executive Order 14028, Improving the Nation's Cybersecurity (12 May 2021; 86 Fed. Reg. 26,633)
- CISA — Framing Software Component Transparency, 3rd Edition (3 September 2024)
- CISA — 2025 Minimum Elements for a Software Bill of Materials (draft) (August 2025, pre-decisional)
- Linux Foundation / SPDX — SPDX 3.0.1 AI Profile; SPDX 2.2.1 = ISO/IEC 5962:2021
- OWASP — CycloneDX · Ecma — ECMA-424
- European Commission — Cyber Resilience Act · Regulation (EU) 2024/2847 (EUR-Lex)
- G7 / BSI / ACN — Software Bill of Materials for AI — Minimum Elements (CISA mirror: Software Bill of Materials (AI) — Minimum Elements)
- Black Duck — 2025 Open Source Security and Risk Analysis (OSSRA) (77% of commercial codebase code is open source)
- Orizon — Third-Party Risk Management services