SBOM for the CRA: CycloneDX, SPDX, and what an auditor expects

Ask ten teams preparing for the CRA what they're working on and most will say "the SBOM." It's the visible, tangible deliverable — a file you can generate and point to. It's also the part of the CRA that is closest to solved, which makes it a strange place to spend the bulk of your effort. Worth doing well; not worth agonising over.

What the CRA actually asks for

The Cyber Resilience Act requires a manufacturer to draw up a software bill of materials in a commonly used, machine-readable format, covering at the very least the top-level dependencies of the product. It sits inside the vulnerability-handling requirements of Annex I and forms part of the technical documentation you keep on file.

Two words in that sentence matter more than the rest. Machine-readable rules out a PDF or a spreadsheet — it means a structured format a tool can parse. And top-level dependencies is the regulatory floor: the components you directly depend on, at minimum. Going deeper — full transitive dependencies — is good practice and better security, but the letter of the requirement stops at top-level. Knowing where the floor is helps you avoid treating a nice-to-have as a blocker.

The three formats: CycloneDX, SPDX, SWID

The CRA doesn't name a format. Three are commonly used and any of them satisfies "commonly used, machine-readable." They come from different worlds, which is the fastest way to choose between them.

For most manufacturers approaching the CRA, CycloneDX is the pragmatic default: it was designed for exactly this problem and it carries VEX in the same document, so your inventory and your exploitability statements live together. SPDX is trivial to export alongside when a downstream party asks. This isn't a decision to lose a week over — the formats are interconvertible enough that picking the wrong one is cheap to undo.

How to generate one (and why it's basically free)

The reason the SBOM layer can't be a business on its own is that the open-source stack already does it well, for nothing. Three tools cover almost every case:

• Syft — generates CycloneDX and SPDX from container images, filesystems and source. Fast, widely used.
• Trivy — SBOM generation plus vulnerability scanning in one tool.
• cdxgen — CycloneDX generation across a broad range of languages and ecosystems.

The right place to run them is in CI/CD, on every build, so the SBOM is a by-product of shipping rather than a document someone remembers to update. If your product spans several repositories or artifacts, aggregate them into a single application-level SBOM — one bill of materials for the product a customer actually receives, not one per repo. That aggregation is the genuinely useful engineering work in this layer.

What makes an SBOM good enough

"We generate an SBOM" and "we have an SBOM an auditor will accept" are different claims. The gap is quality, and it comes down to a handful of properties:

• Completeness. At least top-level dependencies for the floor; transitive depth for real coverage. An SBOM that silently omits half the tree is worse than none, because it looks complete.
• Accurate identity. Each component named, versioned, and uniquely identifiable — a purl or CPE, not just "logging library." This is what makes correlation against vulnerability data possible later.
• Provenance and supplier. Where each component came from, and who supplies it — the baseline captured by the widely-referenced NTIA minimum elements.
• Freshness. Regenerated per release and timestamped. An SBOM describes one version of one product at one moment; a stale one describes a product you no longer ship.
• Integrity. Hashes for components, and the SBOM itself stored immutably, so you can prove what you shipped and when.

Common mistakes

• Treating the SBOM as a one-off deliverable. Generated once for an audit, then never again. It goes stale the next release.
• Build-time only, no versioning. No history means you can't show how the inventory changed across releases — exactly what a post-market question asks.
• Top-level only, by accident. Meeting the floor deliberately is fine; missing the transitive tree because your tool was misconfigured is a coverage gap you don't know you have.
• Confusing having an SBOM with being compliant. This is the big one — and it's the pivot to the rest of the CRA.

The question an SBOM doesn't answer

An SBOM tells you what is in your product. It does not tell you which of those things can hurt you. The moment you correlate it against vulnerability data, you get a list of CVEs — usually a long, alarming one — and every single one is a question, not an answer: does this actually affect us?

An SBOM lists what's in your software. It stays silent on whether any of it is dangerous right now.

That silence is the whole reason the CRA's vulnerability-handling and reporting obligations are hard. Most of the CVEs matched against a real SBOM don't reach the product — wrong configuration, dead code path, a function never called. Deciding which ones do, with evidence you can defend, is the work that sits directly on top of the SBOM. It's the difference between an inventory and a risk position, and it's covered in evidence-backed VEX.

Where the SBOM fits in the CRA programme

Think of the SBOM as the spine, not the skeleton. Everything downstream hangs off it:

1. SBOM — the machine-readable inventory, per product and version. (You are here.)
2. Correlation — match components against the NVD, EU Vulnerability Database, OSV and CISA KEV. See correlation & active exploitation.
3. Evidence-backed VEX — decide which matches actually matter, with reachability and exploitation proof.
4. Reporting — the actively-exploited ones feed the 24 / 72 / 14 obligation.
5. Evidence trail — all of it retained immutably for the technical file and any future audit.

Get the SBOM right — automated, versioned, complete enough — and then spend your real effort one layer up, where the CRA's cost and risk actually live. For the whole picture, the CRA manufacturer's guide puts these pieces in order.

Frequently asked