What an SBOM is
The definition
An SBOM (software bill of materials) is a structured, formal, machine-readable inventory of the software components contained in a product and of their relationships.
The ingredient-label analogy is useful for framing the idea and misleading beyond that: a label is static and read by eye; an SBOM changes with every build and is only valuable when processed by a machine.
The data expected per component
| Data | Why it matters |
|---|---|
| Name | Human identification |
| Version | Without a version, no correlation with a vulnerability is possible |
| Supplier or publisher | Distinguishes two components with the same name |
| Unique identifier — PURL, CPE | Enables automatic correlation |
| Cryptographic hashes | Ties the inventory to the actual artefact |
| Licence as an SPDX identifier | Legal compliance and intellectual property |
| Dependency relationships | Distinguishes direct from transitive, traces how a component got in |
| Author of the inventory and timestamp | Traceability, enforceability |
An inventory without versions or resolvable identifiers is not a usable SBOM: it is a list of names.
Uses, by audience
| Audience | What the SBOM enables |
|---|---|
| Legal | Compile the technical documentation, demonstrate licence compliance, answer customer questionnaires and investor diligence |
| Cyber / PSIRT | Answer “are you affected?” in minutes, prioritise, produce VEX statements, feed the reporting process |
| Procurement | Run supplier diligence, compare offers on a factual basis |
| Product | Track obsolescence, anticipate component end of support, arbitrate technical debt |
| Leadership | Measure portfolio exposure, track coverage metrics |
What an SBOM is not
- Not a vulnerability report. It is the input that makes one possible, by matching the inventory against databases that change daily.
- Not a licence audit. It is the data that makes one possible.
- Not proof that there is no malicious code. A component can be correctly inventoried and compromised. The SBOM answers “what is inside”, not “is it clean”.
- Not a static document. An SBOM belongs to a specific build. An SBOM “of the product”, with no version, is meaningless.
The reality test
One question tells an organisation where it stands: how long did it take you, last time, to answer “are you affected by this vulnerability, and in which shipped versions?”
- Several weeks, by email and spreadsheet: you have no usable SBOM.
- A few days, by asking each team: you generate SBOMs but do not centralise them.
- A few minutes, by running a query: the arrangement described in Generate and steer is in place.