HBOM : guide Hardware Bill of Materials pour le CRA

Votre SBOM recense les bibliothèques et paquets logiciels. Elle ne vous dira pas si le module radio de votre produit n'est plus pris en charge, si le bootloader peut être mis à jour, ou quel lot utilisait un jeu de puces de substitution.

C'est le rôle d'une nomenclature des composants matériels (HBOM). 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 pointent tous vers le même besoin pratique : savoir quels matériels et quels firmwares se trouvent dans le produit, et savoir si vous pouvez agir lorsqu'une vulnérabilité apparaît.

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 sans fil sur votre carte de développement ou un élément sécurisé dans votre passerelle IoT peut porter du firmware, des paramètres de sécurité et des dates de support. Vous ne pouvez pas gérer ces risques sans les inventorier.

L'obligation SBOM est là où cette preuve prend place habituellement. Le CRA demande aux fabricants d'identifier et documenter les composants et les vulnérabilités, notamment par une SBOM en format lisible par machine couvrant au moins les dépendances de niveau supérieur. 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 ce versant matériel de l'inventaire.

Les périodes de support font partie du même tableau. Le CRA vous permet de prendre en compte les périodes de support des composants tiers essentiels. Votre documentation technique doit alors contenir les informations utilisées pour définir la période de support du produit. Si un jeu de puces ou un module atteint sa fin de support avant la fin de la période de support de votre produit, l'HBOM est là où ce fait doit apparaître en premier.

À quoi ressemble un HBOM dans une chaîne d'approvisionnement réelle

Imaginez un importateur européen achetant une passerelle connectée à un ODM de Shenzhen. L'importateur n'a pas besoin de chaque résistance. Il a besoin des données de fabrication qui modifient le risque cyber : module radio, version de référence du firmware, statut de support et substitutions approuvées.

La différence clé est l'enregistrement tel que fabriqué. Un BOM de conception indique ce que l'ingénierie avait prévu d'utiliser. L'HBOM doit aussi capturer ce que l'usine a réellement expédié.

HBOM et SBOM : comparaison rapide

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

Ce qu'il faut inclure et où s'arrêter

Le CRA ne donne pas de liste réglementaire de champs HBOM. Il n'exige pas non plus de lister chaque pièce passive. Son socle d'inventaire des composants fixe un plancher de dépendances de niveau supérieur pour la SBOM, et le versant matériel doit suivre la même logique de risque.

Utilisez ce seuil : listez le matériel qui peut modifier le risque cyber du produit, le statut de vulnérabilité, le chemin de mise à jour ou les preuves de période de support.

Commencez par les composants qui remplissent l'une de ces fonctions :

• Traiter des données : processeurs principaux, SoC, microcontrôleurs, FPGA et ASIC liés à la sécurité.
• Stocker du code ou des secrets : flash, eMMC, Trusted Platform Modules (TPM), éléments sécurisés et contrôleurs de stockage.
• Transmettre des données : modules Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, cellulaire et GNSS.
• Démarrer ou mettre à jour le produit : gestionnaires de démarrage, bootloaders, UEFI, BIOS, firmware du contrôleur de carte mère (BMC) et contrôleurs de mise à jour.
• Appliquer la sécurité : accélérateurs cryptographiques, racines de confiance matérielles, coffres de clés et enclaves sécurisées.
• Exposer l'accès aux services : ports de débogage de production, JTAG, UART, SWD ou interfaces d'administration pour lesquels l'état de verrouillage en production est déterminant.

Les pièces passives telles que les résistances et condensateurs ordinaires n'entrent normalement pas dans l'HBOM, sauf si elles ont une fonction de sécurité, une identité numérique, un firmware ou un risque de substitution connu. Le critère pratique est simple : si une vulnérabilité, un avis de sécurité, une notice de fin de vie ou une substitution fournisseur pour la pièce modifierait votre décision de risque produit, listez-la.

