SBOM: Software Bill of Materials
La sicurezza dei prodotti digitali dipende in misura crescente dalla capacità di conoscere con precisione la composizione del software che li costituisce. Applicazioni e dispositivi sono oggi costruiti assemblando componenti proprietari, librerie open source e dipendenze di terze parti, spesso stratificate su più livelli. Quando una vulnerabilità viene scoperta in una libreria ampiamente diffusa, la rapidità con cui un’organizzazione riesce a stabilire se e dove quella libreria sia utilizzata determina in larga parte l’efficacia della risposta. È in questo contesto che il Software Bill of Materials, SBOM, assume un ruolo centrale nella gestione del rischio informatico e nell’attuazione del quadro normativo europeo in materia di cibersicurezza.
Cos’è uno SBOM e come funziona l’inventario dei componenti software
Uno SBOM può essere descritto come un inventario strutturato e leggibile in formato macchina dei componenti software che costituiscono un prodotto, analogo a una lista di ingredienti applicata al codice piuttosto che a un bene fisico. Le specifiche più diffuse a livello internazionale, SPDX e CycloneDX, consentono di rappresentare non soltanto l’elenco dei componenti, ma anche le relazioni di dipendenza tra essi e le informazioni relative alle vulnerabilità note, secondo formati riconosciuti anche in ambito Vulnerability Exploitability eXchange.
Il Regolamento UE 2024/2847 e gli obblighi normativi sullo SBOM
Il Regolamento (UE) 2024/2847, relativo a requisiti orizzontali di sicurezza cibernetica per i prodotti con elementi digitali, ha reso lo SBOM un elemento previsto dal quadro normativo dell’Unione Europea. L’allegato I, parte II, punto 1, richiede ai fabbricanti di identificare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche mediante la redazione di uno SBOM in un formato comunemente utilizzato e leggibile da dispositivo automatico, che copra almeno le dipendenze di primo livello del prodotto. Il regolamento non impone la pubblicazione dello SBOM, ma ne richiede l’inclusione nella documentazione tecnica e la disponibilità alle autorità di vigilanza del mercato su richiesta. Gli obblighi di notifica delle vulnerabilità attivamente sfruttate si applicano a partire dall’11 settembre 2026, mentre la gran parte degli obblighi previsti dal regolamento diventerà vincolante dall’11 dicembre 2027.
I vantaggi dello SBOM nella gestione rapida delle vulnerabilità
Il valore operativo dello SBOM emerge soprattutto nella fase di gestione delle vulnerabilità. Disporre di un inventario aggiornato dei componenti consente di stabilire in tempi rapidi l’esposizione di un prodotto quando viene resa nota una nuova falla in una libreria diffusa, riducendo il tempo che intercorre tra la divulgazione della vulnerabilità e l’adozione delle contromisure. Le organizzazioni prive di un simile strumento si trovano invece a dover ricostruire manualmente la composizione dei propri sistemi, con un evidente allungamento dei tempi di risposta.
Sfide tecniche e analisi delle dipendenze nello SBOM
La costruzione e il mantenimento di uno SBOM efficace presentano tuttavia alcune difficoltà tecniche. Le dipendenze dichiarate a livello superficiale rappresentano soltanto il requisito minimo previsto dalla normativa; una mappatura completa delle vulnerabilità richiede l’analisi delle dipendenze transitive, ossia dei componenti richiamati indirettamente attraverso altre librerie. Una ricerca condotta dall’Università di Padova in collaborazione con Kineton ha inoltre evidenziato come gli strumenti automatizzati di scansione basati su SBOM possano restituire risultati incoerenti tra loro, generando falsi negativi e comportamenti imprevisti che rendono necessaria una verifica sistematica della loro affidabilità.
Oltre lo SBOM: la gestione del rischio digitale con Demetra
Questi elementi confermano come la mappatura dei componenti software non possa essere considerata un adempimento isolato, ma vada collocata all’interno di una gestione più ampia del rischio digitale. La conoscenza dettagliata della composizione interna di un prodotto costituisce infatti solo il primo passo: comprendere come una vulnerabilità in un singolo componente possa propagarsi lungo la catena di fornitura, fino a incidere su processi, servizi e organizzazioni collegate, richiede strumenti capaci di modellare le interdipendenze a un livello più ampio.
Piattaforme di analisi del rischio e simulazione degli effetti a cascata, come Demetra di Hermes Bay, permettono di rappresentare le relazioni tra asset, processi e fornitori e di valutare le conseguenze che una vulnerabilità software o un evento di compromissione potrebbero generare lungo l’intera catena operativa, supportando le organizzazioni nella pianificazione della continuità e nel rafforzamento della resilienza complessiva.
