← Back to Blogtechnical

SBOM Under the CRA: What You Need to Know

The CRA requires manufacturers to generate and maintain machine-readable SBOMs for all products with digital elements. This guide covers format requirements (SPDX vs CycloneDX), minimum fields, depth, and ongoing maintenance obligations.

CRAReady Team·

Why the CRA Cares About SBOMs

A Software Bill of Materials (SBOM) is a formal inventory of all software components in a product. Under the CRA, Annex I Part II requires manufacturers to "draw up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies."

The SBOM sits at the foundation of CRA compliance. Without it, you cannot reliably:

  • Identify whether a newly disclosed CVE affects your product
  • Meet the vulnerability remediation obligations in Annex I
  • Respond to Article 14 incidents with the required component-level detail
  • Demonstrate compliance to market surveillance authorities

Format Requirements

The CRA does not mandate a specific SBOM format, but requires one that is "commonly used and machine-readable." In practice, two formats dominate:

SPDX (ISO/IEC 5962:2021)

Originally designed for license compliance, SPDX is now widely used for security. It is an ISO standard, which gives it strong regulatory credibility. Available in JSON, YAML, RDF, and tag-value formats. Preferred by the US Executive Order on Cybersecurity and many government procurement frameworks.

CycloneDX (OASIS Standard)

Designed from the ground up for security use cases, CycloneDX has strong support for vulnerability management and VEX (Vulnerability Exploitability eXchange) statements. Package URLs (PURLs) are native in CycloneDX and are critical for accurate vulnerability database matching. JSON and XML formats available. Recommended for manufacturers whose primary concern is security monitoring rather than license compliance.

Minimum vs Best-Practice Depth

The CRA requires coverage of "at least top-level dependencies." However, many serious vulnerabilities — like Log4Shell — occur in transitive dependencies. Best practice is a full transitive SBOM covering all components at every depth level.

Modern tooling makes this achievable: Syft, cdxgen, CycloneDX CLI, and package-manager-specific plugins (e.g., Maven CycloneDX plugin, npm sbom) can generate comprehensive SBOMs from source code, container images, or binary artefacts.

Essential Fields

Regardless of format, each component entry should include:

  • Name and version — exact version, not a range
  • Package URL (PURL) — critical for matching against vulnerability databases like NVD and OSV
  • Supplier — the publisher or maintainer of the component
  • License — SPDX expression
  • Hash — SHA-256 minimum for integrity verification
  • Dependency relationships — explicit parent-child mapping

Maintenance Obligations

The SBOM is not a one-time document. The CRA requires it to be kept current throughout the product's support period. This means:

  • Regenerating the SBOM on every production release as part of CI/CD
  • Version-controlling SBOMs alongside product releases
  • Continuously matching SBOM components against vulnerability feeds
  • Updating the SBOM when dependencies change between releases
  • Making the SBOM available to market surveillance authorities on request

VEX: The SBOM Companion

A SBOM tells you what components are in your product. VEX (Vulnerability Exploitability eXchange) tells downstream consumers which known vulnerabilities actually affect your product and why. VEX dramatically reduces false positives in customer vulnerability scanning.

CycloneDX supports VEX natively. For CSAF-based workflows, the CSAF VEX profile is available. Publishing VEX statements alongside SBOMs is considered best practice under the CRA and is increasingly expected by enterprise customers.

Ready to assess your CRA compliance obligations?

Try the Free Applicability Checker