Catégories matérielles prioritaires

Les catégories suivantes ne constituent pas une liste réglementaire. Ce sont les entrées les plus susceptibles de compter dans les preuves CRA, car elles portent du firmware, des clés, des interfaces ou des dépendances de support fournisseur.

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.

Les couches firmware souvent oubliées

Un seul champ « version firmware » est souvent trop superficiel. De nombreux produits contiennent plusieurs couches firmware avec des propriétaires, des chemins de mise à jour et des sources de vulnérabilités différents.

Les couches souvent manquées comprennent :

• Firmware de démarrage : ROM de démarrage, bootloader, gestionnaire de démarrage et configuration du démarrage sécurisé.
• Firmware radio : firmware Wi-Fi, Bluetooth, baseband cellulaire, Zigbee, Thread, LoRaWAN et NFC.
• Firmware de plateforme : UEFI, BIOS, BMC, option ROM et microcode CPU. NIST SP 800-193 traite le firmware de plateforme comme le matériel et le firmware fondamentaux nécessaires au démarrage et au fonctionnement d'un système.
• Firmware de contrôleur : contrôleurs de stockage, cartes réseau, contrôleurs d'alimentation, concentrateurs de capteurs et contrôleurs embarqués.
• Firmware de sécurité : firmware TPM, systèmes d'exploitation d'éléments sécurisés, applets d'éléments sécurisés, images d'environnement d'exécution de confiance (TEE) et firmware HSM.
• Logique programmable : bitstreams FPGA et configuration d'ASIC ou FPGA liés à la sécurité.
• Blobs binaires fournisseurs : blobs firmware fournis par le SDK, intégrés à l'image du produit mais maintenus par un fournisseur de puce ou de module.

Chaque couche doit être un composant distinct lorsqu'elle a sa propre version, son propre chemin de mise à jour, son propre mainteneur ou sa propre source d'avis. C'est ce qui vous permet de répondre à la question utile plus tard : quelles versions exactes du produit sont affectées par cet avis de sécurité firmware ?

Les champs qui rendent un HBOM utile

Le plancher réglementaire est plus étroit qu'un HBOM utile. Les champs ci-dessous ne sont pas tous obligatoires au titre du CRA. Ce sont les preuves qui vous permettent de gérer les vulnérabilités, les changements de fournisseurs et les décisions de période de support sans repartir de zéro.

Le firmware 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 signalement que toute autre vulnérabilité logicielle.

Lorsque le firmware ne peut pas être mis à jour

Certains firmwares ne peuvent pas être mis à jour sur le terrain. La ROM de démarrage peut être programmée par masque. Le code d'un élément sécurisé peut être contrôlé par le fournisseur. Un module radio peut ne pas exposer de chemin de mise à jour client. Cela ne fait pas disparaître le composant des preuves CRA.

Le CRA s'attend à ce que les vulnérabilités soient traitables par des mises à jour de sécurité lorsque cela s'applique. Si un composant matériel ne peut pas recevoir de mises à jour, documentez ce fait dans l'HBOM et dans l'évaluation des risques.

Enregistrez :

• Statut de mise à jour : mise à jour possible sur le terrain, par le fournisseur uniquement, en usine uniquement ou immuable.
• Raison : ROM, mémoire à programmation unique, module fournisseur verrouillé, contrainte de certification ou absence de canal de mise à jour exposé.
• Mesures compensatoires : isolation, fonctionnalité désactivée, restriction réseau, authentification renforcée ou atténuation au niveau du produit.
• Voie de réponse : mise à jour firmware, remplacement du module, rappel d'unités, avis client ou déclaration VEX not_affected lorsque la fonction vulnérable n'est pas accessible.
• Plage affectée : version du produit, révision du PCB, lot ou plage de numéros de série.

