BSI TR-03183-2 explained: what the guideline requires of an SBOM

What is TR-03183-2?

TR-03183 is titled “Cyber Resilience Requirements for Manufacturers and Products” and has several parts: part 1 general requirements, part 2 the SBOM, part 3 vulnerability reports and notifications, and part H on Module H. According to the BSI, part 2 “describes formal and technical requirements for Software Bill of Materials (SBOM)”. The current versions are part 1 version 1.0.0, part 2 version 2.1.0, part 3 version 1.0.0 and part H version 1.1.0.

The TR is not binding. The BSI writes: “This document is meant to be a guide and is not binding or mandatory. It cannot be used as presumption of conformity.” It is to be replaced by the corresponding harmonised European standards as soon as they become available.

In section 1 the TR states that under the CRA the compilation of an SBOM is mandatory. In section 3.2.9 it explains why it uses terms other than the CRA's: the CRA is a market access regulation, the TR sets technical requirements.

The CRA itself requires a software bill of materials “in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products” (Annex I, Part II, point 1). The Commission may specify format and elements by implementing acts (Article 13(24)). The regulation does not name the TR.

Only version 1.0 of 12 July 2023 was published in German. The BSI lists it as outdated. Version 1.1 of 28 November 2023 was the English translation, with changed requirements for creator, version and licence information. Since then the TR has been published in English.

$ curl -sL -H "Accept: application/xhtml+xml" -H "Accept-Language: eng"  \
http://publications.europa.eu/resource/celex/32024R2847  \
| grep -c "03183"

0

Which formats and versions does it require? (section 4)

A newly generated or updated SBOM must be JSON or XML and valid against one of these specifications in one of the listed versions: CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher. Only officially released versions of the specifications may be used.

Version 2.0.0 of the TR still required CycloneDX 1.5 or higher and SPDX 2.2.1 or higher (table 1). So SPDX 2.3 is no longer enough for a new SBOM.

The most recent version of the TR applies. The immediately preceding one may still be used for up to six months after the new one is issued. An SBOM that matched the version in force on its delivery date stays valid (section 7).

$ pdftotext BSI-TR-03183-2_v2_1_0.pdf -  \
| grep -E "version 1.6 or higher|version 3.0.1 or higher"

CycloneDX9, version 1.6 or higherSystem Package Data Exchange (SPDX)10, version 3.0.1 or higher

Which required fields does the SBOM itself have? (5.2.1, 5.2.3)

Which required fields does each component have? (5.2.2)

Each component needs at least these ten fields. Information that is not available because of the way a component is assembled is left out, even if the field is required, for example the hash or the filename (3.2.1).

Per table 7 a firmware image is an executable, unstructured file. Binaries containing statically linked libraries count as “unstructured, executable files” (8.1.6).

$ pdftotext BSI-TR-03183-2_v2_1_0.pdf -  \
| grep -o '"bsi:component:[a-zA-Z]*"' | sort -u

"bsi:component:archive"
"bsi:component:effectiveLicense"
"bsi:component:executable"
"bsi:component:filename"
"bsi:component:structured"

Additional and optional fields for each component (5.2.4, 5.2.5)

The additional fields are required if the information exists and meets the format's requirements for the field. The optional ones may be given. Licences are named with SPDX licence identifiers or expressions (6.1).

Where do the required fields sit in CycloneDX and SPDX? (8.2)

Since version 2.1.0 the TR maps its fields to SPDX 3.0.1 and CycloneDX 1.6, each in JSON (Tables 8 and 9). According to the TR, both formats lack some of the required values; these go into the SBOM as key-value pairs of the BSI taxonomy. Fields the format itself requires stay in as well.

What applies to components that are only identified? (3.2.2, 3.2.4, 3.2.5)

Not every component has to carry all ten required fields. The TR sets which fields apply in this order: referenced component, identified component, fully described component (5.1).

Must the SBOM hold the same information as the build? (5.1, 3.2.1)

