SBOMs under the CRA: what a software bill of materials must carry

The SBOM stops being optional

A software bill of materials — an SBOM — is a structured inventory of the software components in a product and the dependencies between them. For years it was good practice recommended by security teams and ignored by everyone under deadline pressure. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, changes that. The CRA expects a manufacturer to know and document what its products are built from, and to handle vulnerabilities on that basis — which in practice means an SBOM is no longer discretionary.

The logic is simple and hard to argue with: you cannot patch, report on, or defend a component you have not inventoried. Every downstream obligation — vulnerability handling, coordinated disclosure, incident reporting — rests on knowing what is in the product. The SBOM is that knowledge, made machine-readable.

What an SBOM has to carry

An SBOM is only useful if it is complete and identifies components precisely enough to match against vulnerability data. The core fields are stable across the common formats.

Field	What it records	Why it matters
Component name	The software unit	Human identification
Supplier / author	Who produced it	Attribution and contact for fixes
Version	Exact version string	Vulnerabilities are version-specific
Unique identifier	e.g. CPE, PURL, hash	Automated matching to vulnerability feeds
Dependency relationship	What depends on what	Transitive risk and blast radius
Licence	Applicable licence	Legal and update constraints

The two fields that do the real work are the version and the unique identifier. A vulnerability advisory names an affected version range; without an accurate version and a machine-readable identifier, matching an advisory to your product is manual, slow and error-prone — exactly what fails under the CRA's reporting clock.

Formats: SPDX and CycloneDX

Two machine-readable formats dominate. SPDX (an ISO-standardised format with strong licensing lineage) and CycloneDX (designed from the outset for security use cases) both express the fields above. The CRA does not mandate a single format, but it expects the SBOM to be usable — which in practice means one of these, not a spreadsheet. Pick one, generate it as part of the build rather than by hand, and keep it versioned alongside the software it describes.

Generating the SBOM in the build pipeline is the point most programmes miss. A hand-maintained SBOM is out of date the moment a dependency changes. An SBOM emitted automatically at build time stays true to what actually shipped, which is the only version that matters when an advisory lands.

Why automotive makes this harder

A vehicle programme is a deep supply chain. The OEM integrates components from Tier-1 suppliers, who in turn integrate from Tier-2 suppliers, and open-source components appear at every level. The CRA's expectation that you can enumerate your components collides directly with that depth: a component invisible in a supplier's bill of materials is a component you cannot patch or report on.

This is where the SBOM connects to your existing UN R155 obligations. The supply-chain flow-down that R155 already demands — requirements and evidence passing down the chain — is the same mechanism that populates a complete SBOM. If your cybersecurity interface agreements with suppliers do not require a component inventory, they leave a hole the CRA will find. Treat the SBOM requirement as one more thing to flow down, not a separate exercise.

How the SBOM drives the rest

The SBOM is not the deliverable; it is the input to everything else. When a new vulnerability is published, you query the SBOM to find every product that contains the affected component and version. That query is what makes vulnerability triage fast enough to meet the CRA's reporting windows. Without it, each new advisory triggers a manual hunt across products — untenable once the reporting obligations apply.

The same inventory supports secure-by-design decisions (you can see and reduce your dependency footprint), licensing compliance, and the technical documentation the CRA's conformity assessment expects. One well-maintained SBOM feeds several obligations at once, which is why it is worth building properly rather than assembling under pressure.

Building it once, for both regimes

The SBOM discipline the CRA demands also strengthens the R155 side of the house. The component transparency that populates an SBOM is the same transparency that supports monitoring and vulnerability management in a mature CSMS. Build the SBOM capability once — generated in the pipeline, flowed down to suppliers, queryable against vulnerability feeds — and it serves the CRA and the R155 CSMS together. See the EU CRA for automotive for how the wider obligations fit around it.

The AutoSifu view

We build the SBOM as production infrastructure, not a compliance document — generated in the build, flowed down through supplier interface agreements, and wired into vulnerability triage. Through CIRT we run one route — compliance, solutioning and CoC/VTA support — so the same component inventory feeds the CRA's reporting duties and the R155 CSMS, with the approval body in the room while the supply-chain requirements are set. That turns the SBOM from an audit headache into the thing that makes the audit fast.