SBOM

Softwarestückliste (SBOM)

Eine Softwarestückliste (Software Bill of Materials, SBOM) ist ein strukturiertes, maschinenlesbares Verzeichnis, das jede in einem Produkt enthaltene Softwarekomponente, Bibliothek, jedes Framework und jede Abhängigkeit auflistet – einschließlich Versionsnummern, Lieferanten und Lizenzinformationen. Sie fungiert als eine Art „Nährwerttabelle“ für Software und ermöglicht es Organisationen, bekannte Schwachstellen in ihrer gesamten Software-Lieferkette zu identifizieren und zu beheben.

Wichtige Fakten

Detail	Information
Primäre Formate	SPDX (v2.2.1 veröffentlicht als ISO/IEC 5962:2021), CycloneDX (OWASP, ECMA-424)
Vorgeschrieben durch	EU-Cyberresilienz-Verordnung (2024/2847), US Executive Order 14028
CRA-Frist	11. Dezember 2027 (vollständige Verpflichtungen)
Gilt für	Alle Produkte mit digitalen Elementen, die auf dem EU-Markt verkauft werden
Umfang	Firmware, Betriebssysteme, Middleware, Anwendungscode, Open-Source-Bibliotheken

Warum ist die SBOM für Hardware wichtig?

Eingebettete Hardwareprodukte – IoT-Geräte, Industriesteuerungen, FPGA-basierte Systeme – werden mit Firmware-Stacks ausgeliefert, die Dutzende bis Hunderte von Softwarekomponenten enthalten: RTOS-Kernel, Netzwerk-Stacks, kryptografische Bibliotheken, Bootloader und Treiber. Wenn in einer dieser Komponenten eine Schwachstelle entdeckt wird (z. B. eine kritische OpenSSL-CVE), ermöglicht die SBOM:

Sofortige Folgenabschätzung – Innerhalb von Stunden feststellen, welche Produkte und Firmware-Versionen betroffen sind.
Gezieltes Patchen – OTA-Updates nur für betroffene Geräte bereitstellen, anstatt ganze Flotten pauschal neu zu flashen.
Regulatorischer Nachweis – Auditoren und Marktüberwachungsbehörden dokumentierte Belege für die Prozesse des Schwachstellenmanagements vorlegen.
Kundentransparenz – Unternehmenskunden ermöglichen, das Lieferkettenrisiko vor der Beschaffung zu bewerten.

Ohne eine SBOM steht ein Hersteller, der entdeckt, dass eine vor drei Firmware-Versionen verwendete Bibliothek eine kritische Schwachstelle aufweist, vor wochenlangen forensischen Analysen, um das Ausmaß der Gefährdung zu bestimmen – Zeit, die Regulierungsbehörden und Angreifer nicht gewähren.

SBOM-Formate

Format	Gepflegt von	Stärken	Ökosystem
SPDX (aktuell: 3.0; v2.2.1 ist ISO/IEC 5962:2021)	Linux Foundation	Umfassende Lizenzdaten, ISO-standardisierte Basis	GitHub, Yocto, Zephyr
CycloneDX (aktuell: 1.7; ECMA-424)	OWASP / Ecma	Schlank, auf Schwachstellen fokussiert, VEX-Unterstützung	OWASP-Tools, Dependency-Track

Beide Formate unterstützen die Serialisierung in JSON und XML. Für eingebettete Firmware wird CycloneDX oft bevorzugt, da es native Unterstützung für Hardwarekomponenten-Deskriptoren und VEX-Anweisungen (Vulnerability Exploitability eXchange) bietet.

Die SBOM im Lebenszyklus eingebetteter Firmware

1. Build-Phase
   +-- Toolchain generiert SBOM automatisch aus Build-Manifest
   +-- Erfasst: Komponentenname, Version, Hash, Lizenz, Lieferant
   +-- Tools: Yocto (create-spdx), Zephyr (west spdx), syft, trivy

2. Release-Phase
   +-- SBOM wird dem Firmware-Release-Artefakt beigefügt
   +-- Wird zusammen mit der Firmware-Binärdatei signiert
   +-- Wird im versionierten Artefakt-Repository gespeichert

3. Überwachungsphase
   +-- Kontinuierliches CVE-Scanning der SBOM-Komponenten
   +-- Automatisierte Warnungen, wenn neue Schwachstellen mit SBOM-Einträgen übereinstimmen
   +-- Tools: Dependency-Track, Grype, OSV.dev

4. Reaktion auf Sicherheitsvorfälle
   +-- SBOM-Abfrage identifiziert alle betroffenen Produkte/Versionen
   +-- VEX-Anweisung wird veröffentlicht: betroffen, nicht betroffen oder in Untersuchung
   +-- OTA-Update wird an die betroffene Geräteflotte verteilt

CRA-Anforderungen für die SBOM

Gemäß der EU-Cyberresilienz-Verordnung müssen Hersteller:

Eine maschinenlesbare SBOM für jedes Produkt mit digitalen Elementen erstellen.
Die SBOM während des gesamten Unterstützungszeitraums (mindestens 5 Jahre, sofern das Produkt nicht voraussichtlich kürzer genutzt wird) pflegen.
Die SBOM mit jeder Firmware-Veröffentlichung aktualisieren.
Die aufgelisteten Komponenten auf neu entdeckte Schwachstellen überwachen.
Aktiv ausgenutzte Schwachstellen über die einheitliche Meldeplattform – an das als Koordinator benannte CSIRT und die ENISA – melden, mit einer Frühwarnung innerhalb von 24 Stunden.
Die SBOM den Marktüberwachungsbehörden auf Anfrage zur Verfügung stellen.

Häufige Fehler

Fehler	Warum er relevant ist	Korrekter Ansatz
Manuelle SBOM-Erstellung	Anfällig für Auslassungen, unmöglich zu pflegen	Automatisierte Generierung aus dem Build-System
Nur direkte Abhängigkeiten verfolgen	Transitive Abhängigkeiten enthalten 60–80 % der Schwachstellen	Transitive Abhängigkeiten einbeziehen (das CRA-Minimum sind nur Abhängigkeiten der obersten Ebene)
Einmalige SBOM bei Produkteinführung	Innerhalb von Wochen veraltet, da neue CVEs auftauchen	Kontinuierliche Überwachung mit automatisierten Warnungen
Keine VEX-Anweisungen	Kann nicht kommunizieren, ob eine CVE das Produkt tatsächlich betrifft	VEX zusammen mit der SBOM für jede Sicherheitsempfehlung bereitstellen

Offizielle Referenzen

Verordnung (EU) 2024/2847 (CRA) – Anhang I Teil II Nummer 1, Artikel 13 Absätze 24 und 25 sowie Anhang VII zur SBOM – EUR-Lex (verlangt, dass eine SBOM erstellt und in der technischen Dokumentation aufbewahrt wird; eine Veröffentlichung ist nicht vorgeschrieben)
SPDX – Spezifikation ISO/IEC 5962:2021 – Linux Foundation (primärer Standard für das SBOM-Format)