Was ist eine SBOM? Definition, Inhalt und ein echtes Beispiel

Was ist eine SBOM?

SBOM steht für Software Bill of Materials. Der CRA nennt sie in der deutschen Fassung Software-Stückliste (Anhang I Teil II Nr. 1). Gemeint ist eine Datei, die jede Softwarekomponente eines Produkts aufführt: das Betriebssystem oder RTOS, jede Bibliothek, jedes zugekaufte Modul, mit Version und einer Kennung, über die sich die Komponente eindeutig finden lässt.

Der Nutzen zeigt sich, wenn eine Schwachstelle bekannt wird. CVE-2020-22284 betrifft lwIP von 2.1.0 bis 2.1.2. Mit SBOMs ist in Sekunden klar, welche Geräte und welche Firmware-Stände lwIP in einer dieser Versionen enthalten. Ohne SBOM muss jemand jeden Build einzeln aufmachen.

Eine SBOM beschreibt genau einen Stand. Für jede Softwareversion entsteht eine eigene SBOM (TR-03183-2, Abschnitt 3.1).

Was steht in einer SBOM?

Welche Felder eine SBOM tragen soll, beschreibt in Deutschland die TR-03183-2 des BSI, eine Technische Richtlinie ohne Gesetzeskraft, die der CRA nicht nennt. Für die SBOM selbst verlangt sie Ersteller und Zeitstempel. Je Komponente nennt sie zehn Pflichtfelder (Abschnitt 5.2.2); eindeutige Kennungen wie CPE oder purl sind zusätzlich Pflicht, wenn es sie gibt (5.2.4). Die wichtigsten Felder stehen unten. Der CRA selbst nennt keine Felder; er verlangt ein gängiges maschinenlesbares Format und mindestens die obersten Abhängigkeiten.

Name und Version

Der Name, den der Ersteller vergeben hat, und seine Versionskennung. Ohne Version lässt sich keine Schwachstelle zuordnen.

Ersteller

Wer die Komponente erstellt hat und pflegt, als E-Mail-Adresse oder URL.

Kennung

Eine eindeutige Kennung wie CPE oder Package URL (purl). Über sie gleichen Werkzeuge die Komponente mit Schwachstellendatenbanken ab.

Abhängigkeiten

Welche Komponenten eine Komponente enthält oder braucht, und ob diese Aufzählung vollständig ist.

Lizenz und Hash

Die Lizenzen, unter denen die Komponente genutzt werden darf, und der SHA-512 der ausgelieferten Datei.

Wie sieht eine SBOM aus? Ein Beispiel

ST legt seinem Softwarepaket STM32CubeF4 eine SBOM im Format CycloneDX bei. Die Befehle unten laufen mit jq auf genau dieser Datei. Der erste zeigt, was die SBOM beschreibt, der zweite eine Komponente, der dritte, wie viele der 74 Komponenten eine Version tragen.

Jede Komponente hat eine Version, 57 der 74 tragen allerdings 1.28.2, während die Datei das Paket 1.28.3 beschreibt. Eine Kennung für den Abgleich, also CPE oder purl, trägt nur eine einzige. Was das für den Schwachstellenabgleich heißt und welche Bibliotheken in der Datei fehlen, steht im Artikel zur Prüfung vorhandener SBOMs.

$ 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

Welche SBOM-Formate gibt es?

Zwei Formate haben sich durchgesetzt. CycloneDX gibt es als JSON, XML und Protocol Buffers, SPDX 3.0.1 als JSON-LD. Die TR-03183-2 verlangt JSON oder XML, CycloneDX ab 1.6 oder SPDX ab 3.0.1 (Abschnitt 4). Welches besser zu Ihrem Prozess passt, steht im Vergleich der beiden Formate.

Welche Arten von SBOM gibt es?

Die TR-03183-2 unterscheidet im erläuternden Anhang sechs Arten, nach dem Zeitpunkt, zu dem die SBOM entsteht (Abschnitt 8.4). Für Firmware zählen vor allem zwei: die Build SBOM, die beim Bauen entsteht, und die Analysed SBOM, die aus dem fertigen Binary gelesen wird.

Wer muss eine SBOM erstellen?

Hersteller von Produkten mit digitalen Elementen, die ab dem 11.12.2027 in der EU in Verkehr kommen. Der CRA verlangt die SBOM als Teil der Schwachstellenbehandlung (Anhang I Teil II Nr. 1). Sie gehört in die technische Dokumentation; veröffentlichen müssen Sie sie nicht.

Einrichtungen unter NIS2 müssen nach § 30 Abs. 2 Satz 2 Nr. 4 und 5 BSIG ihre Lieferkette absichern und Schwachstellen in den Systemen managen, die sie erwerben und warten. Das Gesetz nennt die SBOM dort nicht. Eine Stückliste der Geräte, die ein Betreiber einsetzt, ist aber der direkte Weg zu wissen, welche Komponenten von einer neuen Schwachstelle betroffen sind.

Wie bekomme ich eine SBOM für Firmware ohne Quellcode?

Bei zugekaufter Firmware oder alten Builds fehlt oft der Quellcode. Dann entsteht die SBOM aus dem Binary selbst, als Analysed SBOM: Komponenten und Versionen werden aus Zeichenketten, Symbolen und Paketdaten im Image gelesen. Wie das bei Linux-Images und bei Mikrocontroller-Firmware geht, steht in den Artikeln zur SBOM ohne Quellcode und zu den Ansätzen im Vergleich.

Geht das auch automatisch?

LegacyMind liest die Komponenten aus der Datei, die Sie ausliefern: aus Linux-Images, aus ELF- und AXF-Builds für Mikrocontroller und aus Lieferanten-SBOMs. Jede Komponente mit belegter Version wird gegen die Schwachstellenquellen abgeglichen. Die SBOM exportieren Sie als CycloneDX 1.6 oder als SPDX 2.3 und 3.0.1 JSON.