SBOM Requirements Under the CRA: What Manufacturers Need to Know
The CRA requires machine-readable SBOMs for every product with digital elements. This guide covers formats, required fields, depth, and ongoing maintenance obligations.
Why the CRA Mandates SBOMs
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every software component in a product. Under CRA Annex I Part II, manufacturers must draw up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.
Without an SBOM you cannot reliably identify whether a newly published CVE affects your product, meet the vulnerability remediation obligations in Annex I, respond to Article 14 incidents with the required component-level detail, or demonstrate compliance when market surveillance authorities request evidence.
Supported Formats
SPDX (ISO/IEC 5962:2021): Originally designed for license compliance, now widely adopted for security use cases. ISO status gives it strong regulatory credibility. Available in JSON, YAML, RDF, and tag-value formats.
CycloneDX (OASIS Standard): Designed from the ground up for security use cases with strong native support for vulnerability management and VEX statements. Package URLs (PURLs) are native in CycloneDX and critical for accurate vulnerability database matching. Available in JSON and XML. Recommended for manufacturers whose primary goal is security monitoring.
Depth
The CRA requires coverage of at least top-level dependencies. Many serious vulnerabilities -- Log4Shell being the canonical example -- occur in transitive dependencies. Best practice is a full transitive SBOM. Modern tooling (Syft, cdxgen, Maven CycloneDX plugin, npm sbom) makes this achievable.
Essential Fields Per Component
Name and exact version, Package URL (PURL) for vulnerability database matching, supplier, license (SPDX expression), hash (SHA-256 minimum), and explicit dependency relationships.
Maintenance Obligations
Regenerate on every production release in CI/CD, version-control alongside product releases, continuously match against vulnerability feeds using Grype or OWASP Dependency-Check, update when dependencies change, and make available to market surveillance authorities on request.
VEX
VEX (Vulnerability Exploitability eXchange) tells downstream consumers which known CVEs actually affect your product -- dramatically reducing false-positive alerts in customer vulnerability scans. CycloneDX supports VEX natively. Publishing VEX alongside SBOMs is increasingly expected by enterprise customers.
Ready to assess your CRA compliance obligations?
Try the Free Applicability Checker