Zurück zum Blog
SBOMIoTCRA ComplianceSoftware Bill of MaterialsCyber Resilience ActSoftware

SBOM erstellen für IoT-Hersteller: Der praktische Leitfaden zur CRA-Compliance

Erfahren Sie, wie Sie als IoT-Hersteller eine Software Bill of Materials (SBOM) erstellen, welches Format Sie wählen sollten und wie Sie damit die Anforderungen des Cyber Resilience Act erfüllen.

15. Oktober 2025
5 min read
Think Ahead Team

Der Cyber Resilience Act (CRA) verpflichtet Hersteller digitaler Produkte, eine vollständige Software Bill of Materials – kurz SBOM – für jedes Produkt bereitzuhalten. Gerade für IoT-Hersteller stellt das eine besondere Herausforderung dar, denn vernetzte Geräte kombinieren häufig proprietäre Firmware, Open-Source-Bibliotheken und Drittanbieter-Komponenten in einem einzigen Produkt.

Was ist eine SBOM und warum verlangt der CRA sie?

Eine Software Bill of Materials ist eine maschinenlesbare Auflistung aller Softwarekomponenten, die in einem Produkt enthalten sind. Dazu gehören Betriebssysteme, Bibliotheken, Frameworks, Treiber und jede weitere Abhängigkeit – einschließlich transitiver Abhängigkeiten.

Der CRA macht die SBOM zur Pflicht, weil sie das Fundament für effektives Schwachstellenmanagement bildet. Ohne eine vollständige Übersicht über alle eingesetzten Komponenten ist es unmöglich, bei Bekanntwerden einer neuen Sicherheitslücke schnell zu bewerten, ob das eigene Produkt betroffen ist. Die SBOM muss nicht öffentlich zugänglich sein, aber auf Anfrage der Marktüberwachungsbehörden innerhalb von 24 Stunden bereitgestellt werden können.

Für IoT-Hersteller ist das besonders relevant: Ein typischer Smart-Home-Sensor kann dutzende Open-Source-Pakete enthalten, von denen viele wiederum eigene Abhängigkeiten mitbringen. Ohne systematisches SBOM-Management verlieren Teams schnell den Überblick.

Welches SBOM-Format ist das richtige: SPDX oder CycloneDX?

Die beiden etablierten SBOM-Formate sind SPDX (Software Package Data Exchange) und CycloneDX. Beide werden vom CRA akzeptiert, unterscheiden sich aber in ihren Stärken.

SPDX ist ein ISO-Standard (ISO/IEC 5962:2021) und hat seinen Ursprung im Lizenzmanagement. Es eignet sich besonders gut, wenn Sie neben der Sicherheit auch Open-Source-Lizenzcompliance im Blick haben. SPDX unterstützt die Formate JSON, XML, YAML, RDF und Tag-Value.

CycloneDX wurde von der OWASP-Community speziell für Security-Anwendungsfälle entwickelt. Es enthält nativ Felder für Schwachstellen, Sicherheitsbewertungen und Abhängigkeitsgraphen. CycloneDX ist kompakter und wird von vielen CI/CD-Tools direkt unterstützt.

Für die meisten IoT-Hersteller empfiehlt sich CycloneDX als primäres Format, da es näher an den Sicherheitsanforderungen des CRA liegt. Wichtig ist: Dokumentieren Sie Ihre Formatwahl in der technischen Dokumentation und stellen Sie sicher, dass Sie bei Bedarf in das jeweils andere Format konvertieren können.

Schritt für Schritt: So erstellen Sie eine SBOM für Ihr IoT-Produkt

Der Prozess zur SBOM-Erstellung für IoT-Produkte unterscheidet sich von reinen Software-Projekten, da Sie Hardware-nahe Komponenten, Firmware und oft auch Echtzeit-Betriebssysteme berücksichtigen müssen.

Schritt 1: Inventarisierung aller Softwarekomponenten. Beginnen Sie mit einer vollständigen Bestandsaufnahme. Dazu gehören das Betriebssystem (z. B. FreeRTOS, Zephyr, eingebettetes Linux), alle Bibliotheken und Frameworks, Bootloader und Firmware-Komponenten, Treiber für Peripherie und Sensoren sowie Kryptografie-Bibliotheken. Nutzen Sie automatische Scanner für Ihren Quellcode und ergänzen Sie manuell, was Scanner nicht erfassen – etwa binäre Blobs von Chip-Herstellern.

