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 si ha un inventario, e senza un inventario non si può sapere cosa 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 può 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 si riceve il firmware da un ODM o si sta auditando un dispositivo che non si è fabbricato.

La scelta giusta dipende interamente dal fatto che si 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:

# Yocto 6.0 e successivi: aggiungere a local.conf
OE_FRAGMENTS += "core/yocto/sbom-cve-check"

# Yocto 5.x e precedenti: aggiungere a local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Yocto 6.0 ha rimosso la classe cve-check e l'ha sostituita con sbom-cve-check.

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

Buildroot: output CycloneDX nativo oppure make legal-info

Le versioni recenti di Buildroot generano direttamente uno SBOM CycloneDX (manuale di Buildroot 2026.08, sezione 8.9):

# Generare lo SBOM CycloneDX
make show-info | utils/generate-cyclonedx > sbom.cdx.json

# Opzionale: scansionare lo SBOM per le CVE
cat sbom.cdx.json | support/scripts/cve-check --nvd-path dl/buildroot-nvd/

In alternativa si può convertire il manifesto legale:

# 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

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 si aggiunge manualmente come pacchetti Yocto o Buildroot. Se il 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: ha ricevuto il firmware da un ODM o da un OEM, oppure sta verificando un dispositivo che non ha costruito.

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
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 -f /path/to/firmware.bin -l /tmp/emba-log/ -p ./scan-profiles/default-sbom.emba

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 nel tempo lo SBOM del firmware

Un SBOM una tantum è un'istantanea. Per la conformità CRA serve uno SBOM operativo che si evolve con il prodotto.

Cinque passi per rendere questo operativo:

1. Rigenerare ad ogni build firmware. Integri la generazione SBOM di Yocto o Buildroot nella pipeline CI/CD, così che ogni rilascio produca automaticamente uno SBOM aggiornato.

2. Caricare su Dependency-Track. Dependency-Track di OWASP monitora lo SBOM rispetto a feed CVE in tempo reale (NVD, OSV, GitHub Advisory) e segnala quando nuove vulnerabilità interessano componenti esistenti.

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. Quando viene trovata una CVE in un componente, documenti se il prodotto è affected, not_affected, fixed, o under_investigation. Il formato è CycloneDX VEX e Dependency-Track gestisce il flusso. Per il processo si veda la guida VEX.

5. Segnalare la vulnerabilità. Da settembre 2026 il CRA richiede di notificare le vulnerabilità attivamente sfruttate entro 24 ore, contemporaneamente al CSIRT designato come coordinatore e a ENISA tramite la Piattaforma unica di segnalazione. Il flusso esatto è nella guida alla segnalazione ENISA. Dependency-Track insieme al VEX è la base operativa che serve per essere pronti.

Errori Comuni da Evitare

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

2. Ignorare le regioni ad alta entropia. binwalk salta silenziosamente le partizioni cifrate. Esegua prima l'analisi dell'entropia (binwalk -E) e documenti 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, lo SBOM diventa obsoleto in poche settimane.

6. Lacuna dei blob ODM. Richieda contrattualmente la consegna dello SBOM a 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 propri prodotti (lo SBOM)
□ Scegliere il proprio approccio: al momento della build (Yocto/Buildroot) o post-build (EMBA/Syft/cve-bin-tool)
□ Generare lo SBOM in formato JSON CycloneDX (si usi 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 propria metodologia di generazione SBOM per scopi di audit