SBOM Requirements Under the CRA
The CRA mandates that manufacturers identify and document all components in their products. A Software Bill of Materials (SBOM) is the primary mechanism for meeting this obligation — and it underpins your entire vulnerability management programme.
What Does the CRA Actually Require?
Annex I, Part II, Requirement 1 of the CRA states that manufacturers must identify and document components contained in the product with digital elements, 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.
Three things stand out here: the SBOM must be machine-readable, in a commonly used format, and must cover at least top-level dependencies. The CRA does not mandate a specific format — but SPDX and CycloneDX are the two dominant open standards and are widely understood to satisfy the "commonly used" criterion.
The SBOM is not just a compliance artefact — it is the foundation of vulnerability management. Without a comprehensive component inventory, you cannot reliably assess whether a newly disclosed CVE affects your product.
SPDX vs CycloneDX: Which Format Should You Use?
SPDX
ISO/IEC 5962:2021 — Linux Foundation
Originally designed for license compliance; now widely used for security. Strong ecosystem support in build tools. Available in JSON, YAML, RDF, and tag-value formats. Preferred by many government standards (NTIA, UK NCSC).
Good for: license management, regulated industries
CycloneDX
OASIS Standard — OWASP Foundation
Security-first design with strong vulnerability management and VEX support built in. Rich component metadata including PURLs for vulnerability database matching. Available in JSON and XML. Rapidly growing toolchain adoption.
Good for: vulnerability management, VEX statements
Recommendation: Use CycloneDX for security-focused SBOMs — its PURL support makes automated vulnerability matching significantly more reliable. CRAReady generates CycloneDX SBOMs from GitHub repositories and ZIP uploads. If you need to share with customers who require SPDX, most tools can convert between formats.
Minimum Required Fields
SPDX — Key Fields
- SPDXID and document creation metadata
- Package name, version, and supplier
- Package download location or source URL
- Files analyzed flag
- Package checksum (SHA-256 minimum)
- License concluded and license information from files
- Relationship types (DESCRIBES, CONTAINS, DEPENDENCY_OF)
CycloneDX — Key Fields
- Component type (library, framework, container, firmware, etc.)
- Component name, version, and publisher
- Package URL (PURL) — critical for vulnerability matching
- Component hash (SHA-256 or SHA-512)
- License expression (SPDX)
- External references (VCS, website, advisories)
- Dependencies block — explicit parent-child relationships
How Deep Should Your SBOM Go?
The CRA mandates "at least top-level dependencies" — but in practice, the most dangerous vulnerabilities often lurk in transitive dependencies (the dependencies of your dependencies). Log4Shell is the canonical example: most applications did not directly depend on Log4j, but thousands included it transitively.
Best practice is a full transitive SBOM covering all components at every depth level. Modern package managers (npm, Maven, pip, Go modules, Cargo) can enumerate transitive dependencies natively. Tools like Syft, CycloneDX CLI, and cdxgen can generate full SBOMs from source code or container images automatically.
For firmware and hardware products, the SBOM should also include open-source packages in the firmware image, kernel version, and any bundled interpreters (Python, Lua, etc.).
SBOM Maintenance Obligations
An SBOM is not a one-off exercise. The CRA requires you to keep it current throughout the product's support period. This means:
Update on every release
Regenerate the SBOM as part of your CI/CD pipeline on every production build. Stale SBOMs create blind spots in vulnerability monitoring.
Version control SBOMs
Keep historical SBOMs per product version. Market surveillance authorities may ask for the SBOM that was current when a particular version shipped.
Automate vulnerability matching
Integrate your SBOM with vulnerability feeds (NVD, OSV, EUVD). Automated matching should alert your team when a new CVE affects a component in your SBOM.
Disclose on request
The SBOM forms part of the technical file. You must provide it to market surveillance authorities on request. Many customers will also request SBOMs as part of procurement due diligence.
CRAReady automates CycloneDX SBOM generation from GitHub repositories or ZIP uploads, with version tracking and continuous vulnerability matching across NVD, EUVD, and OSV.
Need help implementing this? Try CRAReady →