HBOM-Leitfaden: Hardware-Stückliste für CRA-Compliance

Ihre SBOM listet Bibliotheken und Softwarepakete auf. Sie sagt Ihnen nicht, ob das Funkmodul in Ihrem Produkt außerhalb des Supports liegt, ob der Bootloader aktualisierbar ist oder welche Charge einen Ersatz-Chipsatz verwendet hat.

Diese Aufgabe übernimmt eine Hardware-Stückliste (HBOM). Der CRA verwendet den Begriff „HBOM" nicht, doch Hardware-Produkte, Firmware, Komponentensorgfalt bei Drittanbietern und das SBOM-Komponenteninventar führen alle zum selben praktischen Bedarf: Wissen, welche Hardware und Firmware im Produkt steckt, und wissen, ob Sie handeln können, wenn eine Schwachstelle auftaucht.

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 entscheidend, 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, Sicherheitseinstellungen und Support-Enddaten mitbringen. Ohne eine Inventarisierung lassen sich diese Risiken nicht steuern.

Die SBOM-Pflicht ist der rechtliche Ort für diese Evidenz. Der CRA verpflichtet Hersteller dazu, Komponenten und Schwachstellen zu identifizieren und zu dokumentieren, unter anderem durch eine maschinenlesbare SBOM, die mindestens Abhängigkeiten der obersten Ebene abdeckt. Ein ESP32-Modul bringt deshalb sowohl das physische Modul als auch seinen Firmware-Stack in den Komponentenbestand. Eine HBOM ist das praktische Werkzeug, um diese Hardware-Seite des Inventars zu erfassen.

Support-Zeiträume gehören zum selben Bild. Der CRA erlaubt es, die Supportzeiträume von Kernkomponenten zu berücksichtigen. Ihre technische Dokumentation muss dann die Informationen enthalten, die zur Festlegung des Produkt-Supportzeitraums herangezogen wurden. Wenn ein Chipsatz oder Modul das Support-Ende vor Ablauf des Produkt-Supportzeitraums erreicht, sollte das zuerst in der HBOM sichtbar werden.

Wie eine HBOM in einer echten Lieferkette aussieht

Stellen Sie sich einen EU-Importeur vor, der ein vernetztes Gateway bei einem Shenzhen-ODM einkauft. Der Importeur benötigt nicht jeden Widerstand. Er benötigt die Fertigungsdaten, die das Cyberrisiko verändern: Funkmodul, Firmware-Basisversion, Support-Status und genehmigte Substitutionen.

Der entscheidende Unterschied ist das Ist-Fertigungsprotokoll. Eine Design-Stückliste gibt an, was die Entwicklung verwenden wollte. Die HBOM sollte auch erfassen, was die Fabrik tatsächlich ausgeliefert hat.

HBOM und SBOM im Vergleich

Die vollständigen SBOM-Pflichten finden Sie unter CRA-SBOM-Anforderungen. Einen Formatvergleich bietet CycloneDX vs. SPDX.

Was aufzunehmen ist und wo aufzuhören ist

Der CRA gibt keine gesetzliche Liste von HBOM-Feldern vor. Er verlangt auch nicht, dass Sie jedes passive physische Teil auflisten. Die Komponenteninventar-Basis legt eine Mindesttiefe auf oberster Ebene für die SBOM fest, und die Hardware-Seite sollte derselben Risikoabwägung folgen.

Verwenden Sie diese Schwelle: Führen Sie Hardware auf, die das Cyberrisiko, den Schwachstellenstatus, den Update-Pfad oder die Belege für den Supportzeitraum des Produkts verändern kann.

Beginnen Sie mit Komponenten, die eine dieser Aufgaben erfüllen:

• Daten verarbeiten: Hauptprozessoren, SoCs, Mikrocontroller, FPGAs und sicherheitsrelevante ASICs.
• Code oder Geheimnisse speichern: Flash, eMMC, Trusted Platform Modules (TPMs), Secure Elements und Speichercontroller.
• Daten übertragen: WLAN, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, Mobilfunk und GNSS-Module.
• Das Produkt starten oder aktualisieren: Boot-Manager, Bootloader, UEFI, BIOS, Baseboard-Management-Controller (BMC)-Firmware und Update-Controller.
• Sicherheit durchsetzen: kryptografische Beschleuniger, Hardware-Roots of Trust, Schlüsselspeicher und Secure Enclaves.
• Servicezugang bereitstellen: Produktions-Debug-Ports, JTAG, UART, SWD oder Verwaltungsschnittstellen, bei denen der Sperrstatus in der Produktion relevant ist.