Si une vulnérabilité exploitable ne peut être ni corrigée ni atténuée, les obligations d'action corrective du CRA peuvent imposer des mesures correctives, retrait ou rappel. L'HBOM doit vous donner la plage de produits concernés avant que cette décision devienne urgente.

La fin de vie des composants et la période de support

La période de support du produit n'est pas seulement une promesse service client. Elle fait partie du modèle de gestion des vulnérabilités du CRA.

Le CRA vous permet de prendre en compte les périodes de support des composants tiers essentiels intégrés pour définir la période de support du produit. Votre documentation technique doit alors contenir les informations utilisées pour déterminer cette période de support. Les orientations CRA sur les exemples de matériels à longue durée de vie comprennent les cartes mères, microprocesseurs, routeurs, modems, commutateurs et systèmes de contrôle industriels, souvent utilisés plus de cinq ans.

La fin de vie des composants est donc un champ HBOM, pas seulement une note de processus d'achat.

Pour les composants essentiels, enregistrez :

• Date de fin de support fournisseur : mois et année si disponibles.
• Date de la dernière version firmware : date la plus récente à laquelle le fournisseur a publié une mise à jour firmware pertinente pour la sécurité.
• Source des avis : page PSIRT, flux CSAF, liste de diffusion ou contact fournisseur.
• Voie de remplacement : pièce à brochage compatible, plan de reconception, décision d'achat de dernière chance ou décision de fin de vie du produit.
• Couverture contractuelle : si les obligations de correctifs et de notifications du fournisseur couvrent la période de support du produit déclarée.

Si un module essentiel atteint sa fin de support avant votre produit, vous avez une décision à prendre avant la mise sur le marché. Prolongez la couverture fournisseur, choisissez une pièce différente, limitez la période de support du produit si justifié, ou documentez un plan de remplacement.

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)

À 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 traite le dispositif physique et le logiciel qui s'exécute dessus comme des composants distincts. Un processeur ou un jeu de puces doit être représenté comme un composant device, tandis que le code qui s'exécute dessus doit être représenté comme firmware ou operating-system, selon le cas.

Cette approche 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 propre 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.

CycloneDX dispose également de propriétés officielles cdx:device:* pour les détails matériels tels que la fonction, l'emplacement sur la carte, le type de dispositif, le numéro de série, le numéro de lot et les identifiants GS1. Utilisez ces noms lorsqu'ils correspondent. Si vous ajoutez des propriétés personnalisées pour la capacité de mise à jour ou l'état de sécurité, nommez-les clairement afin que les lecteurs ne les confondent pas avec la taxonomie officielle CycloneDX.

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 ou ultérieur avec des relations de dépendance :

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

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.

L'exemple omet délibérément un CPE matériel. Les chaînes CPE de la NVD sont spécifiques au produit, et les identifiants au niveau module ou die ne correspondent pas toujours. N'ajoutez un champ cpe que lorsque vous avez vérifié l'entrée NVD exacte pour le composant. Pour la comparaison des formats et les choix d'outillage, voir CycloneDX vs SPDX.

La correspondance des vulnérabilités matérielles fonctionne différemment

Les scanners de vulnérabilités logicielles font souvent la correspondance via le Package URL (PURL), le Common Platform Enumeration (CPE) ou les métadonnées de paquets. Le matériel est plus complexe.

PURL est construit autour des écosystèmes de paquets logiciels tels que npm, Maven, PyPI, Debian et RPM. Il est utile pour les paquets firmware ou les bibliothèques distribués comme des paquets. Ce n'est pas le bon identifiant pour une puce physique.

CPE peut représenter le matériel via part=h, et CycloneDX dispose d'un champ cpe de niveau supérieur sur les composants. Utilisez-le lorsqu'un CPE NVD vérifié existe. Ne supposez pas que chaque puce, module ou image firmware en possède un.

Pour les entrées matérielles sans CPE fiable, gardez une piste de correspondance lisible par un humain :

