BSI TR-03183-2 erklärt: was die Richtlinie von einer SBOM verlangt

Was ist die TR-03183-2?

TR-03183 heißt „Cyber Resilience Requirements for Manufacturers and Products“ und hat mehrere Teile: Teil 1 allgemeine Anforderungen, Teil 2 die SBOM, Teil 3 Schwachstellenmeldungen und Teil H zu Modul H. Teil 2 beschreibt laut BSI „formelle und fachliche Vorgaben für SBOM“. Aktuell sind Teil 1 in Version 1.0.0, Teil 2 in Version 2.1.0, Teil 3 in Version 1.0.0 und Teil H in Version 1.1.0.

Verbindlich ist die TR nicht. Das BSI schreibt: „Dieses Dokument stellt eine Hilfestellung ohne verpflichtenden oder verbindlichen Charakter dar. Es kann nicht für eine Konformitätsvermutung genutzt werden.“ Sie soll durch die harmonisierten Europäischen Normen ersetzt werden, sobald diese bereitstehen.

Die TR schreibt in Abschnitt 1, dass der CRA die Erstellung einer SBOM verpflichtend macht. In Abschnitt 3.2.9 erklärt sie, warum sie andere Begriffe als der CRA nutzt: der CRA ist eine Marktzugangsverordnung, die TR legt technische Anforderungen fest.

Der CRA selbst verlangt eine SBOM „in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“ (Anhang I Teil II Nr. 1). Format und Elemente kann die Kommission per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Verordnung nennt die TR nicht.

Auf Deutsch gab es nur Version 1.0 vom 12.07.2023. Das BSI führt sie als veraltet. Version 1.1 vom 28.11.2023 war die englische Übersetzung, mit geänderten Anforderungen an Ersteller-, Versions- und Lizenzangaben. Seither erscheint die TR auf Englisch.

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

0

Welche Formate und Versionen verlangt sie? (Abschnitt 4)

Eine neu erzeugte oder aktualisierte SBOM muss JSON oder XML sein und einer dieser Spezifikationen in einer der genannten Versionen entsprechen: CycloneDX ab 1.6 oder SPDX ab 3.0.1. Es dürfen nur offiziell veröffentlichte Versionen der Spezifikationen verwendet werden.

Version 2.0.0 der TR hatte noch CycloneDX ab 1.5 und SPDX ab 2.2.1 verlangt (Tabelle 1). Für eine neue SBOM reicht SPDX 2.3 damit nicht mehr.

