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 définit le « produit comportant des éléments numériques » à l'Article 3(1) de façon à inclure les produits matériels, et définit le « matériel » à l'Article 3(5) comme «un système d'information électronique physique, ou des parties de celui-ci, capable de traiter, de stocker ou de transmettre des données numériques». Le règlement n'emploie le terme « HBOM » nulle part, mais l'obligation de documenter et d'exercer la diligence requise sur l'ensemble des composants, y compris matériels, découle directement de l'Article 3(1), de l'Article 13(5) et de l'Annexe I, Partie II, point (1).
Résumé
- Un HBOM est un inventaire structuré des composants physiques de votre produit, incluant le firmware embarqué dans chaque composant
- Le CRA n'impose pas d'HBOM en tant que tel, mais l'Article 3(1) étend le champ du CRA aux produits matériels, l'Article 13(5) exige la diligence requise sur tous les composants tiers, et l'Annexe I, Partie II, point (1) impose de documenter les « composants des produits comportant des éléments numériques »
- Le firmware est un logiciel au sens de l'Article 3(4) : il «consiste en un code informatique» et doit figurer dans votre SBOM aux côtés des entrées de composants matériels
- CycloneDX est le format unifié retenu en pratique :
type: devicecouvre le matériel physique,type: firmwarecouvre le logiciel embarqué, et les deux peuvent coexister dans un même document CycloneDX 1.6 - BSI TR-03183 ne couvre pas à ce stade la notion d'HBOM ; ses trois parties portent sur les nomenclatures logicielles et les rapports de vulnérabilités
- La Commission peut préciser le format et les éléments du SBOM par voie d'actes d'exécution (Article 13(24)), mais aucun mandat parallèle pour un format d'HBOM distinct n'existe dans le texte du CRA
Pourquoi l'HBOM est important au titre du CRA
Le champ d'application du CRA va au-delà des « produits logiciels ». L'Article 3(1) définit le « produit comportant des éléments numériques » comme :
«un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément»
L'Article 3(5) définit le « matériel » comme :
«un système d'information électronique physique, ou des parties de celui-ci, capable de traiter, de stocker ou de transmettre des données numériques»
Cette définition couvre le processeur sur votre circuit imprimé, le module sans fil sur votre carte de développement et l'élément sécurisé de votre passerelle IoT. Ces composants ne sont pas anecdotiques pour la conformité CRA ; ils entrent dans son champ d'application.
L'Article 13(5) impose ensuite une obligation concrète au fabricant :
«Aux fins du respect de l'obligation énoncée au paragraphe 1, les fabricants font preuve de diligence raisonnable lorsqu'ils intègrent dans des produits comportant des éléments numériques des composants obtenus auprès de tiers, de sorte que ces composants ne compromettent pas la cybersécurité du produit comportant des éléments numériques, y compris lors de l'intégration de composants de logiciels libres et ouverts qui n'ont pas été mis à disposition sur le marché dans le cadre d'une activité commerciale.»
Vous ne pouvez pas exercer la diligence requise sur des composants matériels que vous n'avez pas inventoriés. L'Annexe I, Partie II, point (1) va plus loin encore : le SBOM doit couvrir les « vulnérabilités et composants des produits comportant des éléments numériques ». Un produit contenant un module ESP32 contient aussi la pile firmware de ce module en tant que composant. L'HBOM est l'outil pratique pour capturer cet inventaire.
Aucune disposition du CRA n'exige un document intitulé HBOM. L'obligation est d'inventorier tous les composants, y compris matériels, dans le cadre de l'obligation SBOM existante au titre de l'Annexe I, Partie II, point (1). L'HBOM est une approche pratique pour satisfaire cette obligation dans les produits à forte composante matérielle, et non un document de conformité distinct.
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 |
| Mandat CRA | Explicite, Annexe I, Partie II, point (1) | Implicite, via le champ de l'Article 3(1) et la diligence de l'Article 13(5) |
| 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 | Annexe VII, point 2(b) et point 8 | 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 reflètent le jugement d'ingénierie en pratique, non une liste légale. Le CRA n'énumère pas les catégories de composants matériels. Vous devez inclure tout composant physique qui traite, stocke ou transmet des données numériques, car c'est ce que couvre l'Article 3(5).
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.
Une part significative des vulnérabilités IoT concerne des firmwares jamais mis à jour après la livraison. Documenter les versions firmware dans votre HBOM est le prérequis au suivi et à la remédiation. Vous ne pouvez pas surveiller ce que vous n'avez pas listé. Voir les erreurs SBOM courantes pour le schéma général.
Comment le firmware s'inscrit dans la définition CRA du logiciel
Le firmware est parfois traité comme une catégorie à part, distincte à la fois du matériel et du logiciel. Le CRA ne crée pas cette troisième catégorie. L'Article 3(4) définit le logiciel comme :
«la partie d'un système d'information électronique qui consiste en un code informatique»
Le firmware est constitué de code informatique. Par conséquent, au sens du CRA, le firmware est un logiciel. Il ne s'agit pas d'une interprétation qui va au-delà du texte ; elle découle directement de la définition.
Le mot « firmware » n'apparaît nulle part dans le texte du règlement CRA. C'est délibéré : la définition de l'Article 3(4) est suffisamment large pour l'englober, si bien qu'aucune classification distincte n'est nécessaire.
La conséquence pratique est directe. Le firmware s'exécutant 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é est soumise aux mêmes obligations de signalement de l'Article 14 que n'importe quelle 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 | Recommandation actuelle pour la conformité 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 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 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.
Questions fréquentes
Le CRA impose-t-il explicitement un HBOM ?
Non, le CRA n'emploie le terme « HBOM » nulle part. L'obligation de documenter les composants matériels découle indirectement : l'Article 3(1) fait entrer les produits matériels dans le champ du CRA, l'Article 13(5) exige la diligence requise sur tous les composants tiers, et l'Annexe I, Partie II, point (1) impose de documenter les « composants des produits comportant des éléments numériques ». L'HBOM est l'approche pratique pour satisfaire ces obligations dans le cas des produits matériels, et non une exigence réglementaire nommée.
Le firmware d'une puce Bluetooth est-il considéré comme un logiciel au titre du CRA ?
Oui. L'Article 3(4) définit le logiciel comme «la partie d'un système d'information électronique qui consiste en un code informatique». Le firmware est constitué de code informatique, donc il entre dans cette définition. Le mot « firmware » n'apparaît pas dans le CRA ; il n'en a pas besoin, car la définition de l'Article 3(4) le couvre déjà. Tout firmware s'exécutant sur un composant de votre produit est un composant logiciel de votre produit comportant des éléments numériques et doit figurer dans votre inventaire des composants.
BSI TR-03183 couvre-t-il l'HBOM ?
Non. BSI TR-03183 comporte trois parties : Partie 1 (Exigences générales), Partie 2 (SBOM) et Partie 3 (Rapports de vulnérabilités). Aucune d'elles ne couvre l'HBOM en tant que concept structurel. TR-03183-2 ne mentionne le firmware que comme un type de fichier de composant au sein d'une nomenclature logicielle, via le champ software_additionalPurpose: firmware. Pour documenter les composants matériels aux fins de conformité CRA, vous devez recourir au jugement d'ingénierie et aux types matériels natifs de CycloneDX, sans vous appuyer sur TR-03183 pour cette partie de votre inventaire.
Quelle version de CycloneDX prend en charge à la fois les composants logiciels et matériels ?
type: device est présent dans CycloneDX depuis la v1.1 (2018 ou antérieure). type: firmware a été ajouté en v1.2, publiée en mai 2020. Les deux sont donc disponibles dans toute version récente de CycloneDX. Pour les travaux CRA, ciblez la v1.6 ou ultérieure : BSI TR-03183-2 v2.1.0 (août 2025) a relevé son exigence minimale CycloneDX à 1.6, et la dernière version stable est la 1.7 (octobre 2025). Il n'existe pas de type: hardware dans aucune version de CycloneDX ; utilisez type: device pour les composants physiques.