• nom exact du fabricant
• numéro de pièce fabricant
• révision ou stepping matériel
• nom et version du firmware
• URL de l'avis fournisseur ou du PSIRT
• contact fournisseur
• identifiant GS1 si disponible, en utilisant la propriété cdx:device:gs1:* correspondante

Surveillez ensuite les sources qui publient réellement des avis de sécurité matériels et firmware : la page PSIRT du fournisseur, la NVD, les vulnérabilités exploitées connues de la CISA, les avis CISA ICS le cas échéant, et les flux sectoriels pour les produits industriels, médicaux ou radio. Utilisez VEX ou des preuves équivalentes lorsqu'un composant est présent mais que la fonction vulnérable n'est pas accessible dans votre produit. Pour le flux de signalement, voir signalement des vulnérabilités et d'incidents CRA.

Ce qu'il faut demander aux fournisseurs et fabricants sous-traitants

Le fabricant est responsable de la diligence sur les composants. Pour le matériel, cela implique de demander les données de sécurité et de cycle de vie avant que la pièce ne soit intégrée au produit.

Demandez aux fournisseurs et fabricants sous-traitants :

• Identité exacte expédiée : numéro de pièce fabricant, révision matérielle, version firmware et toute substitution approuvée.
• Chemin de mise à jour : si le firmware peut être mis à jour sur le terrain, par le fournisseur uniquement, en usine uniquement ou s'il est immuable.
• Sécurité des mises à jour : signature, authentification, protection anti-retour arrière et détails de distribution sécurisée.
• Dates de support : fin de vie du composant, dernier achat possible, dernière version firmware et date de fin de support.
• Canal d'avis : page PSIRT, liste de diffusion de sécurité, flux CSAF, portail de support ou contact nommé.
• Statut de vulnérabilités connues : avis en cours, versions firmware corrigées et toute déclaration VEX ou CSAF.
• Traçabilité de production : BOM conforme à l'état réellement fabriqué, par lot de production, lot ou plage de numéros de série pour les cas de substitutions possibles.
• Route d'approvisionnement : source du distributeur agréé ou du fabricant de composants d'origine lorsque le risque de contrefaçon ou de marché gris est pertinent.

Un BOM de conception n'est pas suffisant lorsqu'un fabricant sous-traitant (ODM) ou un sous-traitant peut substituer des modules en cours de production. Vous avez besoin de l'enregistrement des composants tel que fabriqué pour les unités que vous mettez sur le marché européen.

Pour aller plus loin

1. Définissez le seuil HBOM : incluez le matériel qui traite, stocke, transmet, démarre, met à jour, applique la sécurité, expose l'accès aux services ou affecte les preuves de période de support.
2. Demandez les données fournisseurs avant la mise en production : numéro de pièce, révision, version firmware, chemin de mise à jour, canal d'avis et date de fin de support.
3. Créez un document CycloneDX 1.6 ou ultérieur avec une entrée type: device par composant matériel et une entrée type: firmware par image firmware. Liez-les avec dependencies.
4. Enregistrez la capacité de mise à jour et la fin de vie des composants essentiels. Si un module essentiel ne peut être mis à jour ou atteint sa fin de vie avant la fin de la période de support de votre produit, documentez l'atténuation ou la voie de remplacement.
5. Surveillez les avis fournisseurs, la NVD, les vulnérabilités exploitées connues de la CISA et les flux sectoriels pour chaque composant essentiel. Les recherches dans la base de données CVE peuvent manquer les problèmes matériels et firmware pour lesquels les identifiants sont faibles.
6. Placez la SBOM unifiée, y compris les entrées matérielles, dans votre documentation technique, où elle doit être prête pour les autorités de surveillance du marché sur demande. Si vous préférez ne pas gérer manuellement l'ingestion SBOM et HBOM au fil des versions produit, CRA Evidence gère l'ingestion CycloneDX et le suivi des composants sur votre portefeuille de produits.