In un ecosistema software dominato da componenti open source, dipendenze transitive e catene di fornitura globali, SBOM e VEX diventano strumenti cruciali per ricostruire la fiducia.
La loro importanza è esplosa dopo il caso SolarWinds del 2020, quando una compromissione della supply chain ha mostrato quanto poco conosciamo davvero ciò che gira nei nostri sistemi.
Indice degli argomenti
La lezione di SolarWinds e la crisi di fiducia digitale
Nel dicembre 2020, il caso SolarWinds rivelò una delle più sofisticate compromissioni della supply chain software mai osservate. Un aggiornamento legittimo del sistema di monitoraggio Orion, distribuito a migliaia di clienti pubblici e privati, conteneva codice malevolo introdotto durante il processo di sviluppo. Non si trattava di un attacco diretto ai bersagli finali, ma di un’infiltrazione nel cuore dei meccanismi di fiducia del software moderno.
Per mesi, quel codice è rimasto silente, attraversando confini e firewall senza destare sospetti, fino a quando l’anomalia è emersa: agenzie governative, grandi corporation tecnologiche, persino strutture critiche si sono accorte di condividere la stessa criticità. L’incidente non ha soltanto dimostrato la vulnerabilità delle catene di fornitura digitali, ma ha messo in discussione il modo stesso in cui valutiamo la sicurezza del software.
Da allora, il tema della software transparency è diventato centrale. Non basta più sapere da chi proviene un software o se è firmato digitalmente: occorre sapere di cosa è composto.
In questo contesto, strumenti come il Software Bill of Materials (SBOM) e la sua estensione, la Vulnerability Exploitability eXchange (VEX) stanno emergendo come nuovi pilastri per la sicurezza e la governance del software.
Anatomia dello SBOM: dall’opacità alla trasparenza strutturale
Ogni software moderno è un organismo complesso, costruito su strati di codice provenienti da centinaia di sorgenti diverse, librerie open source, componenti di terze parti, moduli ereditati. Ne deriva pertanto una “opacità funzionale” che l’incidente SolarWinds ha evidenziato in maniera evidente, trasformando la trasparenza strutturale da virtù opzionale a prerequisito sistemico necessario.
Il Software Bill of Materials non è semplicemente un nuovo acronimo nella liturgia della cybersecurity: è la risposta epistemica a una crisi di fiducia. Nato nella cultura open source come pratica di tracciabilità e accountability, il SBOM è divenuto, con l’Ordine Esecutivo 14028 emanato dal Presidente Biden nel 2021, un elemento di sicurezza nazionale. È, in sostanza, una “distinta base” del software, ovvero un inventario strutturato di tutti i componenti che lo costituiscono, paragonabile all’etichetta nutrizionale che rivela gli ingredienti dei cibi che consumiamo ogni giorno.
La sua utilità si è rivelata con chiarezza pochi mesi dopo quando, l’esplosione della vulnerabilità Log4Shell, mise in crisi migliaia di organizzazioni incapaci di sapere se, dove e in quali sistemi fosse presente la libreria vulnerabile. Quell’episodio dimostrò che la mancanza di trasparenza non è un limite teorico, ma un rischio operativo reale.
Sapere cosa contiene un software significa poter mappare le vulnerabilità prima che si trasformino in minacce, identificare componenti compromessi in tempo reale, ridurre la finestra di esposizione e, soprattutto, ristabilire una forma di controllo razionale sulla complessità dello stesso.
Dalla consapevolezza situazionale alla granularità semantica
Nel linguaggio della sicurezza, questo passaggio è cruciale: dallo “sconosciuto ignoto” al “conosciuto gestibile“. La Cybersecurity and Infrastructure Security Agency (CISA) americana definisce i SBOM come strumenti di “consapevolezza situazionale amplificata” in quanto permettono alle organizzazioni di reagire non più in modo reattivo, ma proattivo. La trasparenza diventa così una forma di difesa, e la conoscenza una ulteriore risorsa di resilienza.
Ne consegue una diatriba sulla granularità semantica, ovvero sul livello di dettaglio interno di uno SBOM. Un inventario eccessivamente dettagliato rischia di diventare ingestibile, mentre una rappresentazione troppo sintetica può celare informazioni cruciali per la valutazione del rischio e la risposta alle vulnerabilità. La National Telecommunications and Information Administration (NTIA) americana propone un approccio modulato alla granularità: ogni SBOM dovrebbe includere almeno tutte le dipendenze dirette (primary components), corredate di metadati sufficienti a consentire la tracciabilità ricorsiva delle dipendenze transitive. In altre parole, ciò che non si conosce deve essere dichiarato come tale.
Questa trasparenza imperfetta, codificata nel concetto di known-unknowns, introduce una nuova etica della conoscenza nella sicurezza informatica dove riconoscere i limiti della propria visibilità diventa parte integrante della resilienza.
Le tre traiettorie evolutive del paradigma SBOM
Il paradigma SBOM presenta, per sua natura, tre traiettorie evolutive che ne ampliano la portata strategica e ne ridefiniscono il ruolo nella catena del valore del software.
La prima riguarda l’integrazione con framework di valutazione delle vulnerabilità, in grado di trasformare il SBOM da semplice inventario a strumento decisionale.
La seconda concerne la dinamizzazione, ossia la possibilità di aggiornare in tempo reale la composizione del software al mutare del codice sorgente, evitando di basarsi su “fotografie del software” obsolete.
La terza, più recente, si apre verso l’intelligenza artificiale, dove il concetto di AI-BOM (Artificial Intelligence Bill of Materials) mira a estendere la trasparenza anche ai modelli di machine learning, ai dataset utilizzati e alle dipendenze algoritmiche che ne influenzano il comportamento.
Questi sono tre percorsi distinti ma convergenti che esprimono lo stesso obiettivo di fondo: trasformare la trasparenza in un meccanismo operativo non più confinato alla compliance, ma parte integrante del ciclo di vita della sicurezza del software.
VEX: dal rischio potenziale alla minaccia contestualizzata
Tra queste direttrici, la più concreta e immediata è oggi rappresentata dall’integrazione con il VEX – Vulnerability Exploitability eXchange. Se lo SBOM risponde alla domanda “di cosa è fatto un software”, il VEX risponde alla domanda “quanto è realmente vulnerabile”. Essa rappresenta il passaggio da una visione statica a una visione dinamica del rischio associato al software, dove la conoscenza non è più fine a sé stessa ma orientata all’azione.
Formalizzato come profilo del Common Security Advisory Framework (CSAF) americano, il VEX è pensato per comunicare ai fornitori, in modo strutturato e verificabile, se una vulnerabilità nota all’interno di un componente elencato nello SBOM sia effettivamente sfruttabile oppure mitigata oppure non applicabile o ancora in analisi.
In pratica, mentre lo SBOM permette di identificare i rischi potenziali legati alle vulnerabilità presenti nel software, il VEX le contestualizza rispetto all’ambiente dell’utilizzatore, evidenziando non solo i rischi potenziali, ma anche le minacce effettive a cui è realmente esposto. Questo approccio, oltre a ridurre i falsi positivi, consente alle organizzazioni di allocare le risorse in modo mirato alle vulnerabilità effettivamente applicabili al proprio contesto.
Il binomio strategico SBOM + VEX nella governance moderna
È in questo punto che la combinazione SBOM + VEX assume la sua vera rilevanza strategica. Insieme, potrebbero costituire i due pilastri della “software transparency” e della “vulnerability posture” moderna.
La prima serve a garantire visibilità sulla composizione e sulle origini del software, la seconda invece serve a misurare la reale esposizione del software rispetto alle vulnerabilità note. Questa sinergia sposterebbe l’asse della responsabilità in quanto la gestione del rischio non sarebbe più interamente in carico all’utilizzatore finale, ma coinvolgerebbe significativamente il fornitore che sarebbe chiamato a mantenere aggiornato lo SBOM e a fornire un VEX coerente, verificabile e aggiornato nel tempo.
SBOM e VEX negli appalti pubblici: trasparenza dinamica
Negli Stati Uniti lo SBOM è oggi un requisito obbligatorio nei processi di procurement pubblico dove le agenzie federali lo richiedono ai fornitori come condizione di trasparenza nella qualificazione tecnica.
Applicato agli appalti di acquisizione ICT, il binomio SBOM + VEX permette una “due diligence” tecnologica completa e capace di verificare non solo cosa compone un software, ma anche quanto ciascun componente sia sicuro, aggiornato e privo di vulnerabilità note.
Inoltre, un approccio del genere introduce anche un criterio di trasparenza dinamica che è in grado di monitorare nel tempo l’obsolescenza dei moduli di terze parti e di correlare ogni aggiornamento o modifica funzionale del software alle eventuali nuove vulnerabilità che impattano su di esso.
I limiti della trasparenza: quando il sistema informativo vacilla
Tuttavia, l’efficacia di questo meccanismo non è automatica. Il valore di questo duo si perderebbe quando venissero trascurate le fasi successive al rilascio: se il software evolvesse senza che lo SBOM venisse aggiornato o se il VEX non fosse validato periodicamente, l’intero sistema informativo di fiducia verrebbe meno.
Allo stesso modo, un uso improprio del software, configurazioni non conformi o l’assenza di una catena di distribuzione verificabile renderebbero vana la trasparenza documentata.
La frammentazione degli standard: SPDX vs CycloneDX
Se l’idea di una trasparenza software universale appare oggi condivisa, la sua traduzione in pratica è tutt’altro che facile. Il primo ostacolo risiede nella frammentazione degli standard di rappresentazione dello SBOM, ovvero dei formati attraverso cui viene compilata e condivisa la “distinta base” del software. Oggi convivono due principali modelli: il Software Package Data Exchange (SPDX), promosso dalla Linux Foundation, e CycloneDX, sviluppato dall’OWASP (Open Web Application Security Project) Foundation. Entrambi servono a descrivere in modo strutturato componenti come librerie, versioni, licenze e dipendenze, ma si concentrano su aspetti diversi. Mentre l’SPDX nasce con l’intendo di creare formato comune per la raccolta e la condivisione di dati software, in particolare le informazioni sulle licenze, il CycloneDX privilegia la sicurezza integrandosi con i processi di gestione delle vulnerabilità e dei rischi operativi.
Questa differente visione ha generato una divergenza tecnica e politica e due linguaggi differenti per rappresentare la stessa realtà. Di conseguenza, un’organizzazione che genera uno SBOM in SPDX potrebbe non essere pienamente compatibile con chi utilizza CycloneDX, rendendo complessa l’automazione, la condivisione e, soprattutto, l’integrazione con strumenti come il VEX.
Finché non si definirà un meccanismo comune di interoperabilità, la piena adozione del binomio SBOM + VEX resterà un obiettivo più auspicato che realizzato.
Integrità dello SBOM: firma digitale e catena di custodia
Altro aspetto rilevante è la garanzia dell’integrità dello SBOM. Ad esempio, uno SBOM generato nella fase di sviluppo del software perde efficacia se non è associato a un meccanismo di verifica valido quali una firma, un hash, una catena di custodia che assicuri la corrispondenza tra binario e descrizione. Senza questi meccanismi di garanzia dell’integrità, lo SBOM rischi di essere vanificato come misura di sicurezza e potrebbe essere soggetto ad attacchi da parte di agenti malevoli che avrebbero tutto l’interesse a modificarlo.
Stati Uniti: l’accelerazione normativa post-SolarWinds
Dopo il caso SolarWinds, gli Stati Uniti hanno imposto un’accelerazione normativa chiara attraverso il requisito obbligatorio dello SBOM, mentre in Europa e in Asia il cammino è più frammentato riflettendo i diversi approcci regolamentatori e industriali.
Europa: NIS 2 e Cyber Resilience Act verso la sovranità digitale
Nel contesto europeo, la sicurezza della supply chain digitale è diventata una priorità strategica e politica, ma il percorso resta ancora in costruzione. La di Network and Information Security 2 Directive (NIS 2) e il Cyber Resilience Act (CRA) rappresentano i due pilastri principali di questo approccio.
La prima estende gli obblighi di sicurezza a un numero sempre maggiore di settori, dai servizi energetici e sanitari fino al manifatturiero e alle telecomunicazioni, imponendo agli operatori di valutare i rischi legati ai propri fornitori e di garantire la continuità e l’integrità delle catene di approvvigionamento digitali. Il CRA, invece, introduce requisiti di “security by design” per tutti i prodotti con elementi digitali immessi sul mercato europeo, chiedendo ai produttori di mantenere la sicurezza per l’intero ciclo di vita del software e di assicurare visibilità sulle componenti integrate.
Asia: dal Giappone automotive alla sovranità cinese
In Asia, invece, non esiste un unico standard regionale come in Europa, ma seguono approcci diversi per lo più trainati dal mercato.
Il Giappone si è mosso per primo, spinto da una serie di incidenti che hanno messo in luce la fragilità delle componenti software nei sistemi industriali. Il Ministero dell’Economia, Commercio e Industria (METI) ha quindi promosso l’adozione degli SBOM nel settore automotive: un ambito in cui la catena di fornitura è estremamente complessa e globalizzata e dove una singola vulnerabilità in un modulo software può compromettere la sicurezza fisica delle persone che utilizzano il veicolo. La ratio di questa scelta è chiara: ogni componente software, dal sistema di “infotainment” al controllo del motore, deve essere verificabile, aggiornabile e attribuibile a un fornitore preciso. Colossi come Toyota, Denso e Hitachi Astemo stanno già sperimentando SBOM obbligatori nei processi di procurement e certificazione.
Singapore, invece, segue approccio diverso. Sotto la guida della Cyber Security Agency of Singapore (CSA), sono state avviate diverse iniziative per l’integrazione dello SBOM in vari settori strategici. La vera peculiarità è che lo SBOM non è considerato solo uno strumento tecnico, ma è collegato ai principi ESG (Environmental, Social, Governance) e di responsabilità sociale. In pratica, la trasparenza sul software diventa un indice di etica aziendale, un po’ come accade con la dichiarazione delle emissioni di CO₂.
Altri Paesi, come la Corea del Sud, si muovono ancora in una fase sperimentale, mentre la Cina sta percorrendo una strada più autonoma: punta a costruire un modello di tracciabilità software interno, fortemente legato alla propria visione di sovranità tecnologica. In altre parole, il governo mira a controllare completamente la filiera del software nazionale, riducendo la dipendenza da standard o strumenti sviluppati in occidente. Questo approccio, pur condividendo l’obiettivo di aumentare la visibilità e la sicurezza del software, risponde più a una logica di controllo strategico che di interoperabilità.
Il cambio di paradigma: verso una fiducia digitale verificabile
L’evoluzione dello SBOM, e la sua integrazione con il VEX, non rappresentano semplicemente un miglioramento tecnico, ma un cambio di paradigma nella gestione della fiducia digitale. Dopo decenni di sicurezza basata su confini, segreti e controlli a posteriori, il settore si sta muovendo verso un modello basato sulla trasparenza, la verificabilità e la collaborazione.
Negli Stati Uniti, l’adozione è già una realtà istituzionale, in Europa, è parte di una strategia di sovranità tecnologica e resilienza industriale e in Asia, si innesta su visioni di governance e responsabilità aziendale più ampie. Ma l’obiettivo comune è uno solo: rendere visibile ciò che finora era opaco, trasformando la supply chain digitale da punto cieco a elemento attivo della sicurezza.
Nel medio periodo, la sfida non sarà più “se” adottare SBOM e VEX, ma come automatizzarli, integrarli e certificarli all’interno dei processi di sicurezza aziendali.
