SBOM: cos'è e cosa chiede il Cyber Resilience Act

Una SBOM (software bill of materials, in italiano distinta base del software) è l'elenco formale dei componenti che compongono un software, con versioni, produttori e relazioni di dipendenza, in un formato che una macchina sa leggere. Serve a rispondere in fretta alla domanda che arriva con ogni vulnerabilità nuova: quel componente è dentro i nostri prodotti? Con il Cyber Resilience Act diventa un obbligo per i fabbricanti di prodotti con elementi digitali: va redatta e conservata nella documentazione tecnica, ma non c'è l'obbligo di pubblicarla.

Il quadro generale del regolamento (UE) 2024/2847 sta nella guida Cyber Resilience Act: cos'è e chi riguarda; qui si parla solo di SBOM.

Cos'è una SBOM, in pratica

Il Cyber Resilience Act la definisce all'articolo 3, punto 39: la distinta base del software è "un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software di un prodotto con elementi digitali".

Le linee guida della CISA, l'agenzia statunitense per la cybersecurity, usano un'immagine più semplice: un inventario annidato, la lista degli ingredienti di un software. Il firmware di un router industriale, per esempio, contiene un sistema operativo, una libreria crittografica, un server web: ognuno con la sua versione, il suo produttore e le sue dipendenze.

Il nome richiama la distinta base della manifattura, che elenca i pezzi di un prodotto fisico. Nel software il problema è lo stesso, con una differenza: molti pezzi arrivano da progetti open source e da fornitori terzi, e senza un registro è difficile sapere con precisione cosa c'è dentro.

A cosa serve: la domanda del giorno dopo

Il caso che ha reso il tema concreto è Log4j. La vulnerabilità CVE-2021-44228 nella libreria di logging Apache Log4j2 è stata pubblicata nel National Vulnerability Database il 10 dicembre 2021, ed è nel catalogo CISA delle vulnerabilità sfruttate attivamente. Una libreria di logging finisce dentro moltissimi prodotti, spesso come dipendenza di un'altra libreria: davanti a un caso così la prima domanda non è come correggere, è dove si trova.

Una SBOM trasforma quella ricerca in una consultazione. Il documento CISA del 2026 lo descrive così, in sintesi: quando emerge una vulnerabilità nuova, chi ha le SBOM può verificare se contengono il componente vulnerabile, con tempi di risposta molto migliori di chi non le ha. Gli usi principali sono tre:

• gestione delle vulnerabilità: incrociare i componenti con i bollettini di sicurezza e sapere quali prodotti sono esposti;
• licenze: sapere sotto quale licenza è distribuito ogni componente, prima che lo chieda un cliente o un legale;
• acquisti e fornitori: valutare la qualità del software che si compra, oltre alla parola del fornitore.

Cosa chiede il Cyber Resilience Act

L'obbligo sta nell'Allegato I, parte II, punto 1. I fabbricanti di prodotti con elementi digitali "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".

Il resto del regolamento chiarisce dove va la SBOM e chi la vede:

• Documentazione tecnica: l'Allegato VII, punto 2, lettera b, la elenca tra le informazioni sui processi di gestione delle vulnerabilità, insieme alla politica di divulgazione coordinata e all'indirizzo di contatto per le segnalazioni.
• Autorità di vigilanza: l'Allegato VII, punto 8, prevede che la SBOM sia fornita a seguito di una richiesta motivata di un'autorità di vigilanza del mercato, quando serve a verificare la conformità ai requisiti essenziali.
• Nessun obbligo di pubblicazione: il considerando 77 dice che i fabbricanti non dovrebbero essere obbligati a renderla pubblica. Se decidono di metterla a disposizione dell'utilizzatore, l'Allegato II, punto 9, chiede di indicare dove si trova.
• Conservazione: l'articolo 13, paragrafo 13, chiede di tenere la documentazione tecnica a disposizione delle autorità per almeno dieci anni dall'immissione sul mercato, o per il periodo di assistenza se più lungo.

