Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a complete, formalised list of all software components, libraries and dependencies in a product. SBOM is a requirement under the Cyber Resilience Act (CRA) and an essential tool for vulnerability handling and supply chain security.

Back to Dictionary

What is an SBOM?

Think of an SBOM as an ingredients list for software. Just as a food producer must disclose which ingredients are in a product, CRA requires software producers to document which components their product is built from.

Modern software is rarely built from scratch. A typical product contains hundreds of third-party libraries and open-source components. Each of these components may have known vulnerabilities, and without an SBOM it is impossible to keep track of what is actually running in your product.

The Log4Shell vulnerability in December 2021 illustrated the problem. Organisations worldwide spent weeks determining whether they were affected because they lacked visibility into where the Log4j library was used. With an up-to-date SBOM, you can answer that question within minutes.

SBOM as a legal requirement under CRA

The Cyber Resilience Act requires manufacturers of products with digital elements to prepare an SBOM. The requirement is anchored in CRA Annex I on vulnerability handling and in the requirements for technical documentation.

The SBOM must at a minimum identify top-level dependencies in the product. It must be included in the technical documentation, which the manufacturer must retain for at least ten years after the product's placement on the market.

CRA is not the only regulation pointing towards SBOM. In the US, Executive Order 14028 from 2021 already made SBOM a requirement for software supplied to federal agencies. NIS2 presupposes supply chain security, and an SBOM is the most concrete tool for documenting the software supply chain. DORA sets corresponding requirements for ICT third-party management in the financial sector.

What must an SBOM contain?

A useful SBOM contains at a minimum the following information for each component:

Component name: The official name of the library or package
Version: The specific version included in the product
Supplier: Who developed the component
Unique identifier: E.g. CPE (Common Platform Enumeration) or PURL (Package URL)
Dependency relationships: How the components relate to one another
Licence: Which open-source licence applies

CRA requires top-level dependencies at a minimum, but an SBOM with a full dependency tree (including transitive dependencies) provides far better visibility. Many vulnerabilities are found in deep dependencies that you may not even be aware your product uses.

Formats and tools

Two formats dominate the SBOM landscape:

SPDX (Software Package Data Exchange): Developed by the Linux Foundation and standardised as ISO/IEC 5962:2021. SPDX is well suited for licence management and is the older of the two formats.

CycloneDX: Developed by OWASP with a stronger focus on security. CycloneDX supports vulnerability data, services and machine-readable VEX (Vulnerability Exploitability eXchange).

Both formats are machine-readable (JSON, XML) and supported by most tools. The choice often depends on your existing ecosystem and primary needs.

For generating SBOMs, a range of tools is available: Syft, Trivy, Microsoft SBOM Tool and GitHub's built-in dependency graph. Most CI/CD pipelines can be configured to generate an SBOM automatically at each build.

SBOM in practice

An SBOM only has value if it is kept up to date and used actively. Here is how you integrate SBOM into your development process:

Automate generation: Generate the SBOM automatically as part of your build pipeline. Manual SBOMs quickly become outdated and unreliable.

Link to vulnerability databases: Use tools such as Grype, Trivy or Dependency-Track to automatically match your SBOM against known vulnerabilities in NVD, OSV and other databases. This is the core of effective vulnerability handling.

Version and archive: CRA requires documentation for ten years. Save the SBOM for each release so you can document which components were included in a given version of the product.

Use it for incident response: When a new critical vulnerability is announced, you need to quickly determine whether your product is affected. An up-to-date SBOM makes this possible within minutes.

For organisations working with security by design, SBOM is a natural part of the technical documentation. It also supports GDPR's requirements for technical and organisational measures, as it documents a deliberate approach to component selection and risk management.

Frequently Asked Questions about Software Bill of Materials (SBOM)

What is a Software Bill of Materials (SBOM)?

An SBOM is a complete, formalised list of all software components in a product, including third-party libraries, open-source components and their versions. Think of it as an ingredients list for software, enabling you to trace which components are included in the product.

Does CRA require an SBOM?

Yes. The Cyber Resilience Act requires manufacturers of products with digital elements to prepare an SBOM that at a minimum identifies all top-level dependencies in the product. The SBOM must be included in the technical documentation.

Which formats are used for SBOMs?

The two most widely used formats are SPDX (Software Package Data Exchange), which is an ISO standard, and CycloneDX, developed by OWASP. Both are machine-readable and supported by most SBOM tools.

Why is SBOM important for cybersecurity?

An SBOM gives you visibility over all components in your product. When a new vulnerability is discovered in a library, you can quickly identify whether your product is affected. Without an SBOM, you are blind to risks in your dependencies.

Must the SBOM be shared with customers?

CRA requires the SBOM to be included in technical documentation and made available to market surveillance authorities. CRA does not require public disclosure to all customers, but many industries are moving towards greater transparency, and customers may demand it as part of a procurement process.