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 (ISO/IEC 5962:2021), CycloneDX (OWASP) |
| 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 2.3 | Linux Foundation (ISO-Standard) | Umfassende Lizenzierung, ISO-standardisiert | GitHub, Yocto, Zephyr |
| CycloneDX 1.6 | OWASP | 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 verteiltCRA-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 der gesamten unterstützten Lebensdauer des Produkts (mindestens 5 Jahre) pflegen.
- Die SBOM mit jeder Firmware-Veröffentlichung aktualisieren.
- Die aufgelisteten Komponenten auf neu entdeckte Schwachstellen überwachen.
- Aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden.
- 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 | Vollständigen Abhängigkeitsbaum einbeziehen |
| 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 veröffentlichen |
Verwandte Begriffe
- CRA – Die EU-Verordnung, die eine SBOM für vernetzte Produkte vorschreibt.
- Secure Boot – Integritätsprüfung der Firmware, komplementär zur Nachverfolgung der Lieferkette mittels SBOM.
- IoT – Vernetzte Geräte, deren Firmware-Stacks am meisten von der SBOM-Transparenz profitieren.
- CVE – Die Kennungen für Schwachstellen, nach denen bei der SBOM-Überwachung gesucht wird.
Unser Service für SBOM & Schwachstellenüberwachung automatisiert den gesamten SBOM-Lebenszyklus – von der Erstellung während des Builds über kontinuierliches CVE-Scanning bis hin zu vorformatierten ENISA-Berichten –, damit Ihre eingebettete Firmware ohne manuellen Aufwand konform bleibt.
Offizielle Referenzen
- Verordnung (EU) 2024/2847 (CRA) – Artikel 13 und 14 zur SBOM – EUR-Lex (schreibt die Erstellung und Pflege von SBOMs vor)
- SPDX – Spezifikation ISO/IEC 5962:2021 – Linux Foundation (primärer Standard für das SBOM-Format)