What the CRA expects from an SBOM
Formats, depth, package URLs and where to generate it. A practical read on the software bill of materials the Cyber Resilience Act asks manufacturers for.
A software bill of materials is an inventory of what is inside the thing you ship. Not what is in your repository, not what your package manager installed on a developer laptop: what is in the artefact a customer receives. That distinction is where most first attempts go wrong.
Which format
| Format | Maintained by | Practical note |
|---|---|---|
| CycloneDX | OWASP | Most tooling emits it. Versions 1.5 and 1.6 are what you will see in practice. |
| SPDX | Linux Foundation | Common where licence compliance already drives the process. Version 2.3 is widespread. |
Both are commonly used machine-readable formats. Pick the one your build tooling already produces rather than the one that reads better, because an SBOM you generate by hand is an SBOM that is wrong by the second release.
Top-level dependencies at minimum
The stated floor is the top-level dependencies. That floor is lower than what is useful. Vulnerabilities do not respect depth: a transitive dependency four levels down is exploited exactly as readily as a direct one, and it is the one nobody has heard of.
Generate the full graph if your tooling can. The cost is a larger file. The benefit is that when a component you never chose turns up in a news cycle, you can answer the question in seconds rather than spend a day grepping lockfiles.
What a usable SBOM contains
- A package URL for every component, so that matching against vulnerability data is mechanical rather than fuzzy string comparison.
- Exact versions. A range is not an inventory.
- The component that is the product itself, with its own version, so the file identifies what it describes.
- The dependency relationships, so that the path from your product to a vulnerable component can be shown rather than asserted.
Package URLs matter more than they look. Matching by name alone confuses packages that share a name across ecosystems, and the failure mode is silent: you are told you are clean because the lookup missed.
Generate it in the build
An SBOM produced from the build that made the artefact describes that artefact. An SBOM produced afterwards from a source tree describes an intention. Put generation in the pipeline, next to the step that publishes the release, and keep the file with the release.
- Add an SBOM step to the release job. Most ecosystems have a first-party or well-maintained generator.
- Attach the file to the release artefact so that the version and the inventory travel together.
- Keep old ones. The question you will be asked is what was in version 3.4, shipped eighteen months ago, and the answer has to exist.
What an SBOM does not do
It does not tell you whether you are exploitable. It tells you what you carry. Turning that into an answer needs vulnerability data, a view of which of those vulnerabilities are actually being exploited, and a judgement about whether the vulnerable code path is reachable in your product. The inventory is the first step of three, and it is the only one that is purely mechanical.
It is also not a secret you can publish carelessly. A dependency map of your product is a shortlist of ways to attack it. Share it with customers who ask, keep it out of public buckets, and be deliberate about which version of it is public.
When this becomes mandatory
The date to plan against is 2027-12-11, but the useful date is earlier. Reporting obligations arrive first, and answering a vulnerability report in hours is only possible if the inventory already exists. Build the SBOM pipeline for the reporting deadline, not for the conformity one.