Software Bill of Materials (SBOM)
Una Software Bill of Materials (SBOM) è un inventario strutturato e leggibile dalle macchine che elenca ogni componente software, libreria, framework e dipendenza inclusi in un prodotto — compresi i numeri di versione, i fornitori e le informazioni sulle licenze. Funziona come un‘“etichetta nutrizionale” per il software, consentendo alle organizzazioni di individuare e rimediare alle vulnerabilità note lungo l’intera catena di approvvigionamento del software.
Fatti chiave
| Dettaglio | Informazione |
|---|---|
| Formati principali | SPDX (ISO/IEC 5962:2021), CycloneDX (OWASP) |
| Imposto da | Cyber Resilience Act dell’UE (2024/2847), Executive Order 14028 degli USA |
| Scadenza CRA | 11 dicembre 2027 (obblighi completi) |
| Si applica a | Tutti i prodotti con elementi digitali venduti sul mercato dell’UE |
| Ambito | Firmware, OS, middleware, codice applicativo, librerie open-source |
Perché la SBOM è importante per l’hardware?
I prodotti hardware embedded — dispositivi IoT, controllori industriali, sistemi basati su FPGA — vengono forniti con stack di firmware che includono da decine a centinaia di componenti software: kernel RTOS, stack di rete, librerie crittografiche, bootloader e driver. Quando viene scoperta una vulnerabilità in uno di questi componenti (es. un CVE critico di OpenSSL), la SBOM consente:
- Valutazione immediata dell’impatto — Determinare nel giro di ore quali prodotti e versioni di firmware sono interessati.
- Patching mirato — Distribuire aggiornamenti OTA solo ai dispositivi interessati, anziché riprogrammare indiscriminatamente interi parchi dispositivi.
- Evidenza normativa — Fornire ad auditor e autorità di vigilanza del mercato una prova documentata dei processi di gestione delle vulnerabilità.
- Trasparenza verso il cliente — Consentire agli acquirenti aziendali di valutare il rischio della catena di approvvigionamento prima dell’acquisto.
Senza una SBOM, un fabbricante che scopre che una libreria utilizzata tre release di firmware fa presenta una vulnerabilità critica si trova ad affrontare settimane di analisi forense per determinare l’esposizione — tempo che né i regolatori né gli attaccanti concedono.
Formati SBOM
| Formato | Mantenuto da | Punti di forza | Ecosistema |
|---|---|---|---|
| SPDX 2.3 | Linux Foundation (standard ISO) | Licenze complete, standardizzato ISO | GitHub, Yocto, Zephyr |
| CycloneDX 1.6 | OWASP | Leggero, focalizzato sulle vulnerabilità, supporto VEX | Strumenti OWASP, Dependency-Track |
Entrambi i formati supportano la serializzazione JSON e XML. Per il firmware embedded, CycloneDX è spesso preferito grazie al supporto nativo per i descrittori dei componenti hardware e per le dichiarazioni Vulnerability Exploitability eXchange (VEX).
SBOM nel ciclo di vita del firmware embedded
1. Fase di build
+-- La toolchain genera automaticamente la SBOM dal manifest di build
+-- Acquisisce: nome del componente, versione, hash, licenza, fornitore
+-- Strumenti: Yocto (create-spdx), Zephyr (west spdx), syft, trivy
2. Fase di release
+-- SBOM allegata all'artefatto di release del firmware
+-- Firmata insieme al binario del firmware
+-- Archiviata in un repository di artefatti sotto controllo di versione
3. Fase di monitoraggio
+-- Scansione continua dei CVE rispetto ai componenti della SBOM
+-- Avvisi automatici quando nuove vulnerabilità corrispondono alle voci della SBOM
+-- Strumenti: Dependency-Track, Grype, OSV.dev
4. Risposta agli incidenti
+-- La consultazione della SBOM individua tutti i prodotti/versioni interessati
+-- Pubblicazione di dichiarazione VEX: interessato, non interessato o sotto indagine
+-- Aggiornamento OTA inviato al parco di dispositivi interessati
Requisiti del CRA per la SBOM
Ai sensi del Cyber Resilience Act dell’UE, i fabbricanti devono:
- Generare una SBOM leggibile dalle macchine per ogni prodotto con elementi digitali.
- Mantenere la SBOM per tutta la durata di vita supportata del prodotto (minimo 5 anni).
- Aggiornare la SBOM a ogni release di firmware.
- Monitorare i componenti elencati per le vulnerabilità di nuova scoperta.
- Segnalare all’ENISA le vulnerabilità attivamente sfruttate entro 24 ore.
- Fornire la SBOM alle autorità di vigilanza del mercato su richiesta.
Errori comuni
| Errore | Perché è importante | Approccio corretto |
|---|---|---|
| Creazione manuale della SBOM | Soggetta a omissioni, impossibile da mantenere | Automatizzare la generazione dal sistema di build |
| Tracciare solo le dipendenze dirette | Le dipendenze transitive contengono il 60–80% delle vulnerabilità | Includere l’intero albero delle dipendenze |
| SBOM una tantum al lancio del prodotto | Obsoleto nel giro di settimane con l’emergere di nuovi CVE | Monitoraggio continuo con avvisi automatici |
| Nessuna dichiarazione VEX | Impossibile comunicare se un CVE incide realmente sul prodotto | Pubblicare le VEX insieme alla SBOM per ogni advisory |
Termini correlati
- CRA — Il regolamento dell’UE che impone la SBOM per i prodotti connessi.
- Secure Boot — Verifica dell’integrità del firmware, complementare al tracciamento della catena di approvvigionamento tramite SBOM.
- IoT — Dispositivi connessi i cui stack di firmware traggono il massimo beneficio dalla trasparenza della SBOM.
- CVE — Gli identificatori di vulnerabilità rispetto ai quali il monitoraggio della SBOM effettua le corrispondenze.
Il nostro servizio di monitoraggio SBOM e vulnerabilità automatizza l’intero ciclo di vita della SBOM — dalla generazione in fase di build alla scansione continua dei CVE e ai report ENISA preformattati — affinché il vostro firmware embedded resti conforme senza sforzo manuale.
Riferimenti ufficiali
- Regolamento (UE) 2024/2847 (CRA) — Articoli 13 e 14 sulla SBOM — EUR-Lex (impone la generazione e la manutenzione della SBOM)
- SPDX — Specifica ISO/IEC 5962:2021 — Linux Foundation (standard del formato SBOM principale)