Sul formato il regolamento lascia una porta aperta: l'articolo 13, paragrafo 24, consente alla Commissione di specificare formato ed elementi della SBOM con atti di esecuzione. Nel repository del Publications Office dell'UE, consultato il 7 ottobre 2026, gli atti adottati sulla base del regolamento sono tre (il delegato 2025/1535, il regolamento di esecuzione 2025/2392 sulle categorie di prodotti, il delegato 2026/881) e nessuno riguarda la SBOM. Oggi vale quindi il testo dell'Allegato I.

Da quando

I requisiti dell'Allegato I si applicano dall'11 dicembre 2027, secondo l'articolo 71. Per i prodotti già immessi sul mercato prima di quella data, l'articolo 69 li fa scattare solo in caso di modifica sostanziale. Il calendario completo, con le date già passate, sta in scadenze del Cyber Resilience Act 2026 e 2027.

La non conformità ai requisiti essenziali dell'Allegato I, ai sensi dell'articolo 64, paragrafo 2, è soggetta a sanzioni fino a 15 milioni di euro o, per le imprese, fino al 2,5% del fatturato mondiale annuo dell'esercizio precedente, se superiore.

"Almeno le dipendenze di primo livello": il minimo non basta

Il regolamento fissa un pavimento: le dipendenze dirette del prodotto. Le linee guida internazionali vanno oltre. Nel documento CISA del 2026 il principio di copertura chiede tutti i componenti, comprese le dipendenze transitive, senza una profondità minima, perché chi riceve la SBOM deve poter concludere che una vulnerabilità non lo riguarda quando il componente non compare nell'elenco.

Se una libreria vulnerabile entra nel prodotto come dipendenza di un'altra libreria, una SBOM ferma al primo livello non la mostra. È conforme al testo, ma non risponde alla domanda per cui la si costruisce.

Cosa deve contenere: gli elementi minimi 2026

Il riferimento tecnico più aggiornato è 2026 Minimum Elements for a Software Bill of Materials (SBOM), pubblicato il 29 luglio 2026 dalla CISA con altre 17 organizzazioni, tra cui l'Agenzia per la Cybersicurezza Nazionale (ACN), il BSI tedesco e l'ANSSI francese. Sostituisce gli elementi minimi pubblicati dalla NTIA statunitense nel 2021. Il documento stesso precisa di non interpretare il diritto dell'Unione: non crea obblighi, ma è un riferimento comune per chi genera SBOM e per chi le chiede.

I campi sono 17, divisi in due gruppi. Il primo descrive la SBOM come documento:

• SBOM Author e SBOM Author Signature: chi l'ha generata e la sua firma digitale;
• SBOM Data Format Name e SBOM Data Format Version: formato e versione del formato;
• SBOM Generation Context: in quale fase è stata generata, per esempio prima o dopo la build;
• SBOM Timestamp e SBOM Version: data dell'ultima modifica e versione del documento;
• SBOM Tool Name e SBOM Tool Version: lo strumento usato per generarla.

Il secondo descrive ogni componente:

• Component Producer, Component Name e Component Version: chi l'ha creato, come si chiama, quale versione;
• Component Identifiers: identificativi come CPE o PURL, che permettono di interrogare i database di vulnerabilità;
• Component Hash Value e Component Hash Algorithm: l'impronta crittografica dell'artefatto e l'algoritmo usato;
• Component License: la licenza, possibilmente con gli identificativi SPDX;
• Component Dependency Relationship: quale componente dipende da quale.

A questi si aggiungono sei pratiche: copertura completa, una SBOM nuova per ogni versione o aggiornamento, dati elaborabili dalle macchine, distribuzione tempestiva a chi è autorizzato, dichiarazione esplicita delle informazioni ignote o trattenute, correzione rapida degli errori.

I formati: SPDX e CycloneDX

