What is an SBOM? Definition, contents and a real example

What is an SBOM?

SBOM stands for software bill of materials. The CRA requires one in Annex I Part II(1). It is a file that lists every software component of a product: the operating system or RTOS, every library, every bought-in module, each with its version and an identifier that finds the component unambiguously.

Its value shows when a vulnerability becomes known. CVE-2020-22284 affects lwIP 2.1.0 to 2.1.2. With SBOMs it takes seconds to see which devices and which firmware releases contain lwIP in one of those versions. Without one, someone opens every build by hand.

An SBOM describes exactly one release. Every software version gets its own SBOM (TR-03183-2, section 3.1).

What does an SBOM contain?

In Germany the BSI's TR-03183-2 describes which fields an SBOM should carry; it is a technical guideline without force of law, and the CRA does not name it. For the SBOM itself it requires creator and timestamp. For each component it lists ten mandatory fields (section 5.2.2); unique identifiers such as CPE or purl are also mandatory where they exist (5.2.4). The most important fields are below. The CRA itself names no fields; it requires a commonly used, machine-readable format and at least the top-level dependencies.

Name and version

The name the creator gave the component and its version identifier. Without a version no vulnerability can be matched.

Creator

Who created and maintains the component, as an e-mail address or URL.

Identifier

A unique identifier such as CPE or Package URL (purl). Tools use it to match the component against vulnerability databases.

Dependencies

Which components a component contains or needs, and whether that list is complete.

Licence and hash

The licences under which the component may be used, and the SHA-512 of the delivered file.

What does an SBOM look like? An example

ST ships a CycloneDX SBOM with its STM32CubeF4 software package. The commands below run jq on exactly that file. The first shows what the SBOM describes, the second one component, the third how many of the 74 components carry a version.

Every component has a version, though 57 of the 74 carry 1.28.2 while the file describes package 1.28.3. Only one carries an identifier for matching, a CPE or purl. What that means for vulnerability matching, and which libraries the file leaves out, is in the article on checking an existing SBOM.

$ jq -r .specVersion,.metadata.component.name,.metadata.component.version  \
sbom_cdx.json

1.5
STM32CubeF4
1.28.3

$ jq '.components[] | select(.name=="CMSIS_5") | {type, name, version}'  \
sbom_cdx.json

{
  "type": "library",
  "name": "CMSIS_5",
  "version": "5.9.0"
}

$ jq '[.components[] | select(.version)] | length' sbom_cdx.json;  \
jq '[.components[] | select(.cpe or .purl)] | length' sbom_cdx.json

74
1

Which SBOM formats are there?

Two formats have prevailed. CycloneDX exists as JSON, XML and Protocol Buffers, SPDX 3.0.1 as JSON-LD. The TR-03183-2 requires JSON or XML, CycloneDX from 1.6 or SPDX from 3.0.1 (section 4). Which one fits your process better is in the comparison of the two formats.

What types of SBOM are there?

The explanatory annex of the TR-03183-2 distinguishes six types by when the SBOM is created (section 8.4). For firmware two matter most: the build SBOM, created while building, and the analysed SBOM, read from the finished binary.

Who has to create an SBOM?

Manufacturers of products with digital elements placed on the EU market from 11 December 2027. The CRA requires the SBOM as part of vulnerability handling (Annex I Part II(1)). It belongs in the technical documentation; you do not have to publish it.

Entities under NIS2 in Germany must secure their supply chain and manage vulnerabilities in the systems they acquire and maintain, under section 30(2) sentence 2 no. 4 and 5 of the BSI Act (BSIG). The law does not name the SBOM there. A bill of materials for the devices an operator runs is still the direct way to know which components a new vulnerability hits.

How do I get an SBOM for firmware without source code?

Bought-in firmware and old builds often come without source code. The SBOM is then read from the binary itself, as an analysed SBOM: components and versions come from strings, symbols and package data in the image. How that works for Linux images and microcontroller firmware is in the articles on SBOMs without source code and on the approaches compared.

Can this run automatically?

LegacyMind reads the components from the file you ship: from Linux images, from ELF and AXF builds for microcontrollers and from supplier SBOMs. Every component with an evidenced version is matched against the vulnerability sources. You export the SBOM as CycloneDX 1.6 or as SPDX 2.3 and 3.0.1 JSON.