Ein modernes IoT-Gerät besteht aus mehreren Softwareschichten: einem Echtzeitbetriebssystem (RTOS), einem Netzwerkstack, Kryptobibliotheken, Treibern und Anwendungscode — zu 70–90% aus Open Source und SDKs von Drittanbietern. Eine Software-Stückliste (SBOM) für IoT-Geräte ist ein maschinenlesbares Verzeichnis all dieser Komponenten samt Versionen, Lizenzen und Abhängigkeiten. Ohne sie weiß ein Hersteller nicht genau, was im Flash-Speicher seiner Geräte landet — und das bedeutet einen blinden Fleck bei Sicherheit und regulatorischer Compliance.
Kurz gefasst: Eine SBOM für IoT-Geräte ist eine vollständige, strukturierte Liste aller Firmware-Komponenten (Open Source und Eigenentwicklung) mit Versionen, Lizenzen und Abhängigkeitsbeziehungen. Sie zeigt in Stunden statt in Wochen, welche Geräte im Feld von einer neu bekannt gewordenen Schwachstelle betroffen sind (etwa in einer TLS-Bibliothek), beschleunigt die Incident Response und wird vom EU-Cyberresilienzgesetz (Cyber Resilience Act) ausdrücklich verlangt.
Was ist eine SBOM im IoT-Kontext?
Eine SBOM ist ein formales, maschinenlesbares Verzeichnis aller Softwarekomponenten, aus denen die Firmware eines Geräts besteht — analog zur Stückliste (BOM) aus der Elektronikfertigung. Der Unterschied: Statt Widerständen und integrierten Schaltkreisen beschreibt sie Pakete, Bibliotheken und Codemodule.
Die US-Behörde NTIA hat den Mindestumfang der Felder definiert, die jeder Eintrag enthalten sollte: Lieferantenname, Komponentenname, Version, eindeutige Identifikatoren (etwa CPE oder PURL), die Abhängigkeitsbeziehung sowie Autor und Zeitstempel der SBOM. In der IoT-Praxis kommen Lizenzangaben und kryptografische Hashes der Dateien hinzu.
Eine SBOM für eingebettete Firmware unterscheidet sich von der einer Server-Anwendung. Der Code wird cross-kompiliert, statisch zu einem einzigen Image gelinkt, und ein Teil der Komponenten stammt aus geschlossenen SDKs der Chiphersteller. Ein Blick in den Paketmanager genügt daher nicht — auch die fertigen Binärdateien müssen analysiert werden.
Warum ist die SBOM für die IoT-Sicherheit entscheidend?
Eine SBOM verkürzt die Reaktionszeit auf eine neu offengelegte Schwachstelle von Wochen auf Stunden. Sobald ein kritisches CVE in einer verbreiteten Komponente auftaucht — etwa zlib, OpenSSL, mbedTLS oder lwIP — filtert ein Hersteller mit aktueller SBOM sofort seine Flotte und weiß, welche Modelle und Firmware-Versionen einen Patch benötigen.
Welches Ausmaß das Problem annehmen kann, zeigte Log4Shell im Jahr 2021: Viele Organisationen brauchten Wochen allein dafür, überhaupt festzustellen, wo die verwundbare Bibliothek im Einsatz war. Bei IoT-Geräten, die verteilt im Feld stehen und schwer zu aktualisieren sind, ist diese Unsicherheit noch teurer. Da der Großteil des Embedded-Codes aus Open Source stammt, wächst das Risiko eines Angriffs auf die Software-Lieferkette mit jeder transitiven Abhängigkeit.
Die SBOM ist zugleich die Grundlage für saubere Lizenzführung und Due Diligence. Sie legt Komponenten unter Copyleft-Lizenzen (etwa GPL) offen, die eine Offenlegung des Quellcodes erzwingen können, ebenso wie aufgegebene und nicht mehr gepflegte Pakete. Sie gehört damit zu den umfassenderen Best Practices für IoT-Sicherheit, neben Firmware-Verschlüsselung und der Integritätsprüfung beim Start.
SBOM-Formate: SPDX, CycloneDX und SWID
Der Markt hat sich auf drei Standards eingependelt, die man vor der Werkzeugauswahl kennen sollte. Jeder verfolgt einen etwas anderen Zweck und hat eigene Stärken:
- SPDX — Standard der Linux Foundation, normiert als ISO/IEC 5962:2021 (aktuell in Version SPDX 3.0). Am stärksten bei der Beschreibung von Lizenzen und Rechtskonformität; breit unterstützt, unter anderem vom Build-System Yocto.
- CycloneDX — OWASP-Standard (Version 1.6) mit Fokus auf Sicherheit. Er unterstützt VEX und Schwachstellendaten nativ sowie die Varianten SaaSBOM und HBOM (Hardware) — eine gute Passung für die IoT-Welt.
- SWID — Software-Identifikations-Tags nach ISO/IEC 19770-2, vor allem für Asset-Management und Installationsinventare genutzt.
Für IoT-Geräte fällt die Wahl meist auf CycloneDX (wegen der Integration von Schwachstellendaten) oder SPDX (wenn Lizenzkonformität Priorität hat). Beide sind Textformate (JSON/XML) und lassen sich daher leicht versionieren und digital signieren.
Wie erzeugt man eine SBOM für IoT-Firmware?
Eine SBOM erzeugt man am besten automatisch in der CI/CD-Pipeline bei jedem Firmware-Build und nicht manuell kurz vor dem Release. Nur dann bleibt das Verzeichnis deckungsgleich mit dem, was tatsächlich im Image gelandet ist. Bewährt hat sich folgendes Vorgehen:
- Aus Build-Manifesten — Werkzeuge wie Yocto/OpenEmbedded (Klasse create-spdx), west in Zephyr oder CycloneDX-Generatoren lesen die Liste der Pakete und Versionen direkt aus der Build-Konfiguration.
- Aus Binäranalyse — für Blobs ohne Quellcode (Hersteller-SDKs, vorkompilierte Bibliotheken) nutzt man Scanner wie Syft oder binwalk, die Komponenten im fertigen Image erkennen.
- Signieren und Ablegen — die fertige SBOM wird signiert, dem Release-Artefakt beigefügt und in ein Überwachungssystem wie Dependency-Track eingespeist.
Wird die SBOM-Erzeugung in die CI/CD-Pipeline für Embedded-Firmware eingebunden, trägt jedes Image ein nachprüfbares Verzeichnis. Besonders wichtig ist das bei OTA-Updates im großen Maßstab, wo eine Flotte parallel viele Softwareversionen betreibt.
SBOM und das Cyberresilienzgesetz (Cyber Resilience Act)
Die SBOM ist keine bloße gute Praxis mehr, sondern wird zur Rechtspflicht. Das EU-Cyberresilienzgesetz — Verordnung (EU) 2024/2847 — verpflichtet Hersteller, eine SBOM zu führen und Schwachstellen über den gesamten Lebenszyklus eines Produkts mit digitalen Elementen zu behandeln.
Die zentralen Termine sind die Meldepflicht für aktiv ausgenutzte Schwachstellen ab September 2026 sowie die vollständige Anwendung der Anforderungen ab dem 11. Dezember 2027. Die Einzelheiten behandeln wir im Beitrag über die CRA-Pflichten von IoT-Herstellern. Außerhalb Europas weisen die US-Executive Order 14028 und die FDA-Vorgabe, Medizinprodukt-Einreichungen eine SBOM beizulegen, in dieselbe Richtung.
Wie die SBOM die Schwachstellenbehandlung unterstützt — die Rolle von VEX
Die SBOM allein sagt, was im Gerät steckt; VEX sagt, ob daraus tatsächlich eine Gefahr erwächst. VEX (Vulnerability Exploitability eXchange) ist ein Begleitdokument, das angibt, ob eine Schwachstelle das Produkt real betrifft — eine Komponente kann vorhanden, aber ungenutzt oder nicht erreichbar sein.
Die Kombination aus SBOM, VEX und laufender Überwachung von Schwachstellendatenbanken (NVD, OSV) senkt die Zahl der Fehlalarme drastisch und lässt das Team sich auf das reale Risiko konzentrieren. So entsteht ein geschlossener Kreislauf: Lücke erkennen, Auswirkung bewerten, patchen und sicher als signiertes Update mit Integritätsprüfung beim Start (Secure Boot) ausliefern.
Häufig gestellte Fragen (FAQ)
Worin unterscheidet sich eine SBOM für IoT von einer für Cloud-Anwendungen?
Eine SBOM für IoT beschreibt Firmware, die cross-kompiliert und statisch zu einem einzigen Image gelinkt wird, oft mit Komponenten aus geschlossenen SDKs der Chiphersteller. Sie erfordert deshalb zusätzlich eine Binäranalyse und nicht nur das Auslesen des Paketmanagers wie bei einer typischen Server-Anwendung.
Ist eine SBOM gesetzlich vorgeschrieben?
Ja. In der Europäischen Union verlangt das Cyberresilienzgesetz eine SBOM für Produkte mit digitalen Elementen, mit vollständiger Anwendung ab Dezember 2027. In den USA gilt die Pflicht unter anderem für Regierungslieferanten und Hersteller von Medizinprodukten, die bei der FDA eingereicht werden.
Wie oft sollte eine SBOM aktualisiert werden?
Eine SBOM sollte automatisch bei jedem Firmware-Build erzeugt werden, damit sie exakt der ausgelieferten Version entspricht. Zusätzlich empfiehlt es sich, sie nach der Offenlegung neuer Schwachstellen in den eingesetzten Komponenten erneut zu bewerten, selbst wenn sich der Code nicht geändert hat.
Fazit und wichtigste Erkenntnisse
Eine SBOM für IoT-Geräte ist heute die Grundlage einer ausgereiften Sicherheit der Software-Lieferkette: Sie verkürzt die Reaktion auf Schwachstellen, bringt Ordnung in die Lizenzlage und erfüllt wachsende regulatorische Anforderungen. Entscheidend sind die automatische Erzeugung in CI/CD, die Wahl des passenden Formats (CycloneDX oder SPDX) sowie die Verbindung von SBOM mit VEX und laufender Überwachung.
Bei FSS Technology entwickeln wir IoT-Geräte durchgängig — von Hardware und Firmware über Secure Boot und signierte OTA-Updates bis in die Cloud — mit fest im Entwicklungsprozess verankerter SBOM. Wenn Sie Ihre Produkte auf das Cyberresilienzgesetz vorbereiten und Ihre Firmware-Lieferkette ordnen wollen, lernen Sie unsere Leistungen im IoT-Gerätedesign kennen.