Il Cyber Resilience Act chiede un formato "di uso comune" senza nominarlo. Il documento CISA indica i due formati oggi più diffusi, entrambi aperti e leggibili sia dalle macchine sia dalle persone:

• SPDX, standardizzato come ISO/IEC 5962:2021;
• CycloneDX, standardizzato da Ecma International come ECMA-424.

Le stesse linee guida chiedono a chi riceve SBOM di accettare qualsiasi formato diffuso e interoperabile, evitando le versioni deprecate. In Germania il BSI descrive i requisiti tecnici della SBOM nella linea guida TR-03183-2, citata dallo stesso documento CISA: è un riferimento utile per chi vende anche lì.

Accanto alla SBOM ci sono i formati di advisory, VEX e CSAF, con cui il produttore comunica lo stato di una vulnerabilità su un componente: sfruttabile, in correzione, non rilevante in quel prodotto. La SBOM dice cosa c'è dentro, l'advisory dice se una vulnerabilità nota conta davvero.

Come si costruisce una SBOM che regge

Una SBOM generata una volta per l'audit invecchia alla prima release. Il lavoro vero è il processo:

1. Perimetro: elenca i prodotti con elementi digitali che immetti sul mercato con il tuo marchio, comprese le versioni ancora in assistenza.
2. Generazione nella pipeline di build: la SBOM nasce a ogni build o release, non a mano. Le linee guida chiedono una SBOM per ogni versione o aggiornamento.
3. Contesto dichiarato: una SBOM dal codice sorgente e una dall'analisi del binario possono dare risultati diversi; dichiara quale hai prodotto.
4. Componenti di terzi: chiedi la SBOM ai fornitori di firmware, librerie e moduli che integri, e mettila a contratto.
5. Incrocio con le vulnerabilità: la SBOM va confrontata in modo continuo con i database e i bollettini di sicurezza, e affiancata da prove periodiche come un programma di vulnerability assessment.
6. Archivio e accesso: conserva ogni versione con la documentazione tecnica e decidi prima chi può riceverla, a quali condizioni e per quale canale.

Il punto 5 collega la SBOM agli obblighi già in vigore: dall'11 settembre 2026 l'articolo 14 del regolamento chiede ai fabbricanti di segnalare le vulnerabilità attivamente sfruttate nei loro prodotti, con un preallarme entro 24 ore. Sapere in pochi minuti quali prodotti contengono il componente colpito è la condizione per rispettare quel termine.

Chi compra software: la SBOM come richiesta ai fornitori

La SBOM non interessa solo chi produce. Il D.Lgs. 138/2024, che recepisce la NIS2, all'articolo 24, comma 2, include tra le misure obbligatorie la "sicurezza della catena di approvvigionamento" e la "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità". Il comma 3 chiede di tenere conto della qualità complessiva dei prodotti e delle pratiche di sicurezza dei fornitori, comprese le loro procedure di sviluppo sicuro.

Chiedere la SBOM ai fornitori di software critici è un modo concreto di dare sostanza a queste misure, dentro un programma di gestione del rischio delle terze parti. Tre richieste da mettere a contratto: il formato, la frequenza di aggiornamento, il canale con cui il fornitore comunica le vulnerabilità che toccano i componenti elencati.

Cosa la SBOM non fa

• Non dice se sei vulnerabile: dice cosa c'è dentro. Che un componente vulnerabile sia raggiungibile e sfruttabile in quel prodotto lo dicono l'analisi e gli advisory.
• Non corregge niente: dopo l'individuazione serve un processo di patch management che porti l'aggiornamento in produzione.
• Non si adatta bene al SaaS: il documento CISA riconosce che responsabilità condivisa e rilasci molto frequenti complicano il modello per il software erogato in cloud.

Una SBOM dice in pochi minuti dove si trova un componente vulnerabile. Il passo dopo è vedere se quella vulnerabilità viene sfruttata nei tuoi sistemi. Se vuoi capire come lo facciamo con il monitoraggio continuo, guarda come lavora il nostro SOC gestito.