SBOMs Under the CRA: What You Need to Know

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all software components in a product — every library, dependency, and open-source package that ships with or runs as part of your product. Under the EU Cyber Resilience Act, maintaining an SBOM is not optional: Annex I Part II explicitly requires manufacturers to identify and document components, including third-party components, as part of their vulnerability handling obligations.

What is an SBOM?

Think of an SBOM as a nutritional label for software. Just as food manufacturers must list every ingredient, software manufacturers must be able to list every component they include — and keep that list accurate as their software changes. This enables two things the CRA mandates: proactive vulnerability monitoring (you can only know if a component is vulnerable if you know you're using it) and transparent disclosure to customers and regulators.

An SBOM typically captures component name, version, license, supplier, and one or more identifiers such as CPE (Common Platform Enumeration) or PURL (Package URL). The PURL format is particularly useful for automated vulnerability correlation against databases like OSV, NVD, and the EUVD.

CycloneDX: The Right Format for CRA Compliance

Two SBOM formats are commonly used: SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Both are valid, but CycloneDX has emerged as the preferred format for CRA compliance for several reasons.

CycloneDX is designed specifically for security use cases. It supports not just software components but also hardware, firmware, services, and vulnerability data — all relevant for the "products with digital elements" scope of the CRA. Its native VEX (Vulnerability Exploitability eXchange) support means you can attach exploitability assessments directly to your SBOM. ENISA has referenced CycloneDX in its guidance on CRA implementation.

A minimal CycloneDX SBOM looks like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    { "type": "library", "name": "openssl", "version": "3.0.11" }
  ]
}

In practice, your SBOM will contain hundreds or thousands of components, each with richer metadata including PURL identifiers, license information, and supplier details.

Why Automated Generation is Essential

Manually maintaining an SBOM is not viable for any real product. Components change with every dependency update, patch release, or build configuration change. A stale SBOM is worse than no SBOM — it creates a false sense of security and potential regulatory liability if you fail to detect a vulnerability in a component you thought you weren't using.

Automated SBOM generation tools like Syft (from Anchore) scan your compiled artefact or container image and produce a complete, accurate SBOM at build time. Integrating SBOM generation into your CI/CD pipeline ensures the document is always current. The output can be stored alongside your release artefacts and automatically checked against vulnerability databases on each generation.

For CRA compliance, you should generate an SBOM for each product release, store it alongside your release documentation, update it whenever a patch is issued, and make it available to customers and regulators on request. The CRA does not currently require public SBOM disclosure, but many customers — particularly enterprise and government buyers — will request it as part of their supply chain security due diligence.

Getting Started

If you don't currently generate SBOMs, start with your highest-criticality product. Install Syft or an equivalent tool, run it against your container image or release artefact, and review the output. You'll likely discover components you didn't know were present — outdated transitive dependencies, leftover development tools, or packages pulled in by frameworks you use.

CRAReady's SBOM scanner automates this process: connect your GitHub repository, trigger a scan, and receive a CycloneDX SBOM alongside an immediate vulnerability assessment against the EUVD. Each scan is stored with its timestamp, giving you an auditable history of component changes across releases.