Ihre SBOM listet Bibliotheken und Softwarepakete auf, doch was ist mit der Firmware, die in Ihren Bluetooth-Chip gebrannt wurde, oder dem Mikrocontroller im Herzstück Ihres Geräts? Eine Hardware-Stückliste (HBOM) erweitert das Komponenteninventar auf physische Chips, Module und die darauf ausgeführte Firmware. Der CRA definiert „Produkt mit digitalen Elementen" in Artikel 3 Absatz 1 so, dass auch Hardware-Produkte erfasst sind, und definiert „Hardware" in Artikel 3 Absatz 5 als „ein physisches elektronisches Informationssystem, das digitale Daten verarbeiten, speichern oder übertragen kann, oder Teile eines solchen Systems". Der Begriff „HBOM" findet sich im Verordnungstext an keiner Stelle, aber die Pflicht zur Dokumentation und zur Sorgfalt bei allen Komponenten einschließlich Hardware ergibt sich unmittelbar aus Artikel 3 Absatz 1, Artikel 13 Absatz 5 und Anhang I Teil II Nummer 1.
Zusammenfassung
- Eine HBOM ist ein strukturiertes Inventar der physischen Komponenten in Ihrem Produkt einschließlich der Firmware der jeweiligen Komponenten
- Der CRA schreibt eine HBOM unter diesem Namen nicht vor, aber Artikel 3 Absatz 1 erstreckt den CRA-Anwendungsbereich auf Hardware-Produkte, Artikel 13 Absatz 5 verlangt Sorgfalt bei allen Drittanbieter-Komponenten, und Anhang I Teil II Nummer 1 verpflichtet zur Dokumentation der „in Produkten mit digitalen Elementen enthaltenen Komponenten"
- Firmware ist Software im Sinne von Artikel 3 Absatz 4: Sie „besteht aus Computercode" und muss neben den Hardware-Komponenteneinträgen in Ihrer SBOM erscheinen
- CycloneDX ist das praktisch geeignete einheitliche Format:
type: deviceerfasst physische Hardware,type: firmwareerfasst eingebettete Software, und beide können in einem einzigen CycloneDX-1.6-Dokument nebeneinander bestehen - BSI TR-03183 behandelt HBOM als Konzept bisher nicht; alle drei Teile befassen sich mit Software-Stücklisten und Schwachstellenberichten
- Die Kommission kann Vorgaben zu SBOM-Format und -Feldern per Durchführungsrechtsakt treffen (Artikel 13 Absatz 24), ein paralleles Mandat für ein separates HBOM-Format findet sich im CRA-Text jedoch nicht
Warum HBOM nach dem CRA relevant ist
Der Anwendungsbereich des CRA geht über „Softwareprodukte" weit hinaus. Artikel 3 Absatz 1 definiert „Produkt mit digitalen Elementen" als:
„'Produkt mit digitalen Elementen' bedeutet ein Software- oder Hardware-Produkt und seine Fernverarbeitungslösungen, einschließlich Software- oder Hardware-Komponenten, die gesondert in Verkehr gebracht werden"
Artikel 3 Absatz 5 definiert „Hardware" als:
„ein physisches elektronisches Informationssystem, das digitale Daten verarbeiten, speichern oder übertragen kann, oder Teile eines solchen Systems"
Diese Definition erfasst den Prozessor auf Ihrer Leiterplatte, das Funkmodul auf Ihrem Entwicklungsboard und das Secure Element in Ihrem IoT-Gateway. Sie sind keine Randerscheinung im Rahmen der CRA-Compliance, sondern liegen ausdrücklich in seinem Anwendungsbereich.
Artikel 13 Absatz 5 legt Ihnen als Hersteller dann eine konkrete Pflicht auf:
„Für die Zwecke der Erfüllung der in Absatz 1 festgelegten Pflicht lassen die Hersteller die gebotene Sorgfalt walten, wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen, auch nicht bei der Integration von freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurde."
Sorgfalt gegenüber Hardware-Komponenten, die Sie nicht inventarisiert haben, lässt sich nicht ausüben. Anhang I Teil II Nummer 1 geht noch weiter: Die SBOM muss „Schwachstellen und Komponenten in Produkten mit digitalen Elementen" abdecken. Ein Produkt, das ein ESP32-Modul enthält, enthält auch den Firmware-Stack dieses Moduls als Komponente. Eine HBOM ist das praktische Werkzeug, um dieses Inventar zu erfassen.
Der CRA enthält keine Bestimmung, die ein Dokument namens HBOM vorschreibt. Die Pflicht besteht darin, alle Komponenten einschließlich Hardware-Komponenten im Rahmen der bestehenden SBOM-Pflicht nach Anhang I Teil II Nummer 1 zu inventarisieren. Eine HBOM ist ein praktischer Ansatz, um dieser Pflicht bei Hardware-intensiven Produkten nachzukommen, kein gesondertes Compliance-Dokument.
HBOM und SBOM im Vergleich
| Dimension | SBOM | HBOM |
|---|---|---|
| Primärer Geltungsbereich | Softwarebibliotheken, Pakete, Frameworks | Physische Komponenten: Chips, Module, Secure Elements |
| Firmware-Abdeckung | Kann type: firmware-Einträge enthalten |
Firmware neben der übergeordneten Hardware-Komponente gelistet |
| CRA-Mandat | Explizit, Anhang I Teil II Nummer 1 | Implizit, über Artikel 3 Absatz 1 Anwendungsbereich und Artikel 13 Absatz 5 Sorgfaltspflicht |
| BSI TR-03183-Abdeckung | Ja, TR-03183-2 (v2.1.0, 2025) | Nein, keiner der drei TR-03183-Teile behandelt HBOM |
| CycloneDX-Unterstützung | Alle Versionen | type: device seit v1.1; type: firmware seit v1.2 (Mai 2020) |
| Typisches Generierungswerkzeug | Syft, Trivy, cdxgen | Manuell oder Hardware-Hersteller-Datenblätter; noch keine ausgereiften Werkzeuge zur automatischen Generierung |
| Ablageort in der technischen Dokumentation | Anhang VII Nummer 2 Buchstabe b und Nummer 8 | Gleicher Ort, als Teil des einheitlichen Komponenteninventars |
Die vollständigen SBOM-Pflichten finden Sie unter CRA-SBOM-Anforderungen. Einen Formatvergleich bietet CycloneDX vs. SPDX.
Was in eine HBOM aufzunehmen ist
Die folgenden Kategorien beruhen auf technisch-praktischem Urteil, nicht auf einer gesetzlichen Aufzählung. Der CRA listet keine Hardware-Komponentenkategorien auf. Sie sollten jede physische Komponente aufnehmen, die digitale Daten verarbeitet, speichert oder überträgt, denn genau das erfasst Artikel 3 Absatz 5.
Verarbeitungs- und Konnektivitätskomponenten
Diese Einträge haben höchste Priorität, weil ihre Firmware der wahrscheinlichste Angriffspunkt für Schwachstellen ist:
- Hauptanwendungsprozessor oder SoC (Name, Hersteller, Version/Stepping, Firmware-Version)
- Funkmodule: WLAN, Bluetooth, Zigbee, LoRa, Mobilfunk (jeweils mit Firmware-Version)
- Sekundäre Mikrocontroller für bestimmte Teilsysteme
Sicherheitskomponenten
Sicherheitshardware verdient eigene Einträge, weil Schwachstellen hier die größte Auswirkung haben:
- Trusted Platform Module (TPM)-Chips
- Secure Elements und Hardware-Sicherheitsmodule
- Kryptografische Beschleuniger
- Jede Komponente, die Schlüssel, Zertifikate oder Zugangsdaten gespeichert hält
Speicherkomponenten
Speicher ist relevant, wenn er Code, Konfiguration oder sensible Daten enthält:
- Flash-Speicher mit Bootloader oder Firmware
- eMMC- oder SD-Module für persistente Speicherung
- EEPROM mit Gerätekonfiguration
Erfassen Sie für jeden Eintrag mindestens: Komponentenname, Hersteller, Hardware-Version oder Stepping sowie Firmware-Version, falls zutreffend. Verknüpfen Sie jeden Hardware-Eintrag mit dem zugehörigen Firmware-Eintrag über CycloneDX-Abhängigkeitsbeziehungen.
Ein erheblicher Anteil der IoT-Schwachstellen betrifft Firmware, die nach der Auslieferung nie aktualisiert wird. Firmware-Versionen in Ihrer HBOM zu dokumentieren ist die Voraussetzung für Überwachung und Behebung. Sie können nicht verfolgen, was Sie nicht gelistet haben. Das übergeordnete Muster beschreibt häufige SBOM-Fehler.
Wie Firmware in die CRA-Definition von Software passt
Firmware wird gelegentlich als eigenständige Kategorie behandelt, die sich von Hardware und Software unterscheidet. Der CRA schafft diese dritte Kategorie nicht. Artikel 3 Absatz 4 definiert Software als:
„den Teil eines elektronischen Informationssystems, der aus Computercode besteht"
Firmware besteht aus Computercode. Deshalb ist Firmware nach dem CRA Software. Das ist keine Auslegung, die über den Text hinausgeht, sie ergibt sich unmittelbar aus der Definition.
Das Wort „Firmware" erscheint im CRA an keiner Stelle. Das ist beabsichtigt: Die Definition in Artikel 3 Absatz 4 ist weit genug gefasst, um Firmware zu erfassen, sodass keine gesonderte Klassifizierung notwendig ist.
Die praktische Konsequenz ist eindeutig. Firmware, die auf einem Chip in Ihrem Produkt läuft, ist eine Software-Komponente Ihres Produkts mit digitalen Elementen. Sie muss in Ihrem Komponenteninventar erscheinen. Enthält sie eine Schwachstelle, unterliegt diese Schwachstelle denselben Meldepflichten nach Artikel 14 wie jede Software-Schwachstelle.
CycloneDX als einheitliches SBOM- und HBOM-Format
CycloneDX verarbeitet sowohl Hardware- als auch Software-Komponenten in einem einzigen Dokument. Sie benötigen kein eigenes Dateiformat für Ihre HBOM.
Versionshistorie der Komponententypen (hardware-relevant)
| CycloneDX-Version | Veröffentlichungsdatum | Relevante Ergänzung |
|---|---|---|
| 1.1 oder früher | 2018 | type: device eingeführt |
| 1.2 | 2020-05-26 | type: firmware hinzugefügt |
| 1.5 | 2023-06-26 | type: device-driver hinzugefügt |
| 1.6 | 2024 | Aktuelle Empfehlung für CRA-Konformität |
| 1.7 | Oktober 2025 | Neueste stabile Version |
Hinweis: type: hardware existiert in keiner CycloneDX-Version. Der korrekte Typ für einen physischen Chip oder ein Modul ist type: device.
Die CycloneDX-v1.2-Spezifikation zur Modellierung von Hardware mit Firmware lautet:
"A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device."
Diese Vorgabe entspricht direkt der CRA-Behandlung: Das physische Gerät und seine Firmware sind verwandte, aber eigenständige Komponenten mit je eigener Identität und Version.
Setzen Sie CycloneDX 1.6 als Ziel für neue HBOM-Arbeiten ein. BSI TR-03183-2 v2.1.0 (2025-08-20) hat die Mindestanforderung an die CycloneDX-Version auf 1.6 angehoben. Die Ausrichtung auf 1.6 hält SBOM und HBOM in einem Dokument zusammen und erfüllt TR-03183.
Beispiel: ESP32-Gerät mit Firmware-Stack
Das folgende Beispiel zeigt eine realistische Hardware-Komponente (ESP32-WROOM-32E), ihre Firmware (ESP-IDF) und eine Bibliothek innerhalb der Firmware (mbedtls), alles in einem einzigen CycloneDX-1.6-Dokument mit Abhängigkeitsbeziehungen:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "device",
"name": "ESP32-WROOM-32E",
"version": "Rev 3",
"manufacturer": { "name": "Espressif Systems" },
"description": "WiFi+BT SoC Module",
"properties": [
{ "name": "firmware-version", "value": "4.4.1" },
{ "name": "secure-boot", "value": "supported" }
]
},
{
"type": "firmware",
"name": "ESP-IDF",
"version": "4.4.1",
"description": "Firmware on ESP32"
},
{
"type": "library",
"name": "mbedtls",
"version": "2.28.0",
"description": "TLS library in firmware"
}
],
"dependencies": [
{ "ref": "ESP32-WROOM-32E", "dependsOn": ["ESP-IDF"] },
{ "ref": "ESP-IDF", "dependsOn": ["mbedtls"] }
]
}
Das dependencies-Array macht die Beziehung zwischen Hardware und Firmware explizit. Wenn mbedtls einen CVE-Patch veröffentlicht, können Sie nachvollziehen, welches Gerät betroffen ist und welche Firmware-Version aktualisiert werden muss.
Einen Formatvergleich und Hinweise zur Werkzeugauswahl finden Sie unter CycloneDX vs. SPDX.
Häufig gestellte Fragen
Schreibt der CRA eine HBOM ausdrücklich vor?
Nein, der CRA verwendet den Begriff „HBOM" nirgends. Die Pflicht zur Dokumentation von Hardware-Komponenten ergibt sich mittelbar: Artikel 3 Absatz 1 bringt Hardware-Produkte in den CRA-Anwendungsbereich, Artikel 13 Absatz 5 verlangt Sorgfalt bei allen Drittanbieter-Komponenten, und Anhang I Teil II Nummer 1 verpflichtet zur Dokumentation der „in Produkten mit digitalen Elementen enthaltenen Komponenten". Eine HBOM ist der praktische Ansatz, um diesen Pflichten bei Hardware-Produkten nachzukommen, kein benanntes regulatorisches Erfordernis.
Gilt die Firmware in einem Bluetooth-Chip nach dem CRA als Software?
Ja. Artikel 3 Absatz 4 definiert Software als den Teil eines elektronischen Informationssystems, der aus Computercode besteht. Firmware besteht aus Computercode und fällt damit unter diese Definition. Das Wort „Firmware" kommt im CRA nicht vor; das ist auch nicht nötig, denn die Definition in Artikel 3 Absatz 4 erfasst sie bereits. Jede Firmware, die auf einer Komponente in Ihrem Produkt läuft, ist eine Software-Komponente Ihres Produkts mit digitalen Elementen und muss in Ihrem Komponenteninventar erscheinen.
Behandelt BSI TR-03183 HBOM?
Nein. BSI TR-03183 umfasst drei Teile: Teil 1 (Allgemeine Anforderungen), Teil 2 (SBOM) und Teil 3 (Schwachstellenberichte). Keiner davon behandelt HBOM als strukturelles Konzept. TR-03183-2 erwähnt Firmware nur als Komponenten-Dateityp innerhalb einer Software-Stückliste, über das Feld software_additionalPurpose: firmware. Wenn Sie Hardware-Komponenten für die CRA-Compliance dokumentieren müssen, sind technisches Urteil und die nativen Hardware-Typen von CycloneDX gefragt, da TR-03183 für diesen Teil Ihres Inventars keine Anleitung bietet.
Welche CycloneDX-Version unterstützt Software- und Hardware-Komponenten gleichzeitig?
type: device ist seit CycloneDX v1.1 (2018 oder früher) verfügbar. type: firmware wurde in v1.2, veröffentlicht Mai 2020, hinzugefügt. Beide stehen damit in jeder aktuellen CycloneDX-Version zur Verfügung. Für CRA-Arbeiten setzen Sie v1.6 oder neuer ein: BSI TR-03183-2 v2.1.0 (August 2025) hat die Mindest-CycloneDX-Anforderung auf 1.6 angehoben, und die neueste stabile Version ist 1.7 (Oktober 2025). type: hardware existiert in keiner CycloneDX-Version; verwenden Sie type: device für physische Komponenten.