The SBOM becomes mandatory, but what is it exactly?

You cannot manage a vulnerability in software you do not know you are using. That is exactly why the SBOM is an important part of the Cyber Resilience Act. This article is a short introduction: what is an SBOM, what is it used for, what does it look like, and how do you create one?

What is an SBOM?

SBOM stands for Software Bill of Materials. Anyone who designs physical products knows the term BoM: a list of all the parts that together make up the end product. For many software developers this may be a new concept. An SBOM is essentially the same thing, but for software: a structured list of all libraries and dependencies in your application.

Modern software typically consists of 70% or more third-party components. A typical embedded product contains an RTOS or Linux distribution, a TLS library, an MQTT client or other network protocols, and dozens of packages that each bring their own dependencies. So the SBOM is essentially a list of ingredients. Regulators use the same analogy: the German BSI describes the SBOM in its Cyber Resilience Act guidance as "the equivalent of a list of ingredients for food".

What is the SBOM used for?

1. Vulnerability management by the manufacturer

"Which vulnerabilities are in my product?"

This is the primary purpose within the CRA. With a machine-readable SBOM you can automatically detect newly discovered vulnerabilities (CVEs) in your own product. Without an SBOM, the CRA obligation to "identify and document vulnerabilities in components" is practically impossible to fulfil. It forces manufacturers to know what they ship. The SBOM is therefore not a standalone compliance document, but part of the vulnerability management process.

2. Impact analysis when a vulnerability is found

"This vulnerability has been found. Which of my products are affected?"

Suppose a critical vulnerability is found in a widely used library. With an up-to-date SBOM you can quickly determine which products and firmware versions contain this component and may therefore be affected.

Without an SBOM, such an investigation often starts with the question: "Do we actually use that library anywhere?"

3. Market surveillance and incident response

"Can we demonstrate exactly what is in our product?"

Market surveillance authorities can request the SBOM when they need it to verify compliance with the CRA. An up-to-date SBOM makes it possible to quickly and concretely show which software components are part of a product and which versions are used.

What does an SBOM look like?

"commonly used and machine-readable format" - according to the CRA

There are two dominant open standards: SPDX and CycloneDX. Note that these are not file formats, but agreements on which information an SBOM contains and how it fits together. Each standard can be stored in several file formats, such as JSON, XML or YAML. In practice JSON is the common choice for both, and that is what the examples below show. The CRA currently does not prescribe a specific standard or file format, but requires a commonly used and machine-readable format.

For each component they record the name, the exact version, the licence and a unique identifier that allows tooling to automatically link the component to known vulnerabilities. They also record the relationships between components: which component uses which other component.

This information forms a graph in which you can see exactly how all dependencies relate to each other, including the indirect ones you never consciously chose yourself.

SPDX (as JSON)

SPDX (Software Package Data Exchange) comes from the Linux Foundation and is the older of the two. It was originally created to answer the question "which open source licences are in my product?". The security component was added later, in versions 2.0 and 3.0 of the standard.

{
  "spdxVersion": "SPDX-2.3",
  "name": "frogwatch-firmware",
  "packages": [
    {
      "name": "rustls",
      "SPDXID": "SPDXRef-Package-rustls",
      "versionInfo": "0.23.4",
      "downloadLocation": "https://crates.io/crates/rustls",
      "licenseConcluded": "Apache-2.0 OR MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:cargo/rustls@0.23.4"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-rustls"
    }
  ]
}

Simplified example

CycloneDX (as JSON)

CycloneDX is a younger standard that has been developed from the start with a strong security and supply-chain perspective.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": {
      "type": "firmware",
      "name": "frogwatch-firmware",
      "version": "2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "rustls",
      "version": "0.23.4",
      "purl": "pkg:cargo/rustls@0.23.4",
      "licenses": [
        { "license": { "id": "Apache-2.0" } }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "frogwatch-firmware",
      "dependsOn": ["pkg:cargo/rustls@0.23.4"]
    }
  ]
}

Simplified example

The structure of both formats is similar and at first glance you hardly see a difference. The nice thing about CycloneDX is that it can do more than just SBOM: there is a variant for hardware (HBOM) and for cryptographic dependencies (CBOM). You can then use the same visualisation tools to get insight into those dependencies too.

How do you create an SBOM?

To start with: you create one SBOM per product, and really per released version of that product. The SBOM describes exactly what is in the firmware you shipped. If a product consists of several parts, or two products share the same base, each product still gets its own SBOM. Otherwise you cannot answer which devices in the field are affected when a vulnerability is found.

Depending on how you work, this can be a lot of work or very little. Because we at Jitter mainly program in Rust, the SBOM can be generated fully automatically with cargo cyclonedx. This runs as part of our CI pipeline: for every change to the software we automatically get a new, machine-readable SBOM.

That is exactly how I think compliance should be approached: not by creating a document afterwards because a law asks for it, but by setting up your development process so that the document is created automatically.

It gets harder with older C codebases with copied-in libraries, or with binary blobs from chip vendors. There is no manifest there, so you have to build the inventory partly by hand or with binary analysis. For some companies, that is a lot of work between now and 2027.

Conclusion

From 11 December 2027 the main obligations of the Cyber Resilience Act apply to manufacturers of products with digital elements placed on the EU market.

That may sound far away, but an SBOM is not a document you create once for the compliance department. It has to become part of your vulnerability management process.

If you set up your build process now so that every release automatically produces an up-to-date SBOM, you will not need to start a compliance project in 2027.

You will not just be compliant. You will actually know what is in your product.

Curious what this looks like for your product, or want to know what else the CRA asks of you? Get in touch.