The SBOM the Cyber Resilience Act asks for

Annex I Part II(1) is one of the few requirements in the CRA specific enough to check mechanically. It is also one of the most widely misread, usually in the direction of doing far more work than the regulation asks.

The text

Manufacturers shall identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.

Four constraints sit in that sentence, and each answers a question people routinely get wrong.

1. How deep: top-level is the floor, not the target

“At the very least the top-level dependencies” sets a minimum. It does not cap you there, and in practice a bill of materials generated from a lockfile covers the resolved tree at no extra effort, which is strictly better evidence.

What it does mean is that a top-level dependency missing from your SBOM is a gap in the one thing the article names explicitly. That makes it the first thing worth checking.

Development dependencies

The requirement is about components contained in the product. A test runner that never ships to the user is not one of them. Including development dependencies is not wrong in the sense of being forbidden, but treating their absence as a compliance gap is wrong on the law.

The exception is real and worth knowing: if your build bundles a development dependency into the shipped artefact, it is in the product. Only your build knows that.

2. What format: machine-readable, which means a parser can read it

The regulation says “commonly used and machine-readable” and names no format. In practice that means CycloneDX or SPDX, in JSON or XML.

A dependency list in a README is not machine-readable. Neither is a PDF export, nor a spreadsheet. The test is whether a market surveillance authority's tooling can parse it without a human in the loop.

3. When: the SBOM is due before the product is placed on the market

The essential requirements of Annex I apply from 11 December 2027. The SBOM is not a document you produce when asked; it is part of what makes the product conform.

Annex VII(8) separately requires the SBOM to be part of the technical documentation, to be provided to a market surveillance authority on request. Those are two different obligations and people often collapse them into the second one, which is the more comfortable reading and the wrong one.

4. Who sees it: authorities, not necessarily the public

The CRA does not require you to publish your SBOM. It requires you to have one, and to be able to produce it. Annex II(9) covers the case where you choose to tell users where to find it.

This surprises people in both directions. You are not obliged to expose your dependency graph to the world; you are obliged to be able to hand it over on request, for the version in question, which means keeping the copy that corresponds to each release.

Three questions that decide whether yours counts

1. Does it parse? Valid CycloneDX or SPDX, not a file named like one.
2. Does it cover every top-level dependency declared in your manifest? This is the explicit floor.
3. Does it say who the manufacturer is? Supplier metadata is what connects the document to the Annex II(1) identification of the manufacturer. An SBOM that does not name its supplier documents components without documenting a product.

npx cra-ready ./your-project

What an SBOM does not do

It does not tell you whether your dependencies contain known vulnerabilities. That is Annex I Part I(2)(a), a different requirement, and it needs a vulnerability feed because the answer changes daily. Scanners such as OSV-Scanner, Dependabot, Trivy and Grype answer it, and they answer it better than a static document can.

The two are complementary. The SBOM is the inventory; the scanner is the check against it.

A summary of a regulation, written to be useful, not a substitute for reading it, and not legal advice.