SBOM under the CRA
The Cyber Resilience Act requires manufacturers to draw up a software bill of materials (SBOM) for each product in a commonly used, machine-readable format covering at least the top-level dependencies. The SBOM is part of the technical documentation and does not have to be published.
Last updated:
What the CRA requires
- Annex I Part II point 1: identify and document vulnerabilities and components, including by drawing up an SBOM.
- Machine-readable, commonly used format.
- At minimum the top-level dependencies of the product.
- Part of the technical documentation; provided to market surveillance authorities on request. Publishing it is optional.
What an SBOM contains
Typical fields per component: name, version, supplier, a unique identifier (for example a package URL), licence, a hash, and dependency relationships. Data about the SBOM itself (author, timestamp, tool) makes it traceable.
Common formats: CycloneDX and SPDX
CycloneDX (OWASP) and SPDX (Linux Foundation, ISO/IEC 5962) are the two widely used SBOM formats. Both are machine-readable and supported by many tools. The CRA does not prescribe a specific format.
BSI TR-03183-2 as guidance
The German BSI's Technical Guideline TR-03183-2 describes formal and content requirements for SBOMs, such as mandatory fields and depth. It is not binding under the CRA but is a practical reference until harmonised standards exist.
Generate in CI, not by hand
Dependencies change with every release. Generating the SBOM automatically in the build pipeline, tied to the released version, keeps it accurate and makes it reproducible for audits.
Using the SBOM for vulnerability matching
An SBOM is most useful when matched continuously against vulnerability databases. A new CVE in a transitive dependency should surface as a finding for every affected product version, feeding your vulnerability handling and, if exploited, your reporting.
How Nuowei helps
Nuowei connects to your GitHub repositories read-only and generates an SBOM per repository automatically, updated continuously as your code and dependencies change. The same inventory drives CVE and supply-chain monitoring.