Supply chain del software
SBOM: cos’è una distinta base del software e come si crea
Una SBOM (distinta base del software, in inglese software bill of materials) è un registro formale e leggibile da un dispositivo automatico dei componenti di un software e delle relazioni tra di essi. Il Cyber Resilience Act impone ai fabbricanti di redigerne una, che includa almeno le dipendenze di primo livello, in un formato di uso comune come CycloneDX o SPDX.
Piano Free, nessuna carta richiesta.
Cos’è una SBOM?
Pensala come l’elenco degli ingredienti di un prodotto. Per ogni componente registra un nome, una versione e, idealmente, un identificatore univoco come un package URL, insieme al fornitore e alle relazioni tra i componenti: quale libreria ne richiama un’altra. Il CRA la definisce come un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software di un prodotto.
Una SBOM non dice se un componente è vulnerabile. È l’inventario che permette di rispondere a questa domanda, oggi e ogni volta che viene pubblicata una nuova vulnerabilità.
La SBOM è obbligatoria?
Per i fabbricanti di prodotti che rientrano nell’ambito del Cyber Resilience Act, sì. L’allegato I, parte II, impone loro di identificare e documentare le vulnerabilità e i componenti, anche redigendo una SBOM in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello. La SBOM fa parte della documentazione tecnica e va fornita a un’autorità di vigilanza del mercato su sua richiesta motivata; il regolamento non impone di pubblicarla.
La Commissione può specificare il formato e gli elementi mediante un atto di esecuzione. Fino ad allora, CycloneDX e SPDX sono i formati che la maggior parte degli strumenti produce e accetta.
CycloneDX vs SPDX
Entrambi sono standard aperti ed entrambi sono ampiamente supportati. La scelta dipende di solito dagli strumenti che usano già i tuoi clienti e fornitori; molti team li mantengono entrambi.
| CycloneDX | SPDX | |
|---|---|---|
| Gestito da | OWASP ed Ecma International (ECMA-424) | Linux Foundation; pubblicato come ISO/IEC 5962:2021 |
| Origini | Sicurezza delle applicazioni e rischio della supply chain | Conformità delle licenze |
| Serializzazioni | JSON, XML, Protocol Buffers | JSON, tag-value, RDF, YAML e altri |
| Dati sulle vulnerabilità | Supporto VEX integrato | Sono comuni documenti VEX separati |
Come generare una SBOM
La SBOM più accurata si ottiene da ciò che distribuisci davvero. Per il codice sorgente significa i lockfile e i manifest che la tua build risolve; per le immagini firmware e container significa i file contenuti nell’immagine, perché gli strumenti che operano in fase di build possono non vedere i pacchetti aggiunti più avanti nella pipeline.
- Generala nella pipeline di build, per ogni release, non a mano.
- Scansiona l’artefatto finale oltre al codice sorgente, comprese le immagini firmware e container.
- Registra versioni esatte e package URL, non intervalli di versioni.
- Conserva la SBOM di ogni versione ancora supportata: ti servirà quando comparirà una nuova vulnerabilità.
- Ricontrolla le SBOM archiviate rispetto ai nuovi dati sulle vulnerabilità invece di ricompilare le vecchie release.
Cosa fare con una SBOM una volta che ce l’hai
Una SBOM dimostra il suo valore quando viene pubblicata una nuova vulnerabilità. Con un inventario per ogni release, la domanda «quali dei nostri prodotti contengono questo componente?» richiede minuti invece che giorni. Questa rapidità conta ai sensi dell’articolo 14 del CRA, dove una vulnerabilità attivamente sfruttata fa partire un orologio di segnalazione di 24 ore.
Abbinala a dichiarazioni VEX (Vulnerability Exploitability eXchange) per registrare quali delle vulnerabilità elencate non riguardano il prodotto e perché, così che clienti e autorità vedano la decisione oltre all’inventario.
Disponibile oggi in KROMSE
KROMSE produce e legge SBOM già oggi.
- Ogni scansione di un repository, di un’immagine container o di un’immagine firmware basata su Linux produce una SBOM CycloneDX JSON e una SPDX JSON da scaricare.
- Carica SBOM CycloneDX (JSON da 1.2 a 1.7, o XML) o SPDX 2.2 e 2.3 (JSON o tag-value), oltre ai manifest di build Yocto e Buildroot; ogni caricamento viene confrontato automaticamente con OSV.dev.
- Invia le SBOM dalla CI con un token API dello spazio di lavoro; sono disponibili snippet per GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, Yocto, Buildroot, Zephyr ed ESP-IDF.
- Esportazione VEX in CycloneDX 1.6 VEX e OpenVEX, con ogni dichiarazione VEX importata accettata da una persona.
- Nei piani a pagamento, l’ultima SBOM di ogni prodotto viene ricontrollata su OSV ogni sei ore.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q1 2027Componenti hardware. KROMSE confronterà i componenti hardware del tuo prodotto con gli avvisi di sicurezza hardware pubblicati.
- In arrivo · Q1 2027Sicurezza di agenti e modelli IA. KROMSE produrrà una distinta base dell’IA (AI bill of materials), esaminerà gli strumenti e i permessi che i tuoi agenti possono usare e rileverà i file di modello non sicuri.
Domande frequenti
Cosa significa SBOM?
Software bill of materials, in italiano distinta base del software: un elenco formale e leggibile da un dispositivo automatico dei componenti di un software, con versioni, fornitori e relazioni. Funziona come un elenco degli ingredienti ed è il punto di partenza per scoprire se un prodotto contiene un componente vulnerabile.
Il Cyber Resilience Act richiede una SBOM?
Sì. L’allegato I, parte II, impone ai fabbricanti di prodotti con elementi digitali di redigere una SBOM in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello. Fa parte della documentazione tecnica e viene fornita alle autorità di vigilanza del mercato su richiesta motivata.
Quale formato SBOM dovrei usare?
CycloneDX e SPDX sono entrambi di uso comune, leggibili da un dispositivo automatico e ampiamente supportati. Scegli quello che si aspettano i tuoi clienti e i tuoi strumenti, oppure producili entrambi. La coerenza tra le release conta più della scelta del formato.
Devo pubblicare la mia SBOM?
Il CRA non impone ai fabbricanti di rendere pubblica la SBOM. Deve far parte della documentazione tecnica ed essere fornita all’autorità di vigilanza del mercato che la richieda. Molte aziende condividono le SBOM con i clienti in base a un contratto.
Posso creare una SBOM per un firmware?
Sì. Per il firmware basato su Linux l’approccio affidabile è estrarre l’immagine ed elencare i pacchetti e i binari che contiene, anziché affidarsi solo ai file di build. KROMSE lo fa già oggi per le immagini firmware basate su Linux; le immagini bare-metal e RTOS sono nella roadmap.