Hardware Bill of Materials (HBOM) en CRA-compliance

Uw SBOM vermeldt bibliotheken en softwarepakketten, maar wat met de firmware die in uw Bluetooth-chip is gebrand of de microcontroller in het hart van uw apparaat? Een Hardware Bill of Materials (HBOM) breidt de componenteninventaris uit naar fysieke chips, modules en de firmware die daarop draait. De CRA gebruikt de term "HBOM" niet, maar hardwareproducten, afzonderlijk verhandelde hardwarecomponenten, due diligence op componenten van derden en de SBOM-componenteninventaris wijzen op dezelfde praktische behoefte: weten welke hardware en firmware in het product zitten.

Waarom HBOM relevant is onder de CRA

Het toepassingsgebied van de CRA is breder dan alleen softwareproducten. Hardwareproducten, afzonderlijk verhandelde hardwarecomponenten en de firmware in die componenten horen allemaal bij het inventarisatieprobleem van het product.

Dat is belangrijk voor fabrikanten, omdat componentdue diligence niet beperkt is tot opensourcebibliotheken. Een processor op uw PCB, een draadloze module op uw ontwikkelbord of een secure element in uw IoT-gateway kan firmware en beveiligingsrelevante versies meebrengen. Zonder inventaris kunt u die risico's niet beheren.

De SBOM-verplichting is de juridische plek voor dit werk: zij vraagt om de componenten die in producten met digitale elementen zitten. Een ESP32-module brengt dus zowel de fysieke module als de firmwarestack in het componentenrecord. Een HBOM is het praktische hulpmiddel om die inventaris vast te leggen.

HBOM versus SBOM in een oogopslag

Dimensie	SBOM	HBOM
Primair toepassingsgebied	Softwarebibliotheken, pakketten, frameworks	Fysieke componenten: chips, modules, secure elements
Firmwaredekking	Kan type: firmware-vermeldingen bevatten	Firmware naast de bovenliggende hardwarecomponent vermeld
Compliance-rol	Expliciete componenteninventarisvereiste	Praktische uitbreiding van diezelfde inventaris voor hardwareproducten
BSI TR-03183-dekking	Ja, TR-03183-2 (v2.1.0, 2025)	Nee, geen van de drie TR-03183-delen dekt HBOM
CycloneDX-ondersteuning	Alle versies	type: device sinds v1.1; type: firmware sinds v1.2 (mei 2020)
Gangbaar generatiehulpmiddel	Syft, Trivy, cdxgen	Handmatig of via hardware-leveranciersdatasheets; nog geen volwassen automatische generatietools
Plaats in technisch dossier	Technisch dossier, sectie componenteninventaris	Zelfde locatie, als onderdeel van de verenigde componenteninventaris

Voor de volledige SBOM-verplichting, zie CRA SBOM-vereisten. Voor formatvergelijking, zie CycloneDX versus SPDX.

Wat u in een HBOM opneemt

De volgende categorieën zijn gebaseerd op praktisch technisch oordeel, niet op een wettelijke lijst. De CRA somt geen hardwarecomponentcategorieën op. Neem elk fysiek component op dat digitale gegevens verwerkt, opslaat of verzendt, omdat zulke componenten de cyberbeveiliging kunnen beïnvloeden.

Verwerkings- en connectiviteitscomponenten

Dit zijn de hoogstprioritaire vermeldingen omdat hun firmware het meest waarschijnlijke aanvalsvector is voor kwetsbaarheden:

• Hoofd-applicatieprocessor of SoC (naam, fabrikant, versie/stepping, firmwareversie)
• Draadloze modules: Wi-Fi, Bluetooth, Zigbee, LoRa, mobiel (elk met firmwareversie)
• Secundaire microcontrollers die specifieke subsystemen aansturen

Beveiligingscomponenten

Beveiligingshardware verdient eigen vermeldingen omdat kwetsbaarheden hier de grootste impact hebben:

• Trusted Platform Module (TPM)-chips
• Secure elements en hardware security modules
• Cryptografische accelerators
• Elk component dat sleutels, certificaten of inloggegevens in rust opslaat

Opslagcomponenten

Opslag is relevant wanneer het code, configuratie of gevoelige gegevens bevat:

• Flashgeheugen met bootloader of firmware
• eMMC- of SD-modules voor permanente opslag
• EEPROM met apparaatconfiguratie

Leg voor elke vermelding minimaal vast: componentnaam, fabrikant, hardwareversie of stepping, en firmwareversie waar van toepassing. Koppel elke hardwarevermelding aan de bijbehorende firmwarevermelding via CycloneDX-afhankelijkheidsrelaties.

Hoe firmware past binnen de CRA-definitie van software

Firmware wordt soms behandeld als een aparte categorie, onderscheiden van zowel hardware als software. Voor CRA-werk behandelt u firmware als software, omdat het computercode is die draait in een elektronisch informatiesysteem.

De praktische implicatie is eenvoudig. Firmware die draait op een chip in uw product is een softwarecomponent van uw product met digitale elementen. Het moet in uw componenteninventaris staan. Als het een kwetsbaarheid bevat, volgt die kwetsbaarheid dezelfde kwetsbaarheidsbehandeling en meldingsstroom als elke andere softwarekwetsbaarheid.

CycloneDX als geunificeerd SBOM- en HBOM-formaat

CycloneDX verwerkt zowel hardware- als softwarecomponenten in één document. U hebt geen apart bestandsformaat nodig voor uw HBOM.

Geschiedenis van componenttypen (relevant voor hardware)

CycloneDX-versie	Releasedatum	Relevante toevoeging
1.1 of eerder	2018	type: device geïntroduceerd
1.2	2020-05-26	type: firmware toegevoegd
1.5	2023-06-26	type: device-driver toegevoegd
1.6	2024	CRA-baseline
1.7	oktober 2025	Meest recente stabiele release

Er bestaat geen type: hardware in enige CycloneDX-versie. Het juiste type voor een fysieke chip of module is type: device.

De CycloneDX v1.2-specificatiegids voor het modelleren van hardware met firmware stelt:

"Een hardwareapparaat zoals een processor of chipset. Een hardwareapparaat met firmware MOET een component bevatten voor de fysieke hardware zelf, en een ander component van het type 'firmware' of 'operating-system' (afhankelijk van wat van toepassing is), met informatie over de software die op het apparaat draait."

Deze richtlijn sluit direct aan op de behandeling in de CRA: het fysieke apparaat en zijn firmware zijn gerelateerde maar afzonderlijke componenten, elk met hun eigen identiteit en versie.

Richt u op CycloneDX 1.6 of later voor nieuw HBOM-werk. BSI TR-03183-2 v2.1.0 (2025-08-20) heeft de minimale CycloneDX-vereiste verhoogd naar 1.6. Aansluiting bij 1.6 of later houdt uw SBOM en HBOM in hetzelfde document en voldoet aan TR-03183.

Voorbeeld: ESP32-apparaat met firmwarestack

Het onderstaande voorbeeld toont een realistisch hardwarecomponent (ESP32-WROOM-32E), de bijbehorende firmware (ESP-IDF) en een bibliotheek binnen de firmware (mbedtls), alles in één CycloneDX 1.6-of-later-document met afhankelijkheidsrelaties:

{
  "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"] }
  ]
}

De dependencies-array maakt de relatie tussen hardware en firmware expliciet. Wanneer mbedtls een CVE-patch uitbrengt, kunt u traceren welk apparaat getroffen is en welke firmwareversie moet worden bijgewerkt.

Voor formatvergelijking en keuze van tools, zie CycloneDX versus SPDX.

Wat u nu kunt doen