# SBOM for the Cyber Resilience Act

A software bill of materials is the ingredient list of your product's software. Under the CRA it is mandatory - and it is the only practical way to answer "are we affected?" when the next vulnerability is published.

Source: https://kernwatch.com/sbom · Last updated: 2026-10-17

## Key facts

- Annex I of the CRA requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
- CycloneDX (OWASP) and SPDX (ISO/IEC 5962) are the two widely used SBOM formats.
- The SBOM is part of the technical documentation: it need not be published, but market surveillance authorities can request it.
- Good practice: one SBOM per supported release, generated in the build pipeline and checked daily against vulnerability data.

## What an SBOM is

An SBOM lists every software component in a product: open-source libraries, the operating system, third-party modules and your own packages. For each component it records:

- name and version, for example `openssl 3.0.13`

- supplier

- a unique identifier - a package URL (purl) or CPE

- licence

- which other components it depends on

## What the CRA requires

Annex I of the Cyber Resilience Act requires 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 least the top-level dependencies**. The SBOM is part of your technical documentation; you do not have to publish it, but market surveillance authorities can ask for it.

## CycloneDX and SPDX

Two formats are widely used and both are machine-readable:

- **CycloneDX** (OWASP) - designed for security use cases, with built-in support for vulnerability exploitability (VEX).

- **SPDX** (Linux Foundation, ISO/IEC 5962) - originally for licence compliance, widely supported by build tools.

Most build ecosystems can generate them: for example Syft or cdxgen for containers and file systems, the CycloneDX plugins for Maven, Gradle and npm, and the SPDX output of the Yocto Project for embedded Linux.

## An SBOM is only useful if it stays current

An SBOM written once for the declaration of conformity is outdated with the next release. What helps in practice:

- one SBOM per released version, generated in the build pipeline;

- every component checked against new vulnerability data every day;

- a recorded decision for every finding - affected, not affected or fixed;

- the differences between releases visible at a glance.

## How Kernwatch uses your SBOMs

- Import CycloneDX or SPDX by upload or from CI with an API key.

- Compare releases and see which components were added, removed or changed.

- Components with a package identifier (purl) matched against OSV, the CISA Known Exploited Vulnerabilities list and the EU vulnerability database: daily on paid plans, weekly on Free.

- Triage decisions exported as VEX together with the SBOM when a customer or authority asks.

## Official sources

- [Regulation (EU) 2024/2847, Annex I, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [CycloneDX specification](https://cyclonedx.org/)
- [SPDX specification](https://spdx.dev/)
- [OSV vulnerability database](https://osv.dev/)
- [CISA Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)