Section 5.1 requires the SBOM to contain the same information as available during the build process, or equivalent information where there is no build process.

For compiled code, section 3.2.1 sets out: the component used during the linker run must be listed, even if an alternative could have been used. This applies to statically and dynamically linked libraries. For firmware this means: every library the linker took into the image must be in the SBOM.

$ pdftotext BSI-TR-03183-2_v2_1_0.pdf - | tr '\n' ' '  \
| grep -o "MUST contain the same information as available during the build process[^(]*"

MUST contain the same information as available during the build process or equivalent information where the build process does not exist

$ pdftotext BSI-TR-03183-2_v2_1_0.pdf -  \
| grep -A1 "The component that was used during the execution of the linker"

The component that was used during the execution of the linker MUST be listed, even if alternativecomponents or implementation could have been used.

What is a build SBOM, and which types exist? (8.4)

The appendix distinguishes six kinds of SBOM by the moment they are created. It is explanatory; the requirements are in sections 3 to 5 (section 8). On the Build SBOM it says: “creating a Build SBOM focuses on the linker run for translated code, not the compiler run”. For hash values to identify components unambiguously, reproducible builds are needed (8.4.3).

How deep must the SBOM go? (5.1, 8.3)

Dependencies are resolved recursively: for each component in the scope of delivery, on each path downward, up to and including the first component outside the scope of delivery. That first component must at least be identified, with creator, name, version and other unique identifiers (3.2.4).

The appendix calls this depth “Delivery item SBOM” (8.3.4). Beside it, it describes the top-level, n-level, transitive and complete SBOM. This goes beyond the CRA, which asks for at least the top-level dependencies.

Several instances of a component with different metadata are listed separately. SBOMs of components may be referenced instead of merged if they themselves match the TR; the provider of the product's SBOM is responsible for their availability (5.1). Each software version gets its own SBOM (3.1).

What stays out of the SBOM?

Vulnerabilities: an SBOM must not contain vulnerability information. A document with both SBOM and vulnerability information does not match the TR (3.1). For that, the TR recommends CSAF, with VEX as a profile (8.1.14).

Signature: the TR writes “Ideally, SBOMs should be digitally signed” (8.1.15). The word is in lower case; per section 2 only the key words in capitals are requirements.

Roles: the TR does not use CRA terms such as economic operator, distributor or importer. Its requirements apply regardless of who implements them (3.2.9).

The TR is written so that conformance can be checked deterministically; tools can flag deviations, the creator of the SBOM decides (3.1).

How do I check an SBOM against the TR by hand?

1. 1

   Check the format: CycloneDX 1.6 or higher or SPDX 3.0.1 or higher, as JSON or XML.

2. 2

   Check the SBOM fields: creator with email or URL, and timestamp, in CycloneDX under metadata.manufacturer and metadata.timestamp (table 8).

3. 3

   Check the ten required fields for each component. In CycloneDX the filename and the three properties are the properties bsi:component:filename, bsi:component:executable, bsi:component:archive and bsi:component:structured.

4. 4

   Check the hash: SHA-512 of the deployable file.

5. 5

   Check the depth: every component in the scope of delivery resolved, the first one outside at least identified.

6. 6

   Move vulnerabilities out: CVE information belongs in a separate document, such as CSAF or VEX.

7. 7

   Check against the build: is every library the linker took into the image in the SBOM?

Can this run automatically?

Microcontroller builds from Keil MDK, IAR or GNU Arm. It finds the libraries built in, with their versions, for example CMSIS packs, RTX5, FreeRTOS, lwIP, mbedTLS and STM32Cube. Plus hardening (stack canary, MPU, privilege separation) and embedded keys.

SBOM export: CycloneDX 1.6 JSON, SPDX 2.3 and SPDX 3.0.1 JSON, plus CSV. Every component says where in the image it was read.

Every component with an evidenced version is matched against the vulnerability sources and says where in the build it sits. If the binary evidences no version, the field stays blank.