Hardware-Stückliste (HBOM) und CRA-Compliance

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 verwendet den Begriff „HBOM" nicht, aber Hardware-Produkte, separat vermarktete Hardware-Komponenten, die Sorgfalt gegenüber Drittanbieter-Komponenten und das SBOM-Komponenteninventar führen zu demselben praktischen Bedarf: wissen, welche Hardware und Firmware im Produkt steckt.

Warum HBOM nach dem CRA relevant ist

Der Anwendungsbereich des CRA geht über reine Software-Produkte hinaus. Hardware-Produkte, separat vermarktete Hardware-Komponenten und die Firmware in diesen Komponenten gehören alle zum Inventarproblem des Produkts.

Für Hersteller ist das wichtig, weil Komponentensorgfalt nicht bei Open-Source-Bibliotheken endet. Ein Prozessor auf Ihrer Leiterplatte, ein Funkmodul auf Ihrem Entwicklungsboard oder ein Secure Element in Ihrem IoT-Gateway kann Firmware und sicherheitsrelevante Versionen mitbringen. Diese Risiken lassen sich ohne Inventar nicht steuern.

Die SBOM-Pflicht ist der rechtliche Ort für diese Arbeit: Sie verlangt die Erfassung der Komponenten, die in Produkten mit digitalen Elementen enthalten sind. Ein ESP32-Modul bringt daher sowohl das physische Modul als auch seinen Firmware-Stack in den Komponentenbestand. Eine HBOM ist das praktische Werkzeug dafür.

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
Compliance-Rolle	Explizite Pflicht zum Komponenteninventar	Praktische Erweiterung desselben Komponenteninventars für Hardware-Produkte
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	Technische Dokumentation, Abschnitt zum Komponenteninventar	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. Nehmen Sie jede physische Komponente auf, die digitale Daten verarbeitet, speichert oder überträgt, weil solche Komponenten die Cybersicherheit beeinflussen können.

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.

Wie Firmware in die CRA-Definition von Software passt

Firmware wird gelegentlich als eigenständige Kategorie behandelt, die sich von Hardware und Software unterscheidet. Für die CRA-Arbeit sollten Sie Firmware als Software behandeln, weil sie Computercode ist, der in einem elektronischen Informationssystem läuft.

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 im Komponenteninventar erscheinen. Enthält sie eine Schwachstelle, folgt diese Schwachstelle demselben Schwachstellenmanagement- und Meldeprozess wie jede andere 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-oder-neuer-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.