SBOM (Software Bill of Materials)
An SBOM (Software Bill of Materials) is the machine-readable inventory of all software components of a product, including open-source libraries. The EU Cyber Resilience Act requires it as part of the technical documentation — common formats are SPDX and CycloneDX. Like the list of ingredients on food packaging, the SBOM makes transparent what a piece of software actually contains.
What does an SBOM contain?
An SBOM inventories the constituents of a piece of software: in-house modules, purchased components and open-source libraries along with their transitive dependencies. Each component typically includes name, version, manufacturer or origin, licence information and unique identifiers. Only this level of detail makes it possible to automatically match a newly disclosed vulnerability (CVE) against your own product portfolio.
Formats: SPDX and CycloneDX
To allow SBOMs to be processed across tools, two machine-readable formats have become established:
| Format | Origin | Distinctive feature |
|---|---|---|
| SPDX | Linux Foundation | Internationally standardised as ISO/IEC 5962, historically strong in the licence compliance field |
| CycloneDX | OWASP Foundation | Designed for security use cases, widely used in vulnerability management toolchains |
Both formats fulfil the purpose of a machine-readable bill of materials — more important than the choice of format is that the SBOM is generated automatically in the build process rather than maintained by hand.
The SBOM in the Cyber Resilience Act
The CRA makes the SBOM a manufacturer obligation: Annex I Part II requires it as part of the vulnerability handling requirements, and like the rest of the technical documentation it must be retained for at least ten years after the product is placed on the market. Its real significance, however, becomes apparent with the reporting obligations that apply from 11 September 2026: whether a new CVE in a third-party component affects your own product can only be answered with clean inventories. Without machine-readable knowledge of which component is contained in which product version, even the 72-hour notification becomes a research exercise.
The SBOM in practice: a living document, not a one-off export
An SBOM that is generated once at release and then filed away loses its value with every update. In practice, automatic generation in the CI/CD pipeline has proven itself, so that every shipped product version has an up-to-date inventory. The second step is the continuous matching of SBOM components against new vulnerability reports — only this combination of inventory and vulnerability triage turns the documentation obligation into a functioning vulnerability management process.