Passive Teile wie normale Widerstände und Kondensatoren fallen normalerweise nicht in die HBOM, sofern sie keine Sicherheitsfunktion, keine digitale Identität, keine Firmware und kein bekanntes Substitutionsrisiko aufweisen. Der praktische Test ist einfach: Wenn eine Schwachstelle, ein Sicherheitshinweis, ein EOL-Hinweis oder eine Lieferantensubstitution für das Teil Ihre Produktrisikobewertung verändern würde, listen Sie es auf.

Hardware-Kategorien mit hoher Priorität

Die folgenden Kategorien sind keine gesetzliche Aufzählung. Es sind die Einträge, die in CRA-Nachweisen am häufigsten relevant sind, weil sie Firmware, Schlüssel, Schnittstellen oder Lieferanten-Support-Abhängigkeiten tragen.

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.

Firmware-Ebenen, die häufig übersehen werden

Ein einzelnes Feld „Firmware-Version" ist oft zu flach. Viele Produkte enthalten mehrere Firmware-Ebenen mit unterschiedlichen Verantwortlichen, Update-Pfaden und Schwachstellenquellen.

Häufig übersehene Ebenen sind:

• Boot-Firmware: Boot-ROM, Bootloader, Boot-Manager und Secure-Boot-Konfiguration.
• Radio-Firmware: WLAN, Bluetooth, Mobilfunk-Baseband, Zigbee, Thread, LoRaWAN und NFC-Firmware.
• Plattform-Firmware: UEFI, BIOS, BMC, Option-ROMs und CPU-Mikrocode. NIST SP 800-193 behandelt Plattform-Firmware als grundlegende Hardware und Software, die zum Starten und Betreiben eines Systems erforderlich ist.
• Controller-Firmware: Speichercontroller, Netzwerkkarten, Stromversorgungscontroller, Sensor-Hubs und eingebettete Controller.
• Sicherheits-Firmware: TPM-Firmware, Betriebssysteme von Secure Elements, Secure-Element-Applets, Trusted Execution Environment (TEE)-Images und HSM-Firmware.
• Programmierbare Logik: FPGA-Bitstreams und sicherheitsrelevante ASIC- oder FPGA-Konfigurationen.
• Herstellereigene Binär-Blobs: Firmware-Blobs aus einem SDK, die in das Produkt-Image gebündelt sind, aber vom Chip- oder Modulhersteller gepflegt werden.

Jede Ebene sollte eine separate Komponente sein, wenn sie eine eigene Version, einen eigenen Update-Pfad, einen eigenen Betreuer oder eine eigene Advisory-Quelle hat. Nur so können Sie später die nützliche Frage beantworten: Welche genauen Produktversionen sind von diesem Firmware-Sicherheitshinweis betroffen?

Felder, die eine HBOM nützlich machen

Die gesetzliche Mindestanforderung ist enger als eine nützliche HBOM. Die unten aufgeführten Felder sind nach dem CRA nicht alle verpflichtend. Sie sind die Evidenz, die es Ihnen ermöglicht, Schwachstellen, Lieferantenänderungen und Supportzeitraum-Entscheidungen zu behandeln, ohne bei null anzufangen.

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 behandeln Sie Firmware als Software, 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 Schwachstellenbehandlungs- und Meldeprozess wie jede andere Software-Schwachstelle.

Wenn Firmware nicht aktualisiert werden kann

Manche Firmware lässt sich im Betrieb nicht aktualisieren. Ein Boot-ROM kann maskenprogrammiert sein. Secure-Element-Code kann herstellerseitig kontrolliert werden. Ein Funkmodul bietet möglicherweise keinen kundenseitigen Update-Pfad. Das lässt die Komponente nicht aus den CRA-Nachweisen verschwinden.

Der CRA erwartet, dass Schwachstellen durch Sicherheitsupdates behebbar sind, soweit das zutrifft. Wenn eine Hardware-Komponente keine Updates erhalten kann, dokumentieren Sie das in der HBOM und der Risikobewertung.

Erfassen Sie:

• Update-Status: im Betrieb aktualisierbar, nur durch den Hersteller, nur in der Fabrik oder unveränderlich.
• Grund: ROM, einmalig programmierbarer Speicher, gesperrtes Herstellermodul, Zertifizierungsbeschränkung oder kein freigegebener Update-Kanal.
• Kompensierende Maßnahmen: Isolation, deaktiviertes Feature, Netzwerkbeschränkung, zusätzliche Authentifizierung oder produktseitige Abschwächung.
• Reaktionspfad: Firmware-Update, Modulaustausch, Einheitenrückruf, Kundenhinweis oder VEX-not_affected-Erklärung, wenn der anfällige Pfad nicht erreichbar ist.
• Betroffener Bereich: Produktversion, PCB-Revision, Los- oder Seriennummernbereich.

