Générer un SBOM firmware : outils et workflows

Lorsqu'une vulnérabilité critique comme Log4Shell ou Heartbleed d'OpenSSL est apparue, toutes les équipes logicielles ont cherché à répondre à une seule question : sommes-nous affectés ? Pour les fabricants de firmware, cette question est presque impossible à résoudre sans un Software Bill of Materials. Un déploiement en conteneur peut interroger son gestionnaire de paquets en quelques secondes. Un binaire firmware installé dans des appareils de production sur un plancher d'usine ne le peut pas. Sans un firmware SBOM, vous n'avez pas d'inventaire, et sans inventaire, vous ne pouvez pas savoir ce que vous devez corriger, signaler ou remplacer.

Ce guide couvre les deux approches pour générer un firmware SBOM à l'aide d'outils open source, les défis qui rendent le firmware plus difficile que le logiciel classique, et comment utiliser le résultat pour une conformité CRA continue.

Qu'est-ce qu'un firmware SBOM ?

Un firmware SBOM est un inventaire structuré de tous les composants logiciels contenus dans une image firmware : paquets OS, bibliothèques partagées, bootloaders, modules noyau, pilotes, et tout blob binaire fourni par un tiers. Les mêmes éléments minimaux NTIA s'appliquent que pour tout SBOM logiciel : nom du fournisseur, nom du composant, version, identifiant unique, relations de dépendance, auteur des données SBOM, et horodatage, mais ils sont substantiellement plus difficiles à renseigner pour le firmware que pour une application web.

CycloneDX 1.6 définit firmware comme un type de composant distinct aux côtés du matériel de l'appareil, ce qui signifie que vous pouvez modéliser l'ensemble du produit, couches matérielle, firmware et logicielle, dans un seul document CycloneDX. Ceci est pertinent pour la classification des produits CRA : un routeur classifié comme produit comportant des éléments numériques doit avoir ses composants firmware suivis et surveillés pendant toute la période d’assistance.

L'Annexe I, Partie II du CRA exige des fabricants qu'ils :

"1) recensent et documentent les vulnérabilités et les composants des produits, notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits;"

Pour le firmware, les "dépendances de niveau supérieur" désignent chaque paquet OS, bibliothèque partagée, bootloader et module noyau dans l'image, pas seulement ce qu'un gestionnaire de paquets signale.

Voir les exigences SBOM sous le CRA pour le contexte réglementaire complet.

Un firmware SBOM n'est pas un Hardware Bill of Materials (HBOM). Le HBOM documente les composants physiques : PCB, puces, connecteurs. Un firmware SBOM documente le logiciel qui s'exécute sur ce matériel.

Pourquoi générer un SBOM de firmware est-il plus difficile qu'un SBOM logiciel standard ?

Générer un SBOM pour une application web signifie exécuter npm list --json ou pip list. Générer un SBOM pour un firmware signifie reconstruire un manifeste à partir d'artefacts qui n'ont jamais été conçus pour être inventoriés.

L'idée centrale : la génération d'un firmware SBOM est du rétro-ingénierie sous incertitude. Vous reconstituez un manifeste à partir d'artefacts, vous n'en générez pas un à partir des sources. Cette distinction détermine quel outil et quel workflow vous devez choisir.

Les deux approches fondamentales

Chaque workflow de firmware SBOM appartient à l'une de deux catégories :

1. SBOM au moment du build. Généré pendant le processus de build à partir des entrées exactes du système de build. Précision maximale. Nécessite l'accès au build source. Fonctionne avec Yocto et Buildroot.
2. SBOM post-build / analysé. Rétro-ingénierie à partir d'une image firmware binaire. Confiance moindre, mais souvent la seule option lorsque vous recevez le firmware d'un ODM ou auditez un appareil que vous n'avez pas fabriqué.

Le bon choix dépend entièrement de si vous contrôlez le build.

Approche 1: SBOM au moment du build avec Yocto ou Buildroot

Quand l'utiliser : Vous possédez le build firmware. C'est l'étalon-or en matière de précision.

Yocto : classe create-spdx (intégrée)

Le système de build OpenEmbedded génère des données SBOM SPDX par défaut en héritant de create-spdx dans INHERIT_DISTRO. Après un build d'image normal, le JSON SPDX principal apparaît dans le répertoire de déploiement de l'image :

# Après un build normal d'image Yocto
ls tmp/deploy/images/MACHINE/
# IMAGE-MACHINE.spdx.json         ← document SPDX principal
# Les métadonnées SBOM des recettes sont incluses pour les recettes de l'image

