SBOMs and the CRA: Why a Bill of Materials Matters

A software bill of materials is the backbone of vulnerability handling — and the CRA expects you to have one.

Modern products are assembled, not written from scratch. A single device firmware can pull in hundreds of open-source libraries, each with its own version and its own stream of security fixes. When a new vulnerability is disclosed in one of those libraries, the only question that matters is: "are we affected, and where?" A software bill of materials (SBOM) is what lets you answer it in minutes instead of weeks.

What is an SBOM?

An SBOM is a structured, machine-readable inventory of the components that make up your product's software. At minimum, for each component it records things like the name, version, supplier, and a unique identifier, plus the dependency relationships between components. Think of it as the ingredients list and nutrition label for your software.

Why the CRA cares

Annex I's vulnerability-handling requirements expect manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine-readable format, at least covering the top-level dependencies. The logic is simple: you cannot manage vulnerabilities in components you do not know you have. The SBOM underpins several CRA duties at once:

Vulnerability identification — match your components against vulnerability databases to see what affects you.
Timely remediation — know exactly which products and versions need an update.
Transparency — support coordinated disclosure and give downstream users what they need.

Common SBOM formats

Two open, widely used formats dominate:

SPDX — an ISO-standardised format originally focused on licensing and components.
CycloneDX — a format designed with security and supply-chain use cases in mind.

Either can satisfy the "commonly used, machine-readable" expectation. What matters more than the choice between them is that the SBOM is accurate, complete enough, and kept up to date as the product changes.

What makes an SBOM actually useful

Generated from the build, not by hand. Produce it as part of your CI/build pipeline so it reflects what actually shipped.
Versioned with the release. Each product release should have its own SBOM you can retrieve later.
Complete on the components that carry risk. Third-party and open-source dependencies are where most disclosed vulnerabilities live.
Continuously scanned. An SBOM is only valuable if you re-check it against fresh vulnerability data over time — a component that was clean at release may be vulnerable next month.

An SBOM is a living document. The vulnerabilities in your product change even when your code does not, because the world's knowledge of those components keeps growing. Scanning on every release and on a regular schedule is what turns an SBOM from paperwork into protection.

From SBOM to action

The pattern that satisfies the CRA in practice looks like this: generate an SBOM at build → scan it against known-vulnerability data → triage what is actually exploitable or severe → remediate and ship an update → and, where a vulnerability is being actively exploited, report it to the authorities within the required deadlines. The SBOM is the first link in that chain.

ComplyCRA does the SBOM heavy lifting. Upload or generate an SBOM and ComplyCRA scans it against known-vulnerability data and exploitation status, shows you what is affected, and feeds it straight into your readiness score and reporting workflow — with all processing kept private. Open ComplyCRA →

General information, not legal advice. Refer to Annex I of Regulation (EU) 2024/2847 for the binding wording on documentation and vulnerability handling.