Modern software consists largely of third-party components: open-source libraries, frameworks and their dependencies. When a flaw becomes known in one of them, the question is immediate: are we affected? An SBOM answers it in minutes rather than days.
What it contains
For each component: name, version, supplier or origin, licence and its dependency relationship to other components. SPDX and CycloneDX are widely used and generated directly by many build tools.
Benefits
In vulnerability management a new flaw can be matched automatically against all SBOMs. For licensing questions the SBOM shows which licences the product contains. In a tech due diligence it is quick evidence of dependency management quality.
CRA requirement
The Cyber Resilience Act requires manufacturers to draw up an SBOM covering at least the product’s top-level dependencies and include it in the technical documentation. Obligations largely apply from December 2027; reporting duties for actively exploited flaws have applied since September 2026. Anyone developing software for the EU market should add SBOM generation to the build pipeline now.
Practice
An SBOM is only useful if updated with every build and stored centrally. A document created once is outdated by the next update. Generation therefore belongs automated in the pipeline, together with a check for known flaws.