Schritt 2: Abhängigkeiten auflösen. Ermitteln Sie für jede Komponente die transitiven Abhängigkeiten. Ein einzelnes npm-Paket kann hunderte indirekte Abhängigkeiten mitbringen. Für die CRA-Compliance müssen Sie mindestens die direkten Abhängigkeiten vollständig dokumentieren. Best Practice ist jedoch, auch transitive Abhängigkeiten bis zur zweiten oder dritten Ebene aufzunehmen.

Schritt 3: Metadaten erfassen. Für jede Komponente benötigen Sie mindestens den Paketnamen, die exakte Version, den Lieferanten oder Autor, die Lizenz sowie eine eindeutige Kennung (z. B. CPE oder PURL). Diese Metadaten sind entscheidend, um später automatisiert gegen Schwachstellendatenbanken wie die NVD oder OSV abgleichen zu können.

Schritt 4: SBOM generieren und validieren. Generieren Sie die SBOM in Ihrem gewählten Format und validieren Sie sie gegen das jeweilige Schema. Prüfen Sie auf Vollständigkeit: Fehlen Komponenten, die Sie in Schritt 1 identifiziert haben? Sind alle Versionsangaben korrekt?

Schritt 5: In den Entwicklungsprozess integrieren. Eine SBOM ist kein einmaliges Dokument. Integrieren Sie die SBOM-Generierung in Ihre CI/CD-Pipeline, damit bei jedem Build automatisch eine aktuelle SBOM erzeugt wird. So stellen Sie sicher, dass die SBOM immer dem tatsächlich ausgelieferten Produktstand entspricht.

Häufige Fehler bei der SBOM-Erstellung vermeiden

In der Praxis scheitern viele Hersteller nicht am Prinzip der SBOM, sondern an typischen Fallstricken bei der Umsetzung.

Der häufigste Fehler ist die unvollständige Erfassung: Automatische Scanner erkennen oft keine Firmware-Blobs, statisch gelinkte Bibliotheken oder Komponenten, die als Binärdateien eingebunden sind. Planen Sie immer einen manuellen Review-Schritt ein.

Ein weiterer Fehler ist die fehlende Aktualisierung. Der CRA verlangt, dass die SBOM den aktuellen Stand des Produkts widerspiegelt – auch nach Updates und Patches. Wenn Ihre SBOM nur den initialen Release abbildet, aber Sicherheitsupdates nicht nachgezogen werden, ist das ein Compliance-Risiko.

Schließlich unterschätzen viele Hersteller den Aufwand für Drittanbieter-Komponenten. Wenn Sie Zukaufteile wie WiFi-Module oder Bluetooth-Stacks einsetzen, müssen Sie die SBOM-Informationen von Ihren Zulieferern einfordern. Beginnen Sie frühzeitig damit, denn nicht alle Zulieferer können diese Daten sofort liefern.

Wie Kunnus den SBOM-Prozess vereinfacht

Die manuelle SBOM-Erstellung und -Pflege ist zeitaufwändig und fehleranfällig – besonders wenn Sie mehrere Produktlinien mit unterschiedlichen Software-Stacks verwalten. Automatisierte Tools reduzieren den Aufwand erheblich und minimieren das Risiko unvollständiger Dokumentation.

Kunnus unterstützt IoT-Hersteller dabei, SBOMs automatisiert zu generieren, gegen bekannte Schwachstellen abzugleichen und die gesamte CRA-Dokumentation an einem Ort zu verwalten. So behalten Sie den Überblick über alle Produktversionen und können bei Bedarf innerhalb kürzester Zeit nachweisen, welche Komponenten in welchem Produkt enthalten sind.

Neben der SBOM sind auch ein funktionierendes Schwachstellenmanagement und die richtige Konformitätsbewertung zentrale Bausteine der CRA-Compliance.

Wollen Sie wissen, wo Sie bei der CRA-Compliance aktuell stehen? Unsere kostenlose CRA-Reifegradanalyse zeigt Ihnen in wenigen Minuten, welche Schritte noch nötig sind – einschließlich einer Bewertung Ihres aktuellen SBOM-Prozesses.

Teilen:

Weiterlesen

Bereit, Ihre CRA-Bereitschaft zu prüfen?

Machen Sie unsere kostenlose Reifegradanalyse und erfahren Sie in nur 15 Minuten, wo Ihre Organisation bei der CRA-Compliance steht.

Kostenlose Bewertung starten