Comment Générer un Firmware SBOM : Outils Open Source 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 trois approches pratiques 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 opérationnaliser 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 de support.

CRA Link: Le règlement européen sur la cyber-résilience (Annexe I) exige des fabricants qu'ils gèrent les vulnérabilités tout au long du cycle de vie complet du produit. Un SBOM est le fondement pratique : vous ne pouvez pas corriger ce que vous n'avez pas catalogué. 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 les Firmware SBOMs Sont Plus Difficiles que les SBOMs Logiciels

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)

La bbclass create-spdx est incluse dans les versions récentes de Yocto et héritée par défaut via la configuration de distribution de Poky. Aucun outillage supplémentaire n'est requis. Après un build normal, trois fichiers sont générés :

# After a normal Yocto build
ls tmp/deploy/spdx/
# IMAGE-MACHINE.spdx.json         ← main SPDX document
# IMAGE-MACHINE.spdx.index.json   ← per-recipe component index
# IMAGE-MACHINE.spdx.tar.zst      ← full archive with all component SBOMs

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 :

# Add to 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

# Step 1: Generate the component manifest
make legal-info
# Output: output/legal-info/manifest.csv

# Step 2: Convert to CycloneDX SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: scan for CVEs at build time
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.

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 v3, la réécriture en Rust de l'outil original, offre une extraction plus rapide et un meilleur support des formats pour les images firmware modernes :

# Install binwalk v3
pip install binwalk

# Extract all embedded filesystems
binwalk -eM firmware.bin

# Check what got extracted
ls _firmware.bin.extracted/

# Check for encrypted partitions before proceeding
binwalk -E firmware.bin
# High entropy (above 0.9) regions indicate encrypted content

É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) :

# Check for package manager databases
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

# Run Syft on the extracted filesystem
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

# Install Intel's cve-bin-tool
pip install cve-bin-tool

# Scan extracted binary directory
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 :

# Clone and set up EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Run EMBA with SBOM output
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. Pour le CRA, générez du CycloneDX.

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.

Build → SBOM (CycloneDX) → Dependency-Track → CVE alert → VEX statement → ENISA report (if exploited)

Quatre é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. Émettre des déclarations VEX. Documentez si le produit est affected, not_affected, fixed, ou under_investigation. Voir le guide VEX.
4. 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

Deadline: Les principales obligations du CRA s'appliquent à partir du 11 décembre 2027. Le signalement des vulnérabilités à l'ENISA commence le 11 septembre 2026. Vous avez besoin d'un pipeline SBOM opérationnel avant septembre 2026. Voir le calendrier de mise en œuvre du CRA.

□ 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

Comment CRA Evidence Aide

CRA Evidence suit vos firmware SBOMs aux côtés des Passeports Numériques de Produits, des évaluations de conformité et de la documentation technique dans un espace de travail de conformité unique. Téléchargez directement votre SBOM CycloneDX vers une version de produit : il devient l'inventaire de composants en direct pour cette version.

Téléchargez votre premier SBOM ou commencez un essai gratuit.

Les firmware SBOMs ne sont pas optionnels sous le CRA : ils sont le fondement de tout ce que le règlement exige : connaître vos composants, surveiller les vulnérabilités et signaler les incidents. Choisissez le bon workflow pour votre situation, au moment du build si vous le pouvez, analyse binaire si vous le devez, et opérationnalisez-le avant la date limite de signalement de septembre 2026.