SBOM
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.
This section is the technical reference for it. It is written to be read by both teams: Definition, What the CRA requires, VEX and Licensing as SBOM data need no engineering background; the others familiarity with a build chain.
Why this became a regulatory topic
The CRA did not invent the SBOM; it made an already widespread practice mandatory by writing it into the essential requirements:
Annex I, Part II, point 1 — identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.
Three phrases are decisive, and each has an operational consequence:
- “commonly used format” — in practice CycloneDX or SPDX. A spreadsheet is not one.
- “machine-readable” — JSON, XML, tag-value. A PDF is not machine-readable.
- “at the very least the top-level dependencies” — this is a legal floor, not a target. Supply chain attacks travel mostly through transitive dependencies.
The value chain, in one line
SBOM → technical documentation (Annex VII) → EU declaration of conformity (Annex V) → CE marking → the right to sell in the Union.
That is the sentence to keep on the Legal side: the SBOM is not a side deliverable for engineers, it is a constituent part of the file that yields the CE marking.
What an SBOM is not
- Not a vulnerability report. It is the data that makes one possible.
- 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 — see Supply chain risk.
The reality test
One question is enough to measure your maturity: how long did it take you, last time, to answer “are you affected by this vulnerability?” Without a centralised SBOM the answer takes weeks and rests on emails. With one it takes minutes and rests on a query.
In this section
Cross-cutting
What an SBOM is
A definition both teams can read, the minimum data expected per component, uses by audience, and what an SBOM is not.
Cross-cutting
What the CRA requires of the SBOM
The exact text, a reading of its three key phrases, the publication question, the Commission's empowerment, and the chain that leads to CE marking.
Cyber
Formats
CycloneDX and SPDX: origins, standardisation, respective strengths, comparison, and the choice of a pivot format with export to the other.
Cyber
The six types of SBOM
Design, source, build, analysed, deployed, runtime: they do not describe the same thing and are not equivalent. Which one belongs in the technical documentation.
Cyber
Quality, completeness and depth
Quality criteria for an SBOM, automated scoring, blocking thresholds in CI, transitive dependency depth, and the seven traps that produce false inventories.
Cyber
Component identifiers
PURL, CPE, SWID, hashes: why matching a component to a vulnerability is the number-one cause of false positives, and how to make it reliable.
Cross-cutting
VEX: exploitability
The mechanism that separates 'handled' from 'ignored': statuses, standardised justifications, CycloneDX, OpenVEX and CSAF implementations, and the legal value of a decision not to fix.
Legal
Licensing as SBOM data
SPDX identifiers and expressions, what an SBOM lets you compute about legal compliance, and the data quality without which none of it works.
Cyber
Signing and integrity
Why an unsigned SBOM is not evidence: signing, provenance attestations, SLSA levels, reproducible builds and the transparency log.
Legal
Distribution and confidentiality
Should you publish your SBOM? Disclosure levels, contract clauses, the confidentiality regime for information given to authorities, and the decision matrix.
Cyber
SBOM life cycle
One SBOM per build, immutable and versioned; retention aligned with the technical documentation; archiving, indexing, retrieval and version-to-version comparison.