Nomenclature des composants matériels (HBOM) et CRA

Votre SBOM recense les bibliothèques et paquets logiciels, mais qu'en est-il du firmware gravé dans votre puce Bluetooth ou du microcontrôleur au coeur de votre appareil ? Une nomenclature des composants matériels (HBOM) étend l'inventaire des composants aux puces physiques, aux modules et au firmware qui les anime. Le CRA n'emploie pas le terme « HBOM », mais les produits matériels, les composants matériels commercialisés séparément, la diligence sur les composants tiers et l'inventaire SBOM conduisent au même besoin pratique : savoir quels matériels et quels firmwares se trouvent dans le produit.

Pourquoi l'HBOM est important au titre du CRA

Le champ du CRA dépasse les produits purement logiciels. Les produits matériels, les composants matériels commercialisés séparément et le firmware à l'intérieur de ces composants relèvent tous du problème d'inventaire du produit.

C'est important pour les fabricants, car la diligence sur les composants ne se limite pas aux bibliothèques open source. Un processeur sur votre PCB, un module radio sur votre carte de développement ou un élément sécurisé dans votre passerelle IoT peut porter du firmware et des versions pertinentes pour la sécurité. Vous ne pouvez pas gérer ces risques sans les inventorier.

L'obligation SBOM est le support juridique de ce travail : elle demande les composants contenus dans les produits comportant des éléments numériques. Un module ESP32 fait donc entrer à la fois le module physique et sa pile firmware dans l'enregistrement des composants. L'HBOM est l'outil pratique pour capturer cet inventaire.

HBOM et SBOM : comparaison rapide

Dimension	SBOM	HBOM
Périmètre principal	Bibliothèques logicielles, paquets, frameworks	Composants physiques : puces, modules, éléments sécurisés
Couverture firmware	Peut inclure des entrées type: firmware	Firmware listé aux côtés de son composant matériel parent
Rôle conformité	Exigence explicite d'inventaire des composants	Extension pratique du même inventaire pour les produits matériels
Couverture BSI TR-03183	Oui, TR-03183-2 (v2.1.0, 2025)	Non, aucune des trois parties de TR-03183 ne couvre l'HBOM
Prise en charge CycloneDX	Toutes versions	type: device depuis v1.1 ; type: firmware depuis v1.2 (mai 2020)
Outil de génération typique	Syft, Trivy, cdxgen	Manuel ou fiches techniques des fournisseurs matériels ; pas d'outillage d'auto-génération mature à ce stade
Place dans le dossier technique	Dossier technique, section inventaire des composants	Même emplacement, dans le cadre de l'inventaire unifié des composants

Pour l'obligation SBOM complète, voir Exigences SBOM CRA. Pour la comparaison des formats, voir CycloneDX vs SPDX.

Ce qu'un HBOM doit contenir

Les catégories suivantes relèvent du jugement technique pratique, non d’une liste réglementaire. Le CRA n’énumère pas de catégories de composants matériels. Incluez tout composant physique qui traite, stocke ou transmet des données numériques, car ces composants peuvent affecter la cybersécurité.

Composants de traitement et de connectivité

Ce sont les entrées prioritaires, car leur firmware est le vecteur de vulnérabilités le plus probable :

• Processeur applicatif principal ou SoC (nom, fabricant, version/stepping, version firmware)
• Modules sans fil : Wi-Fi, Bluetooth, Zigbee, LoRa, cellulaire (chacun avec sa version firmware)
• Microcontrôleurs secondaires gérant des sous-systèmes spécifiques

Composants de sécurité

Le matériel de sécurité mérite ses propres entrées, car les vulnérabilités à ce niveau ont le plus fort impact :

• Puces Trusted Platform Module (TPM)
• Éléments sécurisés et modules de sécurité matériels
• Accélérateurs cryptographiques
• Tout composant qui stocke des clés, certificats ou identifiants au repos

Composants de stockage

Le stockage est pertinent lorsqu'il contient du code, une configuration ou des données sensibles :

• Mémoire flash contenant le bootloader ou le firmware
• Modules eMMC ou SD utilisés pour le stockage persistant
• EEPROM contenant la configuration de l'appareil

Pour chaque entrée, enregistrez au minimum : le nom du composant, le fabricant, la version matérielle ou le stepping, et la version firmware le cas échéant. Liez chaque entrée matérielle à son entrée firmware correspondante via les relations de dépendance CycloneDX.

Comment le firmware s'inscrit dans la définition CRA du logiciel

Le firmware est parfois traité comme une catégorie spéciale, distincte du matériel comme du logiciel. Pour le travail CRA, traitez le firmware comme un logiciel, car il s'agit de code informatique exécuté dans un système d'information électronique.

La conséquence pratique est simple. Le firmware exécuté sur une puce de votre produit est un composant logiciel de votre produit comportant des éléments numériques. Il doit figurer dans votre inventaire des composants. S'il contient une vulnérabilité, cette vulnérabilité suit le même flux de traitement et de notification que toute autre vulnérabilité logicielle.

CycloneDX comme format unifié SBOM et HBOM

CycloneDX prend en charge à la fois les composants matériels et logiciels dans un document unique. Vous n'avez pas besoin d'un format de fichier distinct pour votre HBOM.

Historique des types de composants (pertinent pour le matériel)

Version CycloneDX	Date de publication	Ajout pertinent
1.1 ou antérieure	2018	Introduction de type: device
1.2	2020-05-26	Ajout de type: firmware
1.5	2023-06-26	Ajout de type: device-driver
1.6	2024	Socle cible CRA
1.7	octobre 2025	Dernière version stable

À noter qu'il n'existe pas de type: hardware dans aucune version de CycloneDX. Le type correct pour une puce ou un module physique est type: device.

La spécification CycloneDX v1.2 précise, concernant la modélisation du matériel avec firmware :

« Un dispositif matériel tel qu'un processeur ou un jeu de puces. Un dispositif matériel contenant un firmware DEVRAIT inclure un composant pour le matériel physique lui-même, et un autre composant de type 'firmware' ou 'operating-system' (selon le cas), décrivant les informations relatives au logiciel s'exécutant sur le dispositif. »

Cette préconisation correspond directement au traitement CRA : le dispositif physique et son firmware sont des composants liés mais distincts, chacun avec sa propre identité et sa version.

Ciblez CycloneDX 1.6 ou ultérieur pour tout nouveau travail HBOM. BSI TR-03183-2 v2.1.0 (2025-08-20) a relevé son exigence minimale CycloneDX à 1.6. S'aligner sur 1.6 ou ultérieur permet de regrouper votre SBOM et votre HBOM dans le même document et de satisfaire TR-03183.

Exemple : dispositif ESP32 avec pile firmware

L'exemple ci-dessous présente un composant matériel réaliste (ESP32-WROOM-32E), son firmware (ESP-IDF) et une bibliothèque au sein du firmware (mbedtls), le tout dans un unique document CycloneDX 1.6 avec des relations de dépendance :

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

Le tableau dependencies rend explicite la relation entre matériel et firmware. Lorsque mbedtls publie un correctif pour un CVE, vous pouvez retracer quel dispositif est affecté et quelle version firmware mettre à jour.

Pour la comparaison des formats et les choix d'outillage, voir CycloneDX vs SPDX.

Pour aller plus loin