Generare un SBOM per il firmware: strumenti e flussi

Quando una vulnerabilità critica come Log4Shell o Heartbleed di OpenSSL è emersa, ogni team software si è affrettato a rispondere a una sola domanda: siamo interessati? Per i fabbricanti di firmware, quella domanda è quasi impossibile da rispondere senza un Software Bill of Materials. Un deployment in container può interrogare il suo gestore di pacchetti in pochi secondi. Un binario firmware installato in dispositivi di produzione su un piano di fabbrica non può farlo. Senza un firmware SBOM, non hai un inventario, e senza un inventario, non puoi sapere cosa devi correggere, segnalare o sostituire.

Questa guida copre i due percorsi per generare un firmware SBOM usando strumenti open source, le sfide che rendono il firmware più difficile del software tradizionale, e come usare il risultato per la conformità CRA continuativa.

Cos'è un Firmware SBOM?

Un firmware SBOM è un inventario strutturato di tutti i componenti software contenuti in un'immagine firmware: pacchetti OS, librerie condivise, bootloader, moduli kernel, driver, e qualsiasi blob binario fornito da terzi. Gli stessi elementi minimi NTIA si applicano come per qualsiasi SBOM software: nome del fornitore, nome del componente, versione, identificatore univoco, relazioni di dipendenza, autore dei dati SBOM, e timestamp, ma sono sostanzialmente più difficili da popolare per il firmware che per un'applicazione web.

CycloneDX 1.6 definisce firmware come un tipo di componente distinto accanto all'hardware del dispositivo, il che significa che puoi modellare l'intero prodotto, livelli hardware, firmware e software, in un singolo documento CycloneDX. Questo è rilevante per la classificazione dei prodotti CRA: un router classificato come prodotto con elementi digitali deve avere i suoi componenti firmware tracciati e monitorati per l'intero periodo di supporto.

L'Allegato I, Parte II del CRA richiede ai fabbricanti di:

"1) identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto;"

Per il firmware, "dipendenze di primo livello" significa ogni pacchetto OS, libreria condivisa, bootloader e modulo kernel nell'immagine, non solo ciò che riporta un gestore di pacchetti.

Vedere i requisiti SBOM sotto il CRA per il contesto normativo completo.

Un firmware SBOM non è un Hardware Bill of Materials (HBOM). L'HBOM documenta i componenti fisici: PCB, chip, connettori. Un firmware SBOM documenta il software in esecuzione su quell'hardware.

Perché Generare un SBOM di Firmware è Più Difficile di un SBOM Software Standard?

Generare un SBOM per un'applicazione web significa eseguire npm list --json o pip list. Generare uno per il firmware significa ricostruire un manifesto da artefatti che non sono mai stati progettati per essere inventariati.

L'intuizione fondamentale: la generazione di firmware SBOM è reverse engineering sotto incertezza. Stai ricostruendo un manifesto da artefatti, non generandone uno dagli input. Questa distinzione determina quale strumento e workflow dovresti scegliere.

I Due Approcci Fondamentali

Ogni workflow di firmware SBOM rientra in una di due categorie:

1. SBOM al momento della build. Generato durante il processo di build dagli input esatti del sistema di build. Massima accuratezza. Richiede accesso al build sorgente. Funziona con Yocto e Buildroot.
2. SBOM post-build / analizzato. Reverse-engineered da un'immagine firmware binaria. Minore confidenza, ma spesso l'unica opzione quando ricevi il firmware da un ODM o stai auditando un dispositivo che non hai fabbricato.

La scelta giusta dipende interamente dal fatto che tu controlli la build.

Approccio 1: SBOM al Momento della Build con Yocto o Buildroot

Quando usarlo: Possiedi la build firmware. Questo è il gold standard per l'accuratezza.

Yocto: classe create-spdx (integrata)

Il sistema di build OpenEmbedded genera dati SBOM SPDX per impostazione predefinita ereditando create-spdx in INHERIT_DISTRO. Dopo una build normale dell'immagine, il JSON SPDX principale appare nella directory di deploy dell'immagine:

