Skip to content
ENFRDescribe your project

SBOM: what the Cyber Resilience Act requires, and how to produce one

An SBOM is the inventory of the components in a piece of software. What it contains, the CycloneDX and SPDX formats, what the Cyber Resilience Act requires and from when, and how to produce one with every release.

By Published on 4 October 2026

An SBOM (software bill of materials) is the list of components that go into a piece of software, with their versions, their origin and how they relate to each other, in a format a machine can read. When a flaw is published in a library, it tells you within minutes which products ship it, and in which version.

The European Cyber Resilience Act makes it mandatory: from 11 December 2027, manufacturers of products with digital elements, software included, must draw one up for what they place on the European Union market.

What is an SBOM for?

On 9 December 2021, a critical flaw was made public in Log4j, a logging library widely used in software written in Java (Log4Shell, CVE-2021-44228). In its July 2022 report, the Cyber Safety Review Board, the US body that reviews major cyber incidents, found that many organisations did not know where the vulnerable software was; one federal department spent 33,000 hours on the response. It recommended developing SBOM tooling.

An SBOM answers without digging through the code: which components, in which versions, in which products. It also helps check the licences of open-source components, and assess a piece of software you buy before installing it. Finally, it reveals an unexpected dependency, such as the packages invented by coding assistants, which our article on vibe coding discusses.

What an SBOM contains

In July 2021, the NTIA, the US telecommunications agency, set out seven baseline data fields for each component:

  • the supplier name;
  • the component name;
  • its version;
  • other unique identifiers;
  • its dependency relationships;
  • the author of the SBOM data;
  • a timestamp.

The bar has risen since. In July 2026, CISA, the US cybersecurity agency, published revised minimum elements, co-signed by agencies from several countries including ANSSI and its German counterpart BSI: they add, among other things, the hash of each component, its licence, the tool that produced the SBOM and the stage at which it was produced (from source code, at build time).

BSI goes further in its technical guideline TR-03183-2 (version 2.1.0, August 2025): it asks for dependencies to be followed step by step, down to the first component not delivered with the product, with a SHA-512 hash of every delivered component.

CycloneDX or SPDX: which format?

Two open formats cover most uses:

  • CycloneDX, an OWASP project standardised by Ecma International as ECMA-424, at version 1.7 since October 2025. It is designed for security: components, services, known flaws.
  • SPDX, a Linux Foundation project, which became the international standard ISO/IEC 5962:2021 in its version 2.2.1; version 3.0 dates from April 2024. It comes from open-source licence tracking.

The Cyber Resilience Act does not impose a format: it asks for a commonly used, machine-readable one. The European Commission may specify it by an implementing act, which it had not adopted as of 4 October 2026. BSI accepts CycloneDX from version 1.6 and SPDX from version 3.0.1. In the survey published by ENISA, the EU cybersecurity agency, in June 2026, covering 334 organisations, 44% used CycloneDX and 29% SPDX.

What the Cyber Resilience Act requires, and from when

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements, hardware and software, sold in the Union. On SBOMs, its Annex I (Part II, point 1) requires manufacturers to identify and document the components and vulnerabilities of their products, including by drawing up an SBOM that covers at least the top-level dependencies.

  • 10 December 2024: the regulation enters into force.
  • 11 September 2026: the duty to report actively exploited vulnerabilities and severe incidents, products already on the market included: an early warning within 24 hours, a notification within 72 hours, through the single reporting platform opened that day.
  • 11 December 2027: the other obligations apply, the SBOM included.

The SBOM is part of the product’s technical documentation. It does not have to be published: the regulation states that manufacturers are not obliged to, and they hand it to a market surveillance authority that makes a reasoned request. Breaching the essential requirements can lead to a fine of up to 15 million euros or, if higher, 2.5% of worldwide annual turnover.

The text covers software supplied in the course of a commercial activity, along with the remote processing without which it cannot work. Pure online services (SaaS) come rather under the NIS2 directive, and open-source software distributed outside any commercial activity is out of scope. The European simplification package presented in November 2025, known as the “Digital Omnibus”, does not change these dates; it was still under discussion in the European Parliament as of 4 October 2026.

Companies are preparing unevenly: in the ENISA survey, 78% of the organisations questioned had started adopting SBOMs, but 9% had a mature, automated process; 43% said the Cyber Resilience Act had significantly sped up their investment. In the United States, Executive Order 14028 of May 2021 started the movement for suppliers to the federal government; since January 2026, a White House memorandum (M-26-05) lets each agency require an SBOM by contract.

Producing an SBOM with every release

A hand-written SBOM is wrong by the next release. It belongs in the delivery pipeline (CI/CD, the automation that builds, tests and deploys software):

  • Generate it on every build, from the lock files and an analysis of the built software, rather than from the list of declared dependencies.
  • Store it with the release, signed, and keep it for as long as that release is maintained.
  • Check it: an empty, incomplete or badly formatted SBOM fails the release.
  • Connect it to vulnerability monitoring, so you are alerted when a known flaw affects a component of a release still in service.

After the SBOM: tracking vulnerabilities

An SBOM says what a product contains; it does not say whether a known flaw in a component can be exploited in that product. That is the job of VEX (Vulnerability Exploitability eXchange): a statement that says, flaw by flaw, whether the product is affected, fixed, not affected or under investigation. BSI asks for this information to be kept out of the SBOM and recommends publishing it in the CSAF format (Common Security Advisory Framework), an OASIS standard since November 2022, which includes a VEX profile.

This tracking also prepares you for Cyber Resilience Act reporting: knowing quickly that a product is affected leaves time to send the early warning within 24 hours.

Where to start

  • List the products concerned: the software and devices you sell or supply in the Union.
  • Produce a first SBOM per product, automatically, in CycloneDX or SPDX.
  • Connect it to vulnerability monitoring, with an owner per product.
  • Organise the reporting of exploited vulnerabilities, already mandatory since 11 September 2026.

This is what our offer Security in every release covers: the inventory of your applications’ libraries, an alert when a known flaw affects them, and release rules. See also DevOps and CI/CD. To talk it through with an engineer: the free scoping day.

Frequently asked questions

Do you have to publish your SBOM?

No, not under the Cyber Resilience Act: it is part of the technical documentation and is handed to the authorities on a reasoned request. You may share it with your customers; the product’s user information then says where to find it.

Does the Cyber Resilience Act apply to SaaS?

A pure online service comes, in principle, under the NIS2 directive. The Cyber Resilience Act covers the installed software or the device you sell, together with the remote processing it cannot work without.

Should indirect dependencies be listed?

The regulation asks for the top-level dependencies at least; the BSI guideline goes down to indirect ones. Generation tools list them anyway, and keeping them avoids missing a flaw buried several levels down.

Is an SBOM enough to comply?

No. The Cyber Resilience Act also requires security by design, vulnerability handling throughout the support period, security updates and reporting. The SBOM is one piece of it.

Sources

Facts and figures checked on 4 October 2026.