Anzuwenden ist die neueste Version der TR. Die direkt vorhergehende darf bis sechs Monate nach Erscheinen der neuen weiter genutzt werden. Eine SBOM, die bei ihrer Auslieferung der damals gültigen Version entsprach, bleibt gültig (Abschnitt 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

Welche Pflichtfelder hat die SBOM selbst? (5.2.1, 5.2.3)

Welche Pflichtfelder hat jede Komponente? (5.2.2)

Für jede Komponente müssen mindestens diese zehn Felder angegeben sein. Fehlt eine Information, weil die Komponente so zusammengesetzt ist, entfällt das Feld, auch wenn es Pflicht ist, etwa Hash oder Dateiname (3.2.1).

Eine Firmware ist nach Tabelle 7 eine ausführbare, unstrukturierte Datei. Binaries mit statisch gelinkten Bibliotheken gelten als „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"

Zusätzliche und optionale Felder je Komponente (5.2.4, 5.2.5)

Die zusätzlichen Felder sind Pflicht, wenn die Information existiert und den Anforderungen des Formats an das Feld genügt. Die optionalen dürfen angegeben werden. Lizenzen werden mit SPDX-Lizenzkennungen oder -Ausdrücken benannt (6.1).

Wo stehen die Pflichtfelder in CycloneDX und SPDX? (8.2)

Seit Version 2.1.0 enthält die TR eine Zuordnung ihrer Felder zu SPDX 3.0.1 und CycloneDX 1.6, jeweils JSON (Tabellen 8 und 9). Beiden Formaten fehlen laut TR einige der verlangten Werte; diese stehen als Schlüssel-Wert-Paare der BSI-Taxonomie in der SBOM. Felder, die das Format selbst verlangt, bleiben zusätzlich drin.

Was gilt für Komponenten, die nur identifiziert werden? (3.2.2, 3.2.4, 3.2.5)

Nicht jede Komponente muss alle zehn Pflichtfelder tragen. Welche Felder gelten, bestimmt die TR in dieser Reihenfolge: referenzierte Komponente, identifizierte Komponente, voll beschriebene Komponente (5.1).

Muss die SBOM dieselben Informationen wie der Build enthalten? (5.1, 3.2.1)

Abschnitt 5.1 verlangt, dass die SBOM dieselben Informationen enthält, die beim Build-Prozess verfügbar sind, oder gleichwertige, wo es keinen Build-Prozess gibt.

Für kompilierten Code legt Abschnitt 3.2.1 fest: die Komponente, die der Linker verwendet hat, muss in der SBOM stehen, auch wenn eine andere möglich gewesen wäre. Das gilt für statisch und dynamisch gelinkte Bibliotheken. Für Firmware heißt das: jede Bibliothek, die der Linker ins Image übernommen hat, muss in der SBOM stehen.

$ 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.

Was ist eine Build SBOM, und welche Typen gibt es? (8.4)

Der Anhang unterscheidet sechs Arten von SBOM, nach dem Zeitpunkt, zu dem sie entstehen. Er ist erläuternd; die Anforderungen stehen in den Abschnitten 3 bis 5 (Abschnitt 8). Zur Build SBOM heißt es: „creating a Build SBOM focuses on the linker run for translated code, not the compiler run“. Damit Hashwerte Komponenten eindeutig bezeichnen, braucht es reproduzierbare Builds (8.4.3).

Wie tief muss die SBOM reichen? (5.1, 8.3)

Die Abhängigkeiten werden rekursiv aufgelöst: für jede Komponente im Lieferumfang, auf jedem Pfad nach unten, bis einschließlich der ersten Komponente außerhalb des Lieferumfangs. Diese erste Komponente muss mindestens identifiziert sein, mit Ersteller, Name, Version und weiteren eindeutigen Kennungen (3.2.4).

Im Anhang heißt diese Tiefe „Delivery item SBOM“ (8.3.4). Daneben beschreibt er Top-level, n-level, Transitive und Complete SBOM. Das geht über den CRA hinaus, der zumindest die obersten Abhängigkeiten verlangt.

Mehrere Instanzen einer Komponente mit unterschiedlichen Metadaten stehen einzeln in der SBOM. SBOMs von Komponenten dürfen referenziert statt eingefügt werden, wenn sie selbst der TR entsprechen; für ihre Verfügbarkeit sorgt der Anbieter der SBOM des Produkts (5.1). Für jede Softwareversion ist eine eigene SBOM zu erzeugen (3.1).

Was gehört nicht in die SBOM?

Schwachstellen: Eine SBOM darf keine Schwachstelleninformationen enthalten. Ein Dokument mit SBOM und Schwachstellen entspricht der TR nicht (3.1). Empfohlen ist dafür CSAF, mit VEX als Profil (8.1.14).

Signatur: Die TR schreibt „Ideally, SBOMs should be digitally signed“ (8.1.15). Das Wort steht kleingeschrieben; als Anforderung gelten nach Abschnitt 2 nur die großgeschriebenen Schlüsselwörter.

Rollen: Begriffe des CRA wie Wirtschaftsakteur, Händler oder Einführer verwendet die TR nicht. Ihre Anforderungen gelten unabhängig davon, wer sie umsetzt (3.2.9).

Die TR ist so geschrieben, dass sich die Übereinstimmung deterministisch prüfen lässt; Werkzeuge können Abweichungen markieren, entscheiden muss der Ersteller der SBOM (3.1).

Wie prüfe ich eine SBOM von Hand gegen die TR?

1. 1

   Format prüfen: CycloneDX ab 1.6 oder SPDX ab 3.0.1, als JSON oder XML.

2. 2

   SBOM-Felder prüfen: Ersteller mit E-Mail oder URL und Zeitstempel, in CycloneDX unter metadata.manufacturer und metadata.timestamp (Tabelle 8).

3. 3

   Je Komponente die zehn Pflichtfelder prüfen. In CycloneDX stehen Dateiname und die drei Eigenschaften als Properties bsi:component:filename, bsi:component:executable, bsi:component:archive und bsi:component:structured.

4. 4

   Hash prüfen: SHA-512 der auslieferbaren Datei.

5. 5

   Tiefe prüfen: jede Komponente im Lieferumfang aufgelöst, die erste außerhalb mindestens identifiziert.

6. 6

   Schwachstellen auslagern: CVE-Angaben gehören in ein eigenes Dokument, etwa CSAF oder VEX.

7. 7

   Gegen den Build prüfen: steht jede Bibliothek, die der Linker ins Image übernommen hat, in der SBOM?

Geht das auch automatisch?

Builds für Mikrocontroller aus Keil MDK, IAR oder GNU Arm. Gefunden werden die eingebauten Bibliotheken mit Version, etwa CMSIS-Packs, RTX5, FreeRTOS, lwIP, mbedTLS und STM32Cube. Dazu Härtung (Stack-Canary, MPU, Privilegientrennung) und eingebettete Schlüssel.

SBOM-Export: CycloneDX 1.6 JSON, SPDX 2.3 und SPDX 3.0.1 JSON, dazu CSV. Jede Komponente sagt, wo im Image sie gelesen wurde.

Jede Komponente mit belegter Version wird gegen die Schwachstellenquellen abgeglichen und nennt, wo im Build sie steht. Belegt das Binary keine Version, bleibt das Feld leer.