SBOM: The Software Ingredient List
The one-paragraph answer
An SBOM (Software Bill of Materials) is a structured list of the components inside a software product: libraries, packages, dependencies, versions, and licenses. It works like an ingredient list on a food label. Federal contractors must produce SBOMs under Executive Order 14028. Enterprise buyers increasingly demand them. Common formats include SPDX, CycloneDX, and SWID.
Software supply chain attacks have exposed how little most buyers know about what is inside the software they use. When a vulnerability is discovered in a widely-used component, buyers cannot answer basic questions: do we use it, where, and how? SBOM is the answer. But producing accurate SBOMs is not trivial, and buyers who demand them without infrastructure to consume them add cost without benefit.
Every direct and transitive software component: name, version, supplier, and hash.
How components depend on each other. Which are top-level; which are transitive dependencies.
The license each component is under. Critical for buyers to assess license compatibility.
SBOMs are often paired with vulnerability data (like NVD CVEs) so buyers can immediately identify exposure.
Federal contractors must produce SBOMs. Enterprise buyers demand them. Insurance underwriters ask about them. Vendors without SBOM capability lose deals. Buyers without SBOM consumption capability cannot respond to supply chain incidents.
The academic literature on SBOM is ahead of most corporate practice, and it is unusually blunt. Two findings are worth putting in front of any executive who thinks this is a compliance formality.
“Effective data governance is important for minimizing data breach activity and mitigating bias”
That is the gap between having AI and governing it. The second finding is the one that tends to change the room.
“it remains challenging for practitioners to identify the harmful repercussions of their own systems prior to deployment”
Neither of these is a fringe position. Both come from peer-reviewed work, and both describe the condition most organisations are actually in when the question about SBOM arrives from the board, the buyer, or the regulator.
This is the sequence that works, and it is not the sequence most organisations choose. They start with the framework and work backwards toward reality. Start with reality.
Done in this order, SBOM becomes tractable. Done out of order, it becomes a document nobody uses and a control nobody exercises.
In the EU, yes, for products with digital elements. The EU Cyber Resilience Act requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies, held in technical documentation retained for at least ten years. In the US, EO 14028 requires SBOMs from federal contractors. The artifact has moved from good practice to legal obligation in both blocs.
SPDX and CycloneDX are the most widely adopted machine-readable formats. Both are supported by common toolchains.
With every software release. Old SBOMs quickly become stale.
The AI Vendor Risk Inventory™ includes SBOM evaluation as part of vendor diligence.
Many organisations now demand an SBOM in procurement, file it, and never look at it again. That is compliance theatre. The point of the artifact is operational: when a vulnerability lands in a widely used component, you should be able to answer three questions within the hour. Do we use it? Where? What is the blast radius? An organisation that collects SBOMs but has no way to query them across its estate has bought the paperwork without the capability.
A shallow SBOM lists direct dependencies. A useful one lists transitive dependencies too, because that is where the exposure hides. The components that caused the largest supply chain incidents of recent years were almost never direct dependencies of the affected product. They were three levels down, pulled in by something else, invisible to anyone reading a top-level manifest.
A machine-readable format, SPDX or CycloneDX. Regeneration on every release, not annually. Transitive depth, not just direct. License information for each component. A named contact for vulnerability questions and a committed response time. And the right to receive an updated SBOM when the vendor patches, because a stale ingredient list is worse than none: it creates the impression of visibility that does not exist.
An SBOM tells you what software is inside a product. It does not tell you what model is inside, what it was trained on, or how it behaves. For AI products you need both: the SBOM for the software supply chain and an AIBOM for the model supply chain. Both feed the same discipline, which is knowing what you have actually bought. See vendor disclosure for how the two fit together in a procurement process.
The authoritative texts and agency pages behind this summary. We keep this page current, but where a compliance decision turns on exact wording, read the source. Anything concerning SBOM that carries legal consequence should be confirmed against the enrolled text or the issuing body, not against a secondary summary, including this one.
The AI Business Enablement Audit™ measures your organization against every framework in this library, including Software Bill of Materials, and delivers a defensible governance dossier. Start or finish your audit below.
Start or finish your AI Audit →