Compare
CRA compliance: SBOM requirements and tools
The Cyber Resilience Act makes a software bill of materials mandatory for products with digital elements. Here is what the regulation asks of it, what Germany's BSI guideline adds, and how CRA compliance tools compare.
Each comparison says what the other product does well, where CRACI is different, and when you would use both. For every category, see all comparisons.
What the CRA requires of an SBOM
The Cyber Resilience Act, Regulation (EU) 2024/2847, puts the SBOM in its vulnerability handling requirements. It asks for less than many people assume: a machine-readable record of at least the top-level dependencies, kept in the technical documentation and shown to an authority on request. Here is what the regulation says, question by question.
| Capability | What the CRA says | Where |
|---|---|---|
| Is an SBOM mandatory? | Yes. Manufacturers must identify and document the components in their products, "including by drawing up a software bill of materials" | Annex I, Part II, point 1 |
| What is an SBOM? | "A formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements" | Article 3, point 39 |
| Which format? | "A commonly used and machine-readable format". The Commission may specify the format and elements by implementing acts | Annex I, Part II, point 1; Article 13(24) |
| How deep? | "At the very least the top-level dependencies of the products" | Annex I, Part II, point 1 |
| Where does it go? | In the technical documentation, as part of the vulnerability handling information | Annex VII, point 2(b) |
| Does it have to be public? | No. "Manufacturers should not be obliged to make the SBOM public." If you share it with users, the user information says where to find it | Recital 77; Annex II, point 9 |
| Who can ask for it? | A market surveillance authority, on a reasoned request, to check compliance. Authorities may also request SBOMs for an EU-wide dependency assessment | Annex VII, point 8; Article 13(25) |
| How long to keep it? | The technical documentation is kept for at least 10 years after the product is placed on the market, or for the support period, whichever is longer | Article 13(13) |
The regulation applies in full from 11 December 2027, and its reporting obligations apply from 11 September 2026. For the rest of the regulation, see what the CRA requires.
Beyond the minimum: BSI TR-03183-2
Until the Commission specifies the format by implementing act, the most detailed public guidance comes from Germany's Federal Office for Information Security (BSI). Its technical guideline TR-03183-2, version 2.1.0 of August 2025, is guidance, not part of the regulation, but it shows where expectations are heading:
- Format: JSON or XML, valid against CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher.
- Depth: recursive dependency resolution for each component in the scope of delivery, down to and including the first component outside it.
- Source of truth: the SBOM must contain "the same information as available during the build process", or equivalent information where there is no build process.
The guideline also names the kinds of SBOM. A Build SBOM "is created as part of the build process". An Analysed SBOM "is created after the build process by analysing artefacts such as executables, packages, containers and virtual machine images". That distinction is the main difference between the tools on this page.
Top-level or transitive dependencies
Top-level dependencies are the floor, not the goal. A vulnerability in a transitive package is still in your product, and the CRA asks manufacturers to address and remediate vulnerabilities in the components they ship. An SBOM that stops at the first level leaves those packages out of your vulnerability handling. The practical question is not whether to record transitive dependencies, but how to be sure the record matches what shipped.
Build SBOM or analysed SBOM
Most SBOM tools generate an analysed SBOM after the build, or manage SBOMs that other tools produce. CRACI records a build SBOM while the build runs. For SBOM generators and managers compared, see SBOM management and SBOM tools compared. For tools built around the CRA, see CRA compliance tools compared.
Where CRACI fits
CRACI records the SBOM while your GitHub Actions build runs. A package-aware proxy on the runner records every package the job fetched, including packages restored from CI caches, so the SBOM describes the build that produced the artifact rather than a scan that ran somewhere nearby. Each job's SBOM carries a completeness state, and exports in CycloneDX and SPDX include transitive dependencies and each component's declared license.
After release, CRACI keeps re-evaluating monitored SBOMs as new vulnerabilities appear, and it submits the CRA notifications (early warning, notification and final report) on your behalf. Signed provenance links each artifact to the build that produced it. CRACI keeps build data for 180 days by default, with custom retention on Enterprise, so export what belongs in your 10-year technical file. CRACI automates a significant part of the supply chain visibility and evidence your CRA process needs; the conformity assessment and the technical file remain the manufacturer's. Read more about build-time SBOM generation, or book a demo to see an SBOM recorded from one of your builds.
CRACI compared with each tool
- CRACI vs Cybeats An SBOM system of record vs SBOMs recorded and monitored.
- CRACI vs FOSSA SBOM management vs build, SBOM and monitoring in one.
- CRACI vs Anchore Scanning images vs recording and monitoring builds.
- CRACI vs Black Duck Code, snippet and binary scanning vs build evidence.
- CRACI vs Sonatype Repository gatekeeping and SCA vs build evidence.
- CRACI vs ONEKEY Binary firmware analysis vs build-time evidence.
- CRACI vs Finite State Binary and supplier SBOM analysis vs a build record.
- CRACI vs Exein On-device runtime security vs evidence from the build.
Side by side
Several tools on one page, for when you are choosing a category, not one product.
CRA SBOM questions, answered
Does the CRA require transitive dependencies in the SBOM?
The regulation sets the floor at "at the very least the top-level dependencies of the products" (Annex I, Part II, point 1). Transitive dependencies are not named, but a vulnerable transitive package is still in your product, and the CRA asks you to handle vulnerabilities in the components you ship. Germany's BSI TR-03183-2 guideline goes further and asks for recursive dependency resolution.
Does the CRA SBOM have to be public?
No. Recital 77 says manufacturers should not be obliged to make the SBOM public. It belongs in the technical documentation, and a market surveillance authority can request it with a reasoned request. If you choose to share it with users, the information that comes with the product must say where to find it (Annex II, point 9).
Should a CRA SBOM be CycloneDX or SPDX?
The CRA asks for "a commonly used and machine-readable format" and does not name one; the Commission may specify the format by implementing act (Article 13(24)). CycloneDX and SPDX are the two common choices. BSI TR-03183-2 v2.1.0 accepts CycloneDX 1.6 or higher and SPDX 3.0.1 or higher, in JSON or XML.
How long do I have to keep the SBOM?
The SBOM is part of the technical documentation, which manufacturers keep at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period if that is longer (Article 13(13)).
When do the CRA SBOM requirements apply?
The CRA's reporting obligations apply from 11 September 2026, and the regulation applies in full, including the SBOM requirement in Annex I, from 11 December 2027.
Other categories
See CRACI on your own pipeline
Book a demo and we will walk through your builds, your SBOMs and your compliance evidence.
Book a demo