Wenn eine ausnutzbare Schwachstelle nicht behoben oder abgemildert werden kann, können CRA-Korrekturpflichten Abhilfemaßnahmen, Rücknahme oder Rückruf erzwingen. Die HBOM sollte Ihnen den betroffenen Produktbereich aufzeigen, bevor diese Entscheidung dringend wird.

Komponenten-EOL beeinflusst den Supportzeitraum

Der Produkt-Supportzeitraum ist nicht nur ein Kundenversprechen. Er ist Teil des CRA-Modells zur Schwachstellenbehandlung.

Der CRA erlaubt es, die Supportzeiträume integrierter Kernkomponenten von Drittanbietern bei der Festlegung des Produkt-Supportzeitraums zu berücksichtigen. Ihre technische Dokumentation muss dann die Informationen enthalten, die zur Festlegung des Supportzeitraums herangezogen wurden. CRA-Hinweise zu langlebigen Hardwarebeispielen umfassen Hauptplatinen, Mikroprozessoren, Router, Modems, Switches und Industriesteuerungen, die häufig länger als fünf Jahre genutzt werden.

Das macht Komponenten-EOL zu einem HBOM-Feld, nicht nur zu einer Einkaufsnotiz.

Erfassen Sie für Kernkomponenten:

• Lieferanten-Support-Enddatum: Monat und Jahr, soweit verfügbar.
• Datum der letzten Firmware-Veröffentlichung: der jüngste Zeitpunkt, zu dem der Lieferant ein sicherheitsrelevantes Firmware-Update ausgeliefert hat.
• Advisory-Quelle: PSIRT-Seite, CSAF-Feed, Mailingliste oder Lieferantenkontakt.
• Austauschpfad: pin-kompatibles Teil, Neudesign-Plan, Last-Time-Buy-Entscheidung oder Produkt-EOL-Entscheidung.
• Vertragliche Absicherung: ob die Patch- und Meldepflichten des Lieferanten den von Ihnen erklärten Produkt-Supportzeitraum abdecken.

Wenn ein Kernmodul vor Ihrem Produkt das Support-Ende erreicht, müssen Sie vor dem Inverkehrbringen eine Entscheidung treffen. Verlängern Sie die Lieferantenabsicherung, wählen Sie ein anderes Teil, begrenzen Sie den Produkt-Supportzeitraum, sofern gerechtfertigt, oder dokumentieren Sie einen Austauschplan.

CycloneDX als einheitliches SBOM- und HBOM-Format

CycloneDX verarbeitet Hardware- und Software-Komponenten in einem einzigen Dokument. Sie benötigen kein separates Dateiformat für Ihre HBOM.

Versionshistorie der Komponententypen (hardware-relevant)

In keiner CycloneDX-Version gibt es type: hardware. Der korrekte Typ für einen physischen Chip oder ein Modul ist type: device.

Die CycloneDX-Leitlinien für Komponententypen behandeln das physische Gerät und die darauf laufende Software als separate Komponenten. Ein Prozessor oder Chipsatz wird als device dargestellt, während der darauf laufende Code je nach Fall als firmware oder operating-system dargestellt wird.

Diese Leitlinien entsprechen 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 oder neuer als Ziel für neue HBOM-Arbeiten. BSI TR-03183-2 v2.1.0 (2025-08-20) hat die Mindest-CycloneDX-Anforderung auf 1.6 angehoben. Die Ausrichtung auf 1.6 oder neuer hält SBOM und HBOM in einem Dokument zusammen und erfüllt die TR-03183-Anforderungen.

CycloneDX verfügt außerdem über offizielle cdx:device:*-Eigenschaften für Hardware-Details wie Funktion, Platinen-Position, Gerätetyp, Seriennummer, Losnummer und GS1-Identifikatoren. Verwenden Sie diese Namen, wo sie passen. Wenn Sie benutzerdefinierte Eigenschaften für Aktualisierbarkeit oder Sicherheitsstatus hinzufügen, versehen Sie diese mit einem klaren Namespace, damit Leser sie nicht mit der offiziellen CycloneDX-Taxonomie verwechseln.

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",
  "version": 1,
  "components": [
    {
      "type": "device",
      "bom-ref": "device:esp32-wroom-32e",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "Wi-Fi and Bluetooth SoC module",
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf"
        }
      ],
      "properties": [
        { "name": "cdx:device:function", "value": "Wi-Fi and Bluetooth connectivity" },
        { "name": "cdx:device:deviceType", "value": "SMD module" },
        { "name": "example:firmware:updateable", "value": "vendor-supported" },
        { "name": "example:security:secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "firmware:esp-idf-4.4.1",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Espressif IoT Development Framework running on ESP32"
    },
    {
      "type": "library",
      "bom-ref": "library:mbedtls-2.28.0",
      "name": "mbedtls",
      "version": "2.28.0",
      "purl": "pkg:generic/mbedtls@2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "device:esp32-wroom-32e", "dependsOn": ["firmware:esp-idf-4.4.1"] },
    { "ref": "firmware:esp-idf-4.4.1", "dependsOn": ["library:mbedtls-2.28.0"] }
  ]
}

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.