Le SBOM généré inclut tous les composants logiciels, les versions exactes, les licences, les URLs sources, les correctifs appliqués, et les relations de dépendance. Il n'y a aucune incertitude d'extraction : le SBOM est dérivé des mêmes entrées qui ont produit le binaire.

Pour effectuer également une analyse CVE au moment du build :

# Ajouter à local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Voir la documentation SBOM de Yocto pour les options de configuration complètes.

Buildroot : make legal-info + générateur CycloneDX

# Étape 1 : Générer le manifeste des composants
make legal-info
# Sortie : output/legal-info/manifest.csv

# Étape 2 : Convertir en SBOM CycloneDX
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optionnel : scanner les CVE au moment du build
python support/scripts/cve-check --nvd-path ./nvd-data/

Le convertisseur cyclonedx-buildroot produit une sortie JSON CycloneDX à partir du manifeste légal de Buildroot, le rendant immédiatement utilisable pour la conformité CRA.

Limitation connue : Les blobs binaires tiers ajoutés au build (firmware Wi-Fi, blobs GPU) ne sont suivis que si vous les ajoutez manuellement comme paquets Yocto ou Buildroot. Si votre système de build ne connaît pas un blob, le SBOM ne le connaîtra pas non plus.

Zephyr RTOS : west spdx

Zephyr génère des SBOM nativement avec la commande west spdx. Par défaut, elle génère des documents SPDX 2.3 au format tag-value :

west spdx --init -d build
west build -d build -b <your_board> <app_dir>
west spdx -d build

La sortie apparaît dans build/spdx/ et inclut app.spdx, zephyr.spdx, build.spdx et modules-deps.spdx. Les blobs binaires tiers ou les bibliothèques hors arbre non couverts par les métadonnées de build ne sont pas inclus. Documentez ces lacunes ou ajoutez-les manuellement comme composants externes.

Pour FreeRTOS et les plateformes RTOS bare-metal sans outillage SBOM natif, scannez le binaire compilé avec cve-bin-tool. Recensez manuellement la version du noyau RTOS et tout middleware inclus comme composants CycloneDX.

Approche 2: analyse d'un binaire existant

Quand l'utiliser : Vous avez reçu le firmware d'un ODM ou OEM, ou vous auditez un appareil que vous ne fabriquez pas vous-même.

Étape 1 : extraire le firmware avec binwalk

binwalk est l'outil open source standard pour décompresser le firmware :

# Installer binwalk
pip install binwalk

# Extraire tous les systèmes de fichiers embarqués
binwalk -eM firmware.bin

# Vérifier ce qui a été extrait
ls _firmware.bin.extracted/

# Vérifier les partitions chiffrées avant de continuer
binwalk -E firmware.bin
# Une entropie élevée (au-dessus de 0.9) indique du contenu chiffré

Note : ReFirmLabs maintient aussi une réécriture en Rust installable avec cargo install binwalk. Les deux versions fonctionnent pour les étapes ci-dessous ; les flags de commande sont les mêmes.

Étape 2a : identifier la distribution Linux et exécuter Syft

Si le système de fichiers extrait contient une distribution Linux embarquée standard (OpenWRT, basée Debian, basée Alpine) :

# Vérifier les bases de données des gestionnaires de paquets
ls _firmware.bin.extracted/squashfs-root/var/lib/dpkg/    # Debian-based
ls _firmware.bin.extracted/squashfs-root/lib/apk/db/      # Alpine/musl-based
ls _firmware.bin.extracted/squashfs-root/var/lib/opkg/    # OpenWRT/opkg

# Exécuter Syft sur le système de fichiers extrait
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft lit les bases de données des gestionnaires de paquets et génère un SBOM avec une haute confiance pour les composants packagés. Il ne voit pas les bibliothèques C/C++ compilées personnalisées qui ont été compilées directement dans le binaire.

Étape 2b : scanner les binaires pour les bibliothèques vulnérables connues avec cve-bin-tool

# Installer cve-bin-tool d'Intel
pip install cve-bin-tool

# Scanner le répertoire binaire extrait
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool utilise la correspondance de motifs de chaînes contre des signatures pour plus de 447 bibliothèques embarquées connues : OpenSSL, libpng, libxml2, expat, zlib, curl, et plus encore. Il couvre ce que Syft manque.

Étape 2c : analyse approfondie du firmware avec EMBA

Pour une analyse complète qui combine extraction, génération SBOM, et une revue de sécurité complète en un seul workflow :

