SBOM: the software bill of materials required by the CRA

An SBOM (software bill of materials) is the formal, machine-readable inventory of every component that makes up a piece of software, with their versions, suppliers and dependencies. The Cyber Resilience Act (CRA) makes it mandatory for manufacturers of digital products sold in the European Union. For their customers, it is the tool that quickly answers the question every new flaw raises: "am I affected?". This article is part of our Cyber Resilience Act series.

The term comes from manufacturing, where the bill of materials lists the parts of a product. Applied to software, it lists the open-source libraries, commercial modules and other building blocks a vendor has assembled to build its application. Modern software often contains hundreds, many of them not chosen directly by the vendor: each library brings its own dependencies, which bring others.

We therefore distinguish direct dependencies (top-level), which the vendor explicitly included, from transitive dependencies, pulled in indirectly. Bad surprises often hide in the latter.

An SBOM is only useful if it is machine-readable: a hand-written spreadsheet cannot be automatically matched against public vulnerability databases across thousands of components. Hence the importance of standard formats, covered below.

The turning point came in December 2021 with Log4Shell (CVE-2021-44228), a critical flaw in Log4j, a Java logging library found in countless products. The CERT-FR alert, published on 10 December 2021, advised checking internal applications too and contacting the developer or vendor of each product to find out whether it was exposed. Not knowing what was inside their software, many organisations had to question their suppliers one by one. Google's security team counted, as of 16 December 2021, 35,863 Java packages on Maven Central depending on Log4j (over 17,000 for the vulnerable log4j-core module alone, as of 19 December), and found that most depended on it only indirectly.

Since then, attacks on the software supply chain have multiplied, and authorities have made the SBOM a pillar of transparency. In the United States, Executive Order 14028 of May 2021 made it part of the security of software bought by the federal government. In Europe, the CRA makes it mandatory. In its June 2026 adoption survey, ENISA found the regulation acted as an "accelerator": organisations are investing in automated SBOM generation and in integrating it into the development lifecycle.

NTIA minimum elements (2021)

The first reference is the document published on 12 July 2021 by NTIA, an agency of the US Department of Commerce. It sets seven data fields: supplier, component name, version, other unique identifiers, dependency relationships, SBOM author and timestamp. It also requires an automatable format and practices: update frequency, depth (at least top-level dependencies), known unknowns, distribution.

The 2026 update, co-signed by ANSSI

At the end of July 2026, CISA published with the NSA, the FBI and fifteen foreign agencies, including France's ANSSI, Germany's BSI and Italy's ACN, a revised version: the 2026 Minimum Elements for a SBOM. It separates SBOM metadata from component data and adds, among other things, the component's cryptographic hash and algorithm, the licence, the generation tool name and version, the generation context (the point in the lifecycle at which the SBOM was produced) and the author's signature. It no longer settles for top-level depth: it covers all components, including transitive ones.

BSI technical guideline TR-03183-2

In Europe, the most detailed reference is BSI's TR-03183-2, designed to prepare manufacturers for the CRA (version 2.1.0 of 2025, regularly updated). It requires at least CycloneDX 1.6 or SPDX 3.0.1, in JSON or XML, and lists for each component: creator, name, version, filename, dependencies, licences, SHA-512 hash and a few technical properties. It requires dependencies to be resolved recursively and forbids including vulnerability information, which belongs in other documents (CSAF or VEX).

SPDX

SPDX (Software Package Data Exchange), backed by the Linux Foundation, was born for open-source licence compliance. Its version 2.2.1 is standardised as ISO/IEC 5962:2021, and version 3 extended the format to security.

CycloneDX

CycloneDX, an OWASP flagship project, was designed from the outset for security and supply chain risk management. It is standardised by Ecma International as ECMA-424. It can also describe services, hardware and AI models.

Both formats are recognised by all the guides above; ENISA's December 2025 analysis recommends using their latest version. The choice depends mostly on the tools in your development pipeline and your customers'.

VEX: saying whether a flaw is exploitable

An SBOM shows that a component is present, not that it is exploitable. A vulnerable library may be shipped without the faulty function ever being called. VEX (Vulnerability Exploitability eXchange) fills that gap: it is a manufacturer statement that, for a given vulnerability and product, assigns one of the four statuses defined by CISA: not affected, affected, fixed or under investigation, with a justification when the product is not affected. VEX can be expressed in CycloneDX or in the CSAF security advisory format, which BSI recommends.

Part II of Annex I of Regulation (EU) 2024/2847 lists the vulnerability handling requirements. Its first point requires the manufacturer to identify and document vulnerabilities and components contained in the product, "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 product.

Several provisions complete this requirement:

• Technical documentation: Annex VII mentions the SBOM in the description of vulnerability handling processes (point 2(b)) and provides for it to be handed to the market surveillance authority on reasoned request (point 8).
• Harmonised format to come: Article 13(24) allows the Commission to specify the format and elements of the SBOM by implementing act. As of 28 September 2026, to our knowledge no such act had been adopted; the forthcoming European standard on vulnerability handling, being prepared at CEN-CENELEC, may also specify its content.
• Dependency assessment: Article 13(25) allows authorities to request the SBOMs of certain product categories to measure the Union's dependency on components, especially open-source ones.
• Timeline: the obligation applies to products placed on the market from 11 December 2027. The SBOM must be kept up to date during the support period and retained with the technical documentation.

The legal minimum, top level, falls short of technical guides that cover all dependencies. Yet the animation above shows why it matters: with Log4Shell, the vulnerable library was most often a transitive dependency. An SBOM limited to the bare minimum would not have shown it. The SBOM also supports the CRA's other obligations, such as reporting actively exploited vulnerabilities and the stricter conformity assessment for important and critical products.

The CRA does not make the SBOM a public document. Recital 77 says so explicitly: manufacturers "should not be obliged to make the SBOM public". In practice:

• market surveillance authorities (ANFR in France, according to ANSSI) can require it during a check;
• notified bodies see it when they review the technical documentation;
• users get access only if the manufacturer decides so: the instructions must then say where to find it (Annex II, point 9).

For buyers, access to the SBOM is therefore a matter of contract. Because the SBOM reveals part of the product's architecture, ENISA recommends tiered access (public, authenticated customer, privileged), with access logging. Provide for it in your contracts, under a non-disclosure agreement if needed.

Managing vulnerabilities

Imported into a software composition analysis or vulnerability management tool, your suppliers' SBOMs are continuously matched against public databases (NVD, CERT-FR advisories, CISA's Known Exploited Vulnerabilities catalogue). When a flaw is published, you know immediately which products contain it, and the supplier's VEX tells you whether it is exploitable. This is the mechanism shown in the animation.

Assessing suppliers

A vendor's ability to produce a complete, up-to-date SBOM in a standard format says a lot about the maturity of its development. It belongs in your vendor security questionnaire and your third-party risk management. An SBOM also reveals weak signals: components abandoned by their maintainers, very old versions, licences incompatible with your use.

Contracting

In your contracts or your security assurance plan, provide for:

• delivery of an SBOM with each major release, in SPDX or CycloneDX, covering transitive dependencies;
• VEX statements or CSAF advisories when a significant vulnerability affects a component;
• a notification deadline when an exploited vulnerability affects the product;
• confidentiality terms for the SBOM.

For entities subject to NIS 2 or DORA, which must manage their suppliers' security (see our article on NIS 2 and DORA third-party requirements), these clauses provide concrete evidence of due diligence.