SBOM: la lista degli ingredienti del software che scuole e PMI dovrebbero chiedere

Il software moderno è un prodotto composto da molti pezzi

Un’applicazione raramente nasce da zero. Contiene librerie open source, pacchetti del sistema operativo, componenti commerciali, immagini container e dipendenze che a loro volta richiamano altri elementi. Quando emerge una vulnerabilità, la domanda urgente non è soltanto se sia grave: bisogna sapere dove quel componente è presente e quale versione è realmente in uso.

Il 22 ottobre 2026 ENISA ha pubblicato un advisory tecnico dedicato alla Software Bill of Materials, abbreviata in SBOM. È un inventario strutturato dei componenti e delle dipendenze di uno specifico prodotto software: una lista degli ingredienti leggibile dalle persone e dagli strumenti automatici. La guida è rivolta soprattutto a micro, piccole e medie imprese e alle organizzazioni che stanno iniziando questo percorso.

Che cosa deve raccontare una SBOM utile

Una SBOM non è un PDF generico con l’elenco di cinque librerie. Deve collegarsi a una versione precisa del software e descrivere componenti diretti e dipendenze transitive. Tra i dati utili rientrano produttore, nome e versione del componente, identificatori standard, relazioni tra i pacchetti, hash crittografici, licenze, autore e data di generazione dell’inventario.

Formati standard evitano che ogni fornitore inventi una struttura diversa. CycloneDX organizza dati di trasparenza su software e sistemi in un modello leggibile da macchine e persone. SPDX, progetto della Linux Foundation, è uno standard aperto riconosciuto come ISO/IEC 5962:2021. La scelta del formato conta, ma conta di più che l’inventario sia completo, aggiornato e associato senza ambiguità al prodotto descritto.

• Identità: nome, produttore, versione e identificatore univoco del componente.
• Relazioni: quali componenti dipendono da quali altri pacchetti.
• Integrità: hash del file o dell’artefatto distribuito.
• Contesto: strumento, autore, data e modalità con cui la SBOM è stata generata.
• Licenze e provenienza: informazioni necessarie per sicurezza e conformità.

Una SBOM non decide da sola che cosa correggere

L’inventario rende visibili i componenti, ma non sostituisce l’analisi del rischio. Un pacchetto può comparire nell’elenco e non essere raggiungibile nel contesto reale; una vulnerabilità può invece interessare un servizio esposto e richiedere un intervento immediato. ENISA avverte che trattare ogni segnalazione allo stesso modo può sommergere il gruppo tecnico e rallentare le correzioni più urgenti.

Per assegnare priorità bisogna unire i dati SBOM con informazioni sulla vulnerabilità, sfruttabilità, raggiungibilità, esposizione e criticità del servizio. VEX può comunicare se una vulnerabilità nota sia applicabile a uno specifico prodotto. La decisione finale resta basata sul contesto: un registro elettronico pubblico e una demo isolata non hanno lo stesso impatto.

• La SBOM risponde: quali componenti contiene questa versione?
• Il database delle vulnerabilità risponde: quali problemi sono noti per quei componenti?
• VEX e l’analisi tecnica aiutano a capire: il problema è applicabile e sfruttabile qui?
• La gestione del rischio decide: con quale urgenza intervenire e quale servizio proteggere per primo?

Esempio pratico: una piattaforma scolastica segnala una libreria vulnerabile

Immaginiamo una piattaforma usata per iscrizioni e materiali didattici. Arriva un avviso su una libreria JavaScript vulnerabile. Senza inventario, il tecnico deve cercare a mano in repository, server, container e copie archiviate. Con una SBOM associata a ogni rilascio può individuare in pochi minuti quali versioni includono la libreria, se la dipendenza è diretta o transitiva e quali ambienti devono essere controllati.

Il lavoro non finisce con la ricerca del nome. Si verifica se il componente vulnerabile è realmente incluso nell’artefatto distribuito, se il codice interessato è raggiungibile, se esiste una correzione e se l’aggiornamento rompe altre funzioni. Dopo la patch si genera una nuova SBOM, la si valida e la si conserva insieme alla versione corretta. Così l’inventario diventa parte della procedura di rilascio e dell’evidenza dell’intervento.

Come iniziare in quattro passi senza acquistare una piattaforma complessa

ENISA elenca strumenti open source per generazione, validazione, firma, conservazione e consultazione. Non serve adottarli tutti insieme. Conviene scegliere un progetto pilota, produrre un inventario in CycloneDX o SPDX e verificare manualmente dieci componenti: nome, versione, dipendenze, licenza e corrispondenza con l’artefatto installato.

Quando il primo risultato è attendibile, la generazione va inserita nel processo di build o rilascio. La SBOM deve evolvere con il software: conservarne una sola, vecchia di mesi, crea una falsa sensazione di controllo. Occorrono inoltre regole su accesso, conservazione, versionamento e integrità, perché un inventario alterato o distribuito senza criterio può diventare a sua volta una fonte di rischio.

• 1. Scegli un’applicazione concreta e identifica la versione oggi in produzione.
• 2. Genera una SBOM standard, validala e confrontala con pacchetti e artefatti reali.
• 3. Collega la generazione a ogni nuova build o rilascio e conserva lo storico.
• 4. Definisci chi può consultarla, come verificarne l’integrità e come usarla durante un incidente.

Se non sviluppi software, puoi comunque chiedere trasparenza

Molte scuole e piccole imprese acquistano piattaforme invece di svilupparle. In questo caso la SBOM diventa una domanda di fornitura e assistenza. Per i servizi importanti è utile chiedere se il produttore mantiene un inventario dei componenti, con quale frequenza lo aggiorna, come comunica le vulnerabilità e quanto tempo impiega a correggerle. Non sempre l’intero documento può essere reso pubblico, ma il fornitore deve saper dimostrare di conoscere il proprio software.

Il nuovo advisory ENISA considera anche il Cyber Resilience Act, ma precisa che le raccomandazioni sono linee guida tecniche e non costituiscono un’interpretazione legale. Non tutte le organizzazioni hanno gli stessi obblighi. La scelta corretta è integrare la SBOM nei processi di sviluppo, acquisto o gestione in modo proporzionato al ruolo e al rischio.

• Chiedi quale versione del prodotto è coperta dall’inventario.
• Chiedi standard, data di aggiornamento e livello di completezza.
• Definisci tempi e canali per avvisi e correzioni di sicurezza.
• Prevedi esportazione e continuità se il prodotto o il fornitore cambia.

Conoscere gli ingredienti rende più veloce la risposta

Una SBOM non rende sicuro il software per magia. Riduce però il tempo perso a scoprire che cosa contiene e permette di collegare vulnerabilità, versioni e servizi con maggiore precisione. Il risultato utile non è il file generato: è la capacità di rispondere rapidamente, correggere le priorità reali e dimostrare che ogni rilascio è stato controllato.

Se vuoi introdurre una SBOM nei tuoi progetti, valutare la trasparenza di un fornitore o costruire una procedura sostenibile per scuola e impresa, contattami. Possiamo partire da una sola applicazione e definire strumenti, formato, verifiche e responsabilità senza appesantire il lavoro quotidiano.