Does the CRA require the SBOM to be published?

No. The CRA requires manufacturers to draw it up as part of vulnerability handling and to provide it to market surveillance authorities on reasoned request; making it available to users is the manufacturer's decision. The guideline also allows public and non-public SBOMs.

Why may an SBOM not list known vulnerabilities?

Because the SBOM describes a fixed software version, while vulnerability knowledge changes daily. Mixing the two makes the SBOM outdated as soon as a new vulnerability is published; advisories and VEX carry that information instead.

All context cards

Context card

The SBOM under BSI TR-03183-2: an inventory, not a vulnerability report

What does BSI TR-03183-2 require of a software bill of materials, and how does it relate to the CRA?

By knowledge.aitechdoc.world

Reviewed October 2, 2026

Review log and changes

The short answer

TR-03183-2 defines a machine-processable SBOM in CycloneDX 1.6 or SPDX 3.0.1 or higher, one per software version, with set data fields for every component and recursive dependency resolution down to the first component outside the scope of delivery. It deliberately excludes vulnerability information: the SBOM is static for a given version, while vulnerability status changes and belongs in security advisories or VEX. The CRA makes an SBOM mandatory; the guideline describes one detailed way to draw it up.

For: Product security managers, software engineers, compliance managers and technical writers documenting software supply chains

Key points

Version 2.1.0 (August 20, 2025) requires JSON or XML in CycloneDX 1.6 or higher or SPDX 3.0.1 or higher, officially released versions only.
A separate SBOM is generated for each software version; it is updated only to add information or correct errors, and a changed component means a new version.
Dependencies are resolved recursively for every component in the scope of delivery, down to and including the first component outside it, which must at least be identified so SBOMs can be chained.
Required fields include creator and timestamp of the SBOM and, per component, creator, name, version, filename, dependencies (with a completeness statement), distribution licences, hash of the deployable form and executable, archive and structured properties.
An SBOM that also contains vulnerability information does not conform to the guideline; whether a product is affected is a matter for vulnerability handling, published as a security advisory (CSAF) or VEX.

The context

What an SBOM is in the guideline

Part 2 of BSI TR-03183 defines the software bill of materials as a machine-processable file that lists the components of a software product and their supply chain relationships: the primary component (the product itself) and the components it uses. The guideline calls it best practice for a secure software supply chain and notes that the Cyber Resilience Act makes it mandatory for products with digital elements. The CRA sets the minimum (a commonly used, machine-readable format covering at least the top-level dependencies); the guideline describes how far one detailed, interoperable SBOM goes.

Format, version and depth

Formats: CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher, in JSON or XML. The guideline maps its data fields to both formats.
One SBOM per software version: an SBOM is updated for the same version only when information is added or errors are corrected. If a component changes, it gets a new version, and so do the components that depend on it.
Depth: recursive resolution for every component in the scope of delivery, down to the first component outside it. That first outside component is identified (creator, name, version, unique identifiers) so the SBOM can be chained with the SBOM of the environment it runs in.
Build information: the SBOM contains the information available during the build. For compiled code, the component actually used by the linker is listed; for interpreted code outside the delivery item, the minimum required version, skipping versions that are end-of-life or have known vulnerabilities.

Licences as data

The guideline also covers the older use case, license management. It distinguishes original licences (set by the component's creator), distribution licences (under which a licensee may use it) and the effective licence (under which the SBOM creator uses it), named with SPDX identifiers and expressions, never by pasting licence text.

Inventory, not vulnerability status

An SBOM conforming to the guideline must not contain vulnerability information. The SBOM of a version is static; vulnerability information is dynamic. To find out whether a product is affected, the SBOM is compared with sources such as CVE entries and the advisories of component makers, and the use of the affected component is analyzed. The result goes to users as a security advisory in CSAF or as VEX — as part of vulnerability management, not as an edit to the SBOM.

Versions of the guideline

To conform, the most recent version of TR-03183-2 on the BSI website is used; the version before it may still be used for six months after a new one appears. An SBOM that conformed when it was delivered stays conformant.

Questions readers ask next

Does the CRA require the SBOM to be published?: No. The CRA requires manufacturers to draw it up as part of vulnerability handling and to provide it to market surveillance authorities on reasoned request; making it available to users is the manufacturer's decision. The guideline also allows public and non-public SBOMs.
Why may an SBOM not list known vulnerabilities?: Because the SBOM describes a fixed software version, while vulnerability knowledge changes daily. Mixing the two makes the SBOM outdated as soon as a new vulnerability is published; advisories and VEX carry that information instead.

Sources

Technical Guideline TR-03183-2: Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM), version 2.1.0 — Federal Office for Information Security (BSI), August 20, 2025
Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the European Union, November 20, 2024
BSI TR-03183: overview of the four parts — CyberKlartext, August 13, 2026

Review log and changes

Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.

Reviewed October 2, 2026

No corrections or additions since publication.

Glossary terms on this card

Software bill of materials (SBOM)
In software supply chain security, a software bill of materials (SBOM) is a formal, machine-readable inventory of the software components, libraries and their versions and suppliers contained in a software or firmware product, including dependency relationships. Common formats are SPDX and CycloneDX.
Cyber Resilience Act (CRA)
The Cyber Resilience Act, Regulation (EU) 2024/2847, is EU legislation establishing cybersecurity requirements for products with digital elements across their lifecycle, from design through vulnerability handling and security updates during the support period. It entered into force on December 10, 2024.
Supply chain security
In cybersecurity, supply chain security is the management of risks that arise from suppliers, service providers and third-party components, including compromised software or hardware, insecure development practices, malicious updates and insecure remote access by service partners.
License management
In software engineering and IT operations, license management is the process of tracking, assigning and complying with the licenses of software used or delivered, including commercial licenses, runtime licenses and open-source licenses.
Security advisory
In product security, a security advisory is a document published by a manufacturer or coordinator that informs users about a vulnerability in specific products and versions, its severity and impact, and the available fixes, mitigations and workarounds. Machine-readable advisories can use the Common Security Advisory Framework (CSAF).
Common Vulnerabilities and Exposures (CVE)
Common Vulnerabilities and Exposures (CVE) is a public program that assigns unique identifiers such as CVE-2024-12345 to publicly disclosed cybersecurity vulnerabilities, so that vendors, operators and tools can refer to the same vulnerability unambiguously. Identifiers are assigned by CVE Numbering Authorities.
Vulnerability management
In cybersecurity, vulnerability management is the continuous process of identifying, assessing, prioritizing, treating and verifying vulnerabilities in systems and products. For asset owners it covers installed assets; for product suppliers it includes handling reported vulnerabilities and delivering fixes.