# Cloner et configurer EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Exécuter EMBA avec sortie SBOM
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA gère l'extraction en interne, identifie les composants via plusieurs stratégies parallèles, génère un SBOM CycloneDX avec des données VEX, et produit un rapport de vulnérabilités complet. C'est l'option open source la plus complète pour l'analyse de firmware en boîte noire.

Référence des outils: comparaison rapide

SPDX vs CycloneDX : Les deux formats sont largement acceptés. CycloneDX a un type de composant firmware natif et un support VEX intégré, ce qui en fait le meilleur choix pour la conformité CRA. SPDX est préféré dans les contextes de conformité aux licences open source et constitue la sortie native de Yocto. Pour le CRA, générez du CycloneDX. Si vous utilisez Yocto, générez les deux. BSI TR-03183-2 v2.1.0, la ligne directrice technique allemande pour les SBOM sous le CRA, recommande CycloneDX 1.6+ ou SPDX 3.0.1+ et reste le document le plus cité par les auditeurs et organismes notifiés.

Gérer votre firmware SBOM dans le temps

Un SBOM ponctuel est un instantané. Pour la conformité CRA, vous avez besoin d'un SBOM opérationnel qui évolue avec votre produit.

Cinq étapes pour rendre cela opérationnel :

1. Régénérer à chaque build firmware. Intégrez la génération SBOM Yocto ou Buildroot dans votre pipeline CI/CD.

2. Pousser vers Dependency-Track. Surveille votre SBOM contre les flux CVE en direct et vous alerte sur les nouvelles vulnérabilités.

3. Signer le SBOM. Signez le fichier généré avec cosign de Sigstore avant de le stocker ou de le partager :

   cosign sign-blob sbom.cdx.json \
     --bundle sbom.cdx.json.bundle \
     --yes
   

   Stockez le bundle avec le SBOM. Les clients et les autorités peuvent le vérifier avec cosign verify-blob. Le CRA ne l'exige pas aujourd'hui, mais les cadres de sécurité de la chaîne d'approvisionnement comme SLSA et in-toto l'attendent.

4. Émettre des déclarations VEX. Documentez si le produit est affected, not_affected, fixed, ou under_investigation. Voir le guide VEX.

5. Signaler à l'ENISA. À partir de septembre 2026. Voir le guide de signalement ENISA.

Erreurs courantes à éviter

1. Se fier uniquement à Syft pour le firmware. Syft ne voit que les composants gérés par un gestionnaire de paquets. Combinez toujours avec cve-bin-tool ou blint.

2. Ignorer les régions à haute entropie. binwalk ignore silencieusement les partitions chiffrées. Effectuez d'abord une analyse d'entropie (binwalk -E) ; documentez les lacunes dans le SBOM.

3. Oublier le bootloader. U-Boot, coreboot et GRUB sont des composants firmware avec de véritables CVEs. Ils se trouvent en dehors du système de fichiers OS et sont manqués par la plupart des outils.

4. Traiter les SBOMs analysés comme faisant autorité. Un SBOM post-build est une approximation. Marquez les composants avec des niveaux de confiance en utilisant le champ evidence de CycloneDX.

5. Pas de plan de cycle de vie. De nouvelles CVEs sont publiées chaque jour. Sans Dependency-Track, votre SBOM devient obsolète en quelques semaines.

6. Lacune des blobs ODM. Exigez contractuellement la livraison du SBOM de tous les fournisseurs de firmware. Ce n'est pas optionnel sous le CRA.

Liste de contrôle de conformité CRA pour les fabricants de firmware

□ Identifier tous les composants firmware dans vos produits (le SBOM)
□ Choisir votre approche : au moment du build (Yocto/Buildroot) ou post-build (EMBA/Syft/cve-bin-tool)
□ Générer le SBOM au format JSON CycloneDX (utiliser aussi SPDX pour la conformité des licences open source)
□ Inclure le bootloader, le noyau, tous les paquets espace utilisateur, et tout blob vendeur (ou les documenter comme lacunes)
□ Ingérer le SBOM dans Dependency-Track (ou équivalent) pour une surveillance continue
□ Établir un workflow VEX pour documenter le statut d'exploitabilité des CVEs
□ Mettre en place un pipeline de signalement prêt pour l'ENISA à partir de septembre 2026
□ Exiger la livraison du SBOM de tous les fournisseurs de composants firmware (ODMs, fournisseurs de puces)
□ Régénérer le SBOM à chaque build firmware et suivre les changements dans le temps
□ Documenter votre méthodologie de génération SBOM à des fins d'audit