Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

SBOM for the Cyber Resilience Act: what to produce and how to keep it

7 min read

On this page
  1. What the CRA actually asks
  2. CycloneDX or SPDX?
  3. What a useful SBOM contains
  4. Keep it current, or it is worthless
  5. Step by step for your stack
  6. Firmware and devices
  7. How Provetry helps
  8. Sources

A software bill of materials (SBOM) is the list of components inside a product, with their versions and where they come from. From 11 December 2027, the Cyber Resilience Act makes one mandatory for every product in its scope. Long before that date, it is the only practical way to meet the reporting duties that have applied since September 2026: you cannot tell within 24 hours whether an exploited vulnerability affects you if you don’t know what you ship.

What the CRA actually asks

Annex I, Part II of the regulation sets the vulnerability-handling requirements. The first one asks manufacturers to identify and document the vulnerabilities and components contained 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”.

Four points follow from that sentence:

  • Machine-readable, in a common format. In practice, CycloneDX or SPDX.
  • At least the top-level dependencies. The packages your product declares directly. Listing the whole tree, transitive dependencies included, is better practice and makes vulnerability matching far more reliable.
  • Part of your technical documentation. The SBOM belongs to the file you keep for the authorities (Annex VII). Market surveillance authorities can ask for it.
  • Not necessarily public. The CRA does not require you to publish your SBOM. You may share it with customers if you choose; many business customers will start asking.

CycloneDX or SPDX?

Both are fine. CycloneDX (an OWASP project, standardised as ECMA-424) was designed with security in mind and carries vulnerability and exploitability information (VEX) well. SPDX (Linux Foundation, ISO/IEC 5962) comes from licence compliance and is widely used for open-source licence reporting. If you have no preference, start with CycloneDX and export SPDX when a customer asks for it.

What a useful SBOM contains

For each component:

  • its name, version and supplier;
  • a unique identifier, ideally a package URL (purl) such as pkg:npm/express@4.19.2, so that vulnerability databases can be matched without guesswork;
  • a hash, when you can produce one;
  • its relationship to the rest (direct or transitive dependency).

And for the SBOM itself: the product and release it describes, when it was produced and by which tool.

Keep it current, or it is worthless

An SBOM describes one release. The common failure is a document produced once for an audit and never touched again. To avoid it:

  1. Generate it in your build pipeline, at every release, from the lock files and the container images you actually ship.
  2. Store each release’s SBOM with the release, so you can say which versions in the field contain a component.
  3. Match it against vulnerability data every day, not only at release time: new vulnerabilities are published on components you shipped months ago. Watch for exploitation as well (CISA KEV, the EU Vulnerability Database), since that is what starts the reporting clock.
  4. Record your decisions. When a vulnerable component is present but cannot be exploited in your product, write it down (a VEX statement). It saves the same analysis next time and documents your diligence.

Step by step for your stack

How to generate the SBOM, and what each ecosystem hides from it: npm, pnpm and Yarn, Python, Java, Rust, Go, .NET and container images.

Firmware and devices

For a connected device, the SBOM must cover the firmware too: the operating system, its packages, the bootloader and any third-party binary. If you buy modules from suppliers, ask them for their SBOMs now and put that request in your purchasing terms. Under the CRA, the components you integrate are your responsibility.

How Provetry helps

Provetry builds the SBOM of each product from your repository or from a file, at every release, in CycloneDX and SPDX, watches every component for new vulnerabilities and for exploitation, and keeps each release’s SBOM in your technical file. The free plan covers one product’s SBOM, with a weekly vulnerability digest.

This guide is general information, not legal advice.

Sources