# Dopo un normale build dell'immagine Yocto
ls tmp/deploy/images/MACHINE/
# IMAGE-MACHINE.spdx.json         ← documento SPDX principale
# I metadati SBOM delle ricette sono inclusi per le ricette nell'immagine

Lo SBOM generato include tutti i componenti software, le versioni esatte, le licenze, gli URL sorgente, le patch applicate e le relazioni di dipendenza. Non c'è incertezza di estrazione: lo SBOM è derivato dagli stessi input che hanno prodotto il binario.

Per eseguire anche l'analisi CVE al momento della build:

# Aggiungere a local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Vedere la documentazione SBOM di Yocto per le opzioni di configurazione complete.

Buildroot: make legal-info + generatore CycloneDX

# Passo 1: Generare il manifesto dei componenti
make legal-info
# Risultato: output/legal-info/manifest.csv

# Passo 2: Convertire in SBOM CycloneDX
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Opzionale: scansionare le CVE in fase di build
python support/scripts/cve-check --nvd-path ./nvd-data/

Il convertitore cyclonedx-buildroot produce un output JSON CycloneDX dal manifesto legale di Buildroot, rendendolo immediatamente utilizzabile per la conformità CRA.

Limitazione nota: I blob binari di terze parti aggiunti alla build (firmware Wi-Fi, blob GPU) vengono tracciati solo se li aggiungi manualmente come pacchetti Yocto o Buildroot. Se il tuo sistema di build non conosce un blob, nemmeno lo SBOM lo conoscerà.

Zephyr RTOS: west spdx

Zephyr genera SBOM in modo nativo tramite il comando west spdx. Per impostazione predefinita genera documenti SPDX 2.3 in formato tag-value:

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

L'output appare in build/spdx/ e include app.spdx, zephyr.spdx, build.spdx e modules-deps.spdx. I blob binari di terze parti o le librerie out-of-tree non coperti dai metadati di build non sono inclusi. Documenti queste lacune o li aggiunga manualmente come componenti esterni.

Per FreeRTOS e piattaforme RTOS bare-metal senza tooling SBOM nativo, scansioni il binario compilato con cve-bin-tool. Enumeri manualmente la versione del kernel RTOS e ogni middleware incluso come componenti CycloneDX.

Approccio 2: Analisi di un Binario Esistente

Quando usarlo: Hai ricevuto il firmware da un ODM o OEM, o stai auditando un dispositivo che non costruisci tu stesso.

Passo 1: Estrarre il firmware con binwalk

binwalk è lo strumento open source standard per decomprimere firmware:

# Installare binwalk
pip install binwalk

# Estrarre tutti i filesystem incorporati
binwalk -eM firmware.bin

# Verificare cosa è stato estratto
ls _firmware.bin.extracted/

# Verificare le partizioni cifrate prima di procedere
binwalk -E firmware.bin
# Entropia alta (sopra 0.9) indica contenuto cifrato

Passo 2a: Identificare la distribuzione Linux ed eseguire Syft

Se il filesystem estratto contiene una distribuzione Linux embedded standard (OpenWRT, basata su Debian, basata su Alpine):

# Verificare i database dei gestori di pacchetti
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

# Eseguire Syft sul filesystem estratto
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft legge i database dei gestori di pacchetti e genera uno SBOM con alta confidenza per i componenti pacchettizzati. Non vede le librerie C/C++ compilate personalizzate che sono state compilate direttamente nel binario.

Passo 2b: Scansionare i binari per le librerie vulnerabili note con cve-bin-tool

# Installare cve-bin-tool di Intel
pip install cve-bin-tool

# Scansionare la directory binaria estratta
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool utilizza la corrispondenza di pattern di stringhe contro firme per oltre 447 librerie embedded note: OpenSSL, libpng, libxml2, expat, zlib, curl, e altro. Copre ciò che Syft manca.

Passo 2c: Analisi approfondita del firmware con EMBA

Per un'analisi completa che combina estrazione, generazione SBOM, e una revisione completa della sicurezza in un singolo workflow:

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

# Eseguire EMBA con output SBOM
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA gestisce l'estrazione internamente, identifica i componenti attraverso multiple strategie parallele, genera uno SBOM CycloneDX con dati VEX, e produce un report completo sulle vulnerabilità. È l'opzione open source più completa per l'analisi di firmware black-box.