Das Beispiel lässt absichtlich eine Hardware-CPE weg. CPE-Strings der National Vulnerability Database (NVD) sind produktspezifisch, und modul- oder die-seitige Identifikatoren stimmen nicht immer überein. Fügen Sie ein cpe-Feld nur dann hinzu, wenn Sie den genauen NVD-Eintrag für die Komponente verifiziert haben. Einen Formatvergleich und Hinweise zur Werkzeugauswahl finden Sie unter CycloneDX vs. SPDX.

Hardware-Schwachstellenabgleich ist anders

Software-Schwachstellenscanner gleichen oft nach Package URL (PURL), Common Platform Enumeration (CPE) oder Paket-Metadaten ab. Hardware ist unübersichtlicher.

PURL basiert auf Software-Paket-Ökosystemen wie npm, Maven, PyPI, Debian und RPM. Er ist nützlich für Firmware-Pakete oder Bibliotheken, bei denen die Software wie ein Paket verteilt wird. Für einen physischen Chip ist er nicht der richtige Identifikator.

CPE kann Hardware über part=h darstellen, und CycloneDX hat ein cpe-Feld auf oberster Komponentenebene. Verwenden Sie es, wenn eine verifizierte NVD-CPE vorhanden ist. Gehen Sie aber nicht davon aus, dass jeder Chip, jedes Modul oder jedes Firmware-Image eine CPE hat.

Halten Sie für Hardware-Einträge ohne zuverlässige CPE die Abgleichspur menschenlesbar:

• exakter Herstellername
• Herstellerteilenummer
• Hardware-Revision oder Stepping
• Firmware-Name und -Version
• Hersteller-Advisory oder PSIRT-URL
• Lieferantenkontakt
• GS1-Identifikator, sofern vorhanden, über die entsprechende cdx:device:gs1:*-Eigenschaft

Beobachten Sie dann die Quellen, die tatsächlich Hardware- und Firmware-Sicherheitshinweise veröffentlichen: die PSIRT-Seite des Lieferanten, NVD, CISA Known Exploited Vulnerabilities, CISA-ICS-Hinweise, soweit relevant, und branchenspezifische Feeds für Industrie-, Medizin- oder Funkprodukte. Verwenden Sie VEX oder gleichwertige Belege, wenn eine Komponente vorhanden ist, die anfällige Funktion in Ihrem Produkt aber nicht erreichbar ist. Den Meldeprozess finden Sie unter CRA-Schwachstellen- und Vorfallsberichterstattung.

Was Sie Lieferanten und Auftragshersteller fragen sollten

Komponentensorgfalt liegt beim Hersteller. Bei Hardware bedeutet das, vor der Festlegung auf ein Teil Sicherheits- und Lebenszyklus-Daten einzufordern.

Fragen Sie Lieferanten und Auftragshersteller nach:

• Exakter gelieferter Identität: Herstellerteilenummer, Hardware-Revision, Firmware-Version und alle genehmigten Substitutionen.
• Update-Pfad: ob die Firmware im Betrieb, nur durch den Hersteller, nur in der Fabrik oder gar nicht aktualisiert werden kann.
• Update-Sicherheit: Signierung, Authentifizierung, Anti-Rollback und Details zur sicheren Verteilung.
• Support-Daten: Komponenten-EOL, Last-Time-Buy, letzte Firmware-Veröffentlichung und Support-Enddatum.
• Advisory-Kanal: PSIRT-Seite, Sicherheits-Mailingliste, CSAF-Feed, Support-Portal oder benannter Ansprechpartner.
• Status bekannter Schwachstellen: aktuelle Sicherheitshinweise, behobene Firmware-Versionen und etwaige VEX- oder CSAF-Erklärungen.
• Produktionsnachverfolgbarkeit: Ist-Stückliste je Produktionslauf, Los- oder Seriennummernbereich, wenn Substitutionen auftreten können.
• Lieferkettenquelle: autorisierter Händler oder Originalkomponentenhersteller, wenn Fälschungs- oder Graumarktrisiken relevant sind.

Eine Design-Stückliste reicht nicht aus, wenn ein ODM oder Auftragshersteller Module während der Produktion ersetzen kann. Sie benötigen die Ist-Komponentenaufzeichnung für die Einheiten, die Sie auf dem EU-Markt bereitstellen.