CRA SBOM requirements: format and depth in CI

A software bill of materials (SBOM) is a machine-readable list of the components inside your software. Under the Cyber Resilience Act (CRA) it becomes mandatory for products with digital elements sold in the EU. The requirement takes up one line in the regulation, and that one line raises a surprising number of questions in a delivery team: which format, how deep, and for how long do we keep it?

This article covers what the CRA requires of an SBOM, how to choose a format and a depth, and how to build generation, signing and archiving into CI so the SBOM becomes a by-product of every build instead of a quarterly project.

Questions about this topic? Get in touch with us!

This is a technical walkthrough, not legal advice. If you are unsure whether your product is in scope, talk to a lawyer. The legal references were checked on 2 November 2026.

By the Agency 42 team · Last reviewed 2 November 2026

What does the CRA say about SBOMs?

The CRA is Regulation (EU) 2024/2847. The SBOM requirement sits in Annex I, Part II, point 1. Manufacturers must identify and document vulnerabilities and components in their products, 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 products".

A few things are worth knowing up front:

• The requirement applies from 11 December 2027 (Article 71), when most of the CRA starts to apply.
• The reporting obligation already applies, since 11 September 2026 (Article 14). It is hard to meet without an SBOM, so in practice you need one now. Whether your product is covered at all is the topic of our guide Does the Cyber Resilience Act apply to you?
• You do not have to publish the SBOM. Recital 77 says manufacturers should not be obliged to make it public. If you choose to share it with users, you must tell them where to find it (Annex II, point 9).
• Authorities can ask for it. The SBOM is part of the technical documentation (Annex VII, point 2(b)), and a market surveillance authority can obtain it on a reasoned request (Annex VII, point 8).
• It must be kept for a long time. The technical documentation must be available for at least ten years after the product is placed on the market, or for the support period if that is longer (Article 13(13)).

Think of the SBOM as the ingredients list on a food package. Nobody reads it every day, but the day someone asks "does this contain nuts?", you want an immediate answer for every package still on the shelves.

Format: CycloneDX or SPDX?

The CRA does not name a format. The Commission may specify format and elements through implementing acts (Article 13(24)), but no such act had been adopted when we last checked. Harmonised standards for the CRA are being developed by CEN and CENELEC. Until they exist, "commonly used and machine-readable" in practice means one of two formats:

The most concrete guidance available today is the German BSI technical guideline TR-03183-2 (version 2.1.0, August 2025). It asks for CycloneDX 1.6 or later or SPDX 3.0.1 or later, in JSON or XML. The guideline is not binding outside Germany, and it is not binding in Germany either, but it is the most detailed reading by a public authority so far and a sensible baseline to aim for.

Our advice: pick one format as the default for the whole organisation and make sure your tooling can convert when a customer asks for the other. The worst outcome is not the wrong format. It is three formats in three teams.

Depth: is "top-level" enough?

Legally, the floor is the product's top-level dependencies. Technically, that is rarely enough. Vulnerabilities such as Log4Shell often sat several levels down the dependency tree, and that is exactly where you need to search when the 24-hour clock starts.

1. Include transitive dependencies

The BSI guideline asks for dependencies to be resolved recursively, at least down to the first component outside what you deliver yourself. It is a good rule of thumb. Generate the full tree, even if the law only asks for the top.

2. Do not forget the base image

For a container, the operating system packages are part of the product. An SBOM that lists only the application's npm or Maven dependencies often misses what actually becomes vulnerable: OpenSSL, glibc and friends in the base image.

3. Identify components so they can be matched

Record name, version, supplier, a PURL (package URL) or CPE, and a checksum. Without unambiguous identifiers a scanner cannot match the component against vulnerability databases, and the SBOM becomes decoration.

4. Keep vulnerabilities out of the SBOM

An SBOM describes what is in a release, and it does not change. The vulnerability picture changes every day. Put vulnerability assessments in separate documents such as VEX or CSAF, and keep the SBOM static per release.

How to build SBOMs into CI

The goal is easy to state: every artifact that leaves the pipeline has an SBOM that is signed, bound to exactly that artifact and stored somewhere you can still search in five years.

1. Generate on every build

Let the pipeline create the SBOM for the finished artifact, not just for the source tree. That way the base image and build dependencies are included. An example with Trivy for a container image:

trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/app:1.4.2

If you prefer Anchore's tooling, Syft produces the same kind of inventory:

syft registry.example.com/app:1.4.2 -o cyclonedx-json=sbom.cdx.json

2. Sign it and bind it to the artifact

An SBOM sitting loose in a folder does not prove much. Attach it as a signed attestation to the image digest, for example with Sigstore Cosign. With your own key (ideally held in a KMS or a secrets vault):

cosign attest --yes --key cosign.key --type cyclonedx --predicate sbom.cdx.json registry.example.com/app@sha256:<digest>

And to verify, for example in an admission policy or at handover:

cosign verify-attestation --key cosign.pub --type cyclonedx registry.example.com/app@sha256:<digest>

Without --key, Cosign uses keyless signing, which requires an OIDC identity, typically from your CI platform. Also note that Cosign by default writes an entry to the public Rekor transparency log. That is often an advantage, but check that it fits your policy.

Now anyone with the right access can verify that this SBOM belongs to this image, and that nobody changed it afterwards.

3. Archive every release that is still out there

• Keep SBOMs for every release, not just the latest. The old versions running at customers are the ones that cause trouble.
• Store them next to the artifact (in the registry, for example Harbor) and in a searchable archive. Registries are pruned by retention policies, but the documentation has to survive for at least ten years.
• Protect the archive against modification and deletion. It is evidence.

4. Scan what you have already shipped

Scan stored SBOMs against vulnerability data every day, not only at build time. Both Trivy and Grype can scan an SBOM directly without pulling the image again: trivy sbom sbom.cdx.json or grype sbom:sbom.cdx.json. That way you find new vulnerabilities in old releases without rebuilding anything.

5. Make it searchable

The question "which releases contain package X in version Y?" should be answered by a query, not by an archaeological dig. That question decides whether you can send the early warning within 24 hours under Article 14.

6. Let AI help, and let people decide

AI tools are useful for summarising large SBOMs, suggesting which findings are relevant and drafting a first VEX statement. Whether a vulnerability is actually exploitable in your product should still be decided and signed off by a person. That is how your engineers get more time for the work that needs judgement.

Common mistakes

• SBOMs only for "big" releases. Friday's hotfix is a release too.
• No link to the artifact. If you cannot show which SBOM belongs to which image, it is weak as evidence.
• Manual generation. Anything that relies on someone remembering will eventually be forgotten. As the Hitchhiker's Guide points out, it pays to know where your towel is. It is even better if the pipeline packs it for you.
• The wrong owner. The SBOM is not only the security team's problem. Product teams own the builds, legal owns the licences, and someone has to own the archive.

Summary

• The CRA requires a machine-readable SBOM in a commonly used format covering at least the top-level dependencies (Annex I, Part II, point 1), from 11 December 2027.
• It does not have to be published, but it belongs in the technical documentation and must be kept for at least ten years.
• No format has been mandated yet. CycloneDX or SPDX are the obvious choices, and BSI TR-03183-2 is a useful benchmark.
• Generate the full dependency tree including the base image, sign the SBOM against the artifact, archive every release and scan daily.

Make this a priority now if:

• you sell software or connected hardware in the EU,
• you cannot tell within an hour which releases contain a given component,
• your SBOMs (if you have any) are created by hand or only for some releases.

Want help building a pipeline that meets the CRA?

We are a Kubernetes and DevSecOps team based in Malmö, Sweden, and we build secure CI/CD chains with SBOMs, signing, scanning and policies. We have experience from the defence sector and from assignments for Danish public authorities.

Want to know where you stand today? We run a gap analysis against the CRA and NIS2 and give you a prioritised list of what is missing. Contact us for a quote or a first technical conversation.

Read more:

• DevOps and DevSecOps
• Compliance: NIS2 and the CRA
• Does the Cyber Resilience Act apply to you?
• Kubernetes hardening as NIS2 evidence
• Contact us

Sources

All checked on 2 November 2026.

1. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (Cyber Resilience Act), OJ L, 20.11.2024. Recital 77, Articles 13(13), 13(24), 14 and 71, Annex I Part II point 1, Annex II point 9 and Annex VII points 2(b) and 8. eur-lex.europa.eu
2. European Commission, "Cyber Resilience Act: Implementation" (implementing acts, guidance, standardisation). digital-strategy.ec.europa.eu
3. BSI, Technical Guideline TR-03183-2: Software Bill of Materials (SBOM), version 2.1.0. bsi.bund.de