Riferimento degli Strumenti: Confronto Rapido

SPDX vs CycloneDX: Entrambi i formati sono ampiamente accettati. CycloneDX ha un tipo di componente firmware nativo e supporto VEX integrato, rendendolo la scelta migliore per la conformità CRA. SPDX è preferito nei contesti di conformità alle licenze open source ed è l'output nativo di Yocto. Per il CRA, generi CycloneDX. Se usa Yocto, generi entrambi. BSI TR-03183-2 v2.1.0, la linea guida tecnica tedesca per gli SBOM sotto il CRA, raccomanda CycloneDX 1.6+ o SPDX 3.0.1+ ed è il documento più citato da auditor e organismi notificati.

Gestire il Tuo Firmware SBOM nel Tempo

Un SBOM una tantum è un'istantanea. Per la conformità CRA, hai bisogno di uno SBOM operativo che si evolve con il tuo prodotto.

Cinque passi per rendere questo operativo:

1. Rigenerare ad ogni build firmware. Integra la generazione SBOM di Yocto o Buildroot nel tuo pipeline CI/CD.

2. Caricare su Dependency-Track. Monitora il tuo SBOM contro feed CVE in tempo reale e ti avvisa delle nuove vulnerabilità.

3. Firmare lo SBOM. Firmi il file generato con cosign di Sigstore prima di archiviarlo o condividerlo:

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

   Conservi il bundle insieme allo SBOM. Clienti e autorità possono verificarlo con cosign verify-blob. Il CRA non lo richiede oggi, ma i framework di sicurezza della supply chain come SLSA e in-toto lo prevedono.

4. Emettere dichiarazioni VEX. Documenti se il prodotto è affected, not_affected, fixed, o under_investigation. Vedere la guida VEX.

5. Segnalare all'ENISA. Da settembre 2026. Vedere la guida alla segnalazione ENISA.

Errori Comuni da Evitare

1. Fidarsi di Syft da solo per il firmware. Syft vede solo i componenti gestiti da un gestore di pacchetti. Combina sempre con cve-bin-tool o blint.

2. Ignorare le regioni ad alta entropia. binwalk salta silenziosamente le partizioni cifrate. Esegui prima l'analisi dell'entropia (binwalk -E); documenta le lacune nello SBOM.

3. Dimenticare il bootloader. U-Boot, coreboot e GRUB sono componenti firmware con vere CVE. Si trovano al di fuori del filesystem OS e vengono mancati dalla maggior parte degli strumenti.

4. Trattare gli SBOM analizzati come autorevoli. Un SBOM post-build è un'approssimazione. Contrassegna i componenti con livelli di confidenza usando il campo evidence di CycloneDX.

5. Nessun piano del ciclo di vita. Nuove CVE vengono pubblicate ogni giorno. Senza Dependency-Track, il tuo SBOM diventa obsoleto in poche settimane.

6. Lacuna dei blob ODM. Richiedi contrattualmente la consegna dello SBOM da tutti i fornitori di firmware. Questo non è opzionale sotto il CRA.

Lista di Controllo della Conformità CRA per i Produttori di Firmware

□ Identificare tutti i componenti firmware nei tuoi prodotti (lo SBOM)
□ Scegliere il tuo approccio: al momento della build (Yocto/Buildroot) o post-build (EMBA/Syft/cve-bin-tool)
□ Generare lo SBOM in formato JSON CycloneDX (usa anche SPDX per la conformità alle licenze open source)
□ Includere bootloader, kernel, tutti i pacchetti userspace, e qualsiasi blob vendor (o documentarli come lacune)
□ Importare lo SBOM in Dependency-Track (o equivalente) per il monitoraggio continuo
□ Stabilire un workflow VEX per documentare lo stato di sfruttabilità delle CVE
□ Configurare il pipeline di segnalazione pronto per l'ENISA da settembre 2026
□ Richiedere la consegna dello SBOM da tutti i fornitori di componenti firmware (ODM, vendor di chip)
□ Rigenerare lo SBOM ad ogni build firmware e tracciare le modifiche nel tempo
□ Documentare la tua metodologia di generazione SBOM per scopi di audit