How to create an SBOM for CRA compliance

The Cyber Resilience Act requires manufacturers to draw up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the product's top-level dependencies. In practice: CycloneDX or SPDX, generated automatically on every build and archived per shipped version.

You do not have to publish the SBOM – it is part of the technical documentation and must be provided to market surveillance authorities on request. Its real value lies elsewhere: without an SBOM you cannot quickly answer whether an exploited component is in your products – exactly what CRA reporting demands from September 2026.

What does the CRA require?

• Annex I Part II(1): manufacturers identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
• Annex VII: the SBOM is part of the technical documentation, where available.
• Implementing acts: the Commission may specify SBOM format and elements.

Top-level dependencies are the minimum. For robust vulnerability handling, cover the full transitive dependency tree – most vulnerabilities sit in indirect packages.

Why it is urgent

More than a thousand components per application cannot be tracked by hand. An SBOM created manually once before release is outdated after the next dependency update.

Formats: CycloneDX vs. SPDX

Both formats work for the CRA. If your focus is vulnerability handling, CycloneDX is usually the more pragmatic start. Consistency matters more than the choice: one format, one pipeline, one store.

BSI TR-03183-2: minimum fields

The German BSI's Technical Guideline TR-03183 operationalises CRA requirements and has three parts; part 2 covers SBOMs. It expects CycloneDX or SPDX in current versions and defines mandatory fields, including:

• SBOM creator and timestamp
• per component: creator, name, version, dependencies
• licence information
• hash of the deployed component

The guideline is not legally binding but is the best available orientation until the EU sets details. Check the current version directly with the BSI.

SBOMs in CI/CD

GitHub Actions and other pipelines

1. Run a generator in the build job (e.g. Syft or cdxgen) – after dependency resolution so lockfiles are respected.
2. Store the SBOM as a build artefact tied to version and commit.
3. For releases: sign the SBOM and archive it immutably – at least for the retention period of the technical documentation (10 years or the support period, whichever is longer).

Container images and firmware

For containers the SBOM belongs to the image, not just the source: base image and OS packages are often the biggest source of vulnerabilities. For firmware, include toolchain components, bootloaders and third-party binaries even if they do not come from a package manager.

From SBOM to vulnerability matching

An SBOM only becomes useful when it is continuously matched against vulnerability databases (e.g. OSV, NVD) and exploit signals. Add VEX (Vulnerability Exploitability eXchange) statements to document why a vulnerability is not exploitable in your product – saving discussions with customers and authorities.

Common mistakes

• SBOM from source code instead of the shipped artefact.
• No versioning – when reporting, nobody knows which SBOM matches which customer installation.
• Top-level dependencies only, although vulnerabilities are transitive.
• Hand-written components and vendored libraries missing.

Your first SBOM step by step

1. Choose the artefact: start with the product most customers use and the artefact actually shipped – installer, container image or firmware image.
2. Test a generator: run a tool such as Syft or cdxgen locally against the artefact and spot-check the output against your lockfiles.
3. Close gaps: add components the generator misses, such as copied libraries or supplier binaries.
4. Move it into the pipeline: generate the SBOM automatically on every release build and store it with the artefact.
5. Set up matching: connect the SBOM to a vulnerability scanner and define who assesses findings.

Practical examples

Web agency with many client projects

An agency maintains numerous Node.js and PHP projects. Instead of a separate approach per project, it defines a shared pipeline step that generates a CycloneDX SBOM on every deployment and hands it to the client as part of the release documents. Each client, as manufacturer, can add the SBOM to its technical documentation.

Device maker with embedded Linux

A maker of industrial gateways builds firmware with an embedded Linux build system. Many components come from the build system itself. It makes sense to generate the SBOM directly from the build rather than analysing the finished image afterwards – that yields more accurate versions.

Automated with Nuowei

Nuowei (beta, launch November 2026) generates an SBOM on every commit, versions it per release and continuously matches it against vulnerabilities. Learn more on our SBOM page, where you can also join the waitlist.