Oggi la Software Bill of Materials (SBOM) è diventata uno strumento fondamentale per gestire la sicurezza, la compliance e il rischio nella supply chain software, soprattutto in un contesto in cui il riuso di componenti open source è diffuso su larga scala. In questo articolo raccontiamo come, attraverso il nostro approccio, sia possibile automatizzare la raccolta e la gestione di queste informazioni, migliorando visibilità e resilienza.
Per anni la sicurezza del software è stata affrontata come un problema prevalentemente tecnico, fatto di patch, firewall e controlli perimetrali. Oggi questa visione non è più sufficiente. Le applicazioni che utilizziamo e sviluppiamo non sono più monoliti costruiti interamente in casa, ma ecosistemi complessi, composti da librerie open source, componenti commerciali, servizi cloud, framework e moduli sviluppati da terze parti.
In questo contesto, la domanda non è più semplicemente “il mio software è sicuro?”, ma piuttosto: “di cosa è fatto il mio software e cosa comporta in termini di rischio, responsabilità e compliance?”
È qui che entra in gioco la Software Bill of Materials (SBOM): la distinta base del software, ovvero un inventario strutturato e interrogabile dei componenti che lo compongono. Quello che fino a poco tempo fa era un tema per addetti ai lavori sta rapidamente diventando una necessità trasversale, che riguarda tutte le organizzazioni, non solo chi sviluppa software.
Quando pensiamo a un’applicazione, tendiamo ancora a immaginarla come un prodotto relativamente compatto, sviluppato e controllato da un singolo team. In realtà, il software moderno è sempre più simile a una supply chain, paragonabile a quella di un prodotto industriale.
Accanto al codice proprietario sviluppato internamente, un’applicazione include oggi una quantità crescente di componenti esterni: librerie open source, framework, runtime, SDK di terze parti, plugin e moduli forniti da vendor, componenti commerciali acquistati e integrati (COTS), oltre a servizi cloud, API e pacchetti provenienti da marketplace. Il risultato è un assemblato di elementi con origini diverse, ciascuno con il proprio ciclo di vita, le proprie vulnerabilità e i propri vincoli di licenza.
Questa complessità è amplificata dal modo in cui il software viene prodotto. È normale che più team contribuiscano alla stessa applicazione — interni, fornitori, consulenti — e che gli stessi componenti vengano riutilizzati in più progetti. Le dipendenze cambiano frequentemente: nuove versioni, nuove librerie, nuove immagini container entrano in produzione con grande rapidità.
Il vantaggio è evidente: lo sviluppo è più veloce e aumenta la capacità di innovazione. Il rovescio della medaglia è altrettanto chiaro: la superficie di rischio aumenta. Ogni dipendenza rappresenta una possibile fonte di vulnerabilità, problemi di compatibilità o obblighi di licenza non gestiti. E ogni aggiornamento, se non governato con la giusta visibilità, può introdurre nuovi rischi. Trattare il software come una supply chain non è quindi un esercizio teorico, ma una presa d’atto necessaria per comprenderne davvero complessità e responsabilità.
Uno dei punti di forza dell’open source è il riuso: componenti condivisi da migliaia di progetti accelerano lo sviluppo e favoriscono l’innovazione. Allo stesso tempo, questo modello crea un effetto moltiplicatore del rischio. Quando emerge una vulnerabilità in un componente ampiamente diffuso, l’impatto non è circoscritto a un singolo prodotto, ma si estende a interi ecosistemi software.
In questi casi, il problema non è tanto l’esistenza della vulnerabilità in sé — le vulnerabilità sono inevitabili — quanto la capacità di capire rapidamente se e dove quella vulnerabilità impatta la propria organizzazione. Significa sapere se un componente è utilizzato, in quale versione, se è presente direttamente o come dipendenza indiretta, dove è stato distribuito e chi lo ha introdotto lungo la catena di sviluppo o fornitura.
Eventi come Apache Struts nel 2017, Log4Shell nel 2021 o la vulnerabilità di cURL nel 2023 hanno mostrato con chiarezza questo meccanismo. In tutti questi casi, la differenza tra chi ha reagito in modo rapido ed efficace e chi ha faticato per settimane è stata spesso una sola: la visibilità sulla composizione del software.
Le organizzazioni che sapevano esattamente cosa avessero in produzione hanno potuto individuare rapidamente i punti di esposizione e intervenire. Chi, invece, non disponeva di questa visibilità si è trovato a cercare “al buio”, con impatti rilevanti su tempi, costi e rischio operativo. È in questo contesto che la SBOM diventa un vero acceleratore operativo. Disporre di un inventario strutturato dei componenti software non elimina le vulnerabilità, ma riduce drasticamente il tempo e l’incertezza necessari per identificarle, valutarne l’impatto e gestirle in modo mirato.
Il tema della SBOM viene spesso introdotto partendo dalla sicurezza: vulnerabilità, CVE, patching. Ma fermarsi a questo livello è riduttivo. Esiste un secondo piano, altrettanto rilevante, che riguarda licenze, obblighi legali e responsabilità lungo la supply chain software.
Un caso emblematico in questo senso è quello di Vizio, frequentemente citato nel mondo open source e copyleft. La vicenda è interessante perché sposta il focus da “stiamo usando software open source?” a una domanda molto più scomoda : “possiamo dimostrare di rispettarne davvero le condizioni?”
Vizio è stata coinvolta in una causa legata all’utilizzo di componenti software rilasciati sotto licenza GPL all’interno dei propri smart TV. Il punto centrale non era semplicemente l’uso di software open source — pratica del tutto legittima — ma il modo in cui tale software veniva distribuito. Secondo le contestazioni, il codice sorgente rilasciato non era sufficiente a consentire un utilizzo reale: mancavano parti fondamentali, istruzioni di build, informazioni sulle modifiche effettuate e una chiara tracciabilità dei componenti inclusi.
Il caso è diventato rilevante perché ha chiarito un principio fondamentale: non basta dichiarare la conformità a una licenza open source, bisogna essere in grado di provarla in modo concreto e verificabile. Nei contesti embedded e nei prodotti commerciali che incorporano OSS — come Linux embedded, driver modificati o librerie copyleft — una gestione superficiale della composizione software porta rapidamente a situazioni critiche. Il risultato è spesso un rilascio del sorgente solo formalmente corretto, ma privo delle informazioni necessarie a garantirne una reale fruibilità, con conseguenti rischi legali e reputazionali per l’organizzazione.
Il punto di fondo è che la supply chain software genera obblighi, non solo tecnici ma anche contrattuali e legali. Ogni componente introdotto porta con sé condizioni di utilizzo, vincoli di distribuzione e responsabilità che devono essere governati nel tempo. Senza una SBOM — o senza un processo equivalente di tracciabilità e controllo — questi obblighi diventano difficili da gestire, se non del tutto ingestibili.
In questo senso, la SBOM non è soltanto uno strumento di sicurezza, ma un meccanismo di accountability: consente di sapere cosa si sta distribuendo, da dove proviene, quali licenze lo regolano e quali responsabilità ne derivano. Ed è proprio questa capacità di dimostrare consapevolezza e controllo che sta rendendo la gestione delle SBOM sempre più centrale, anche al di fuori dei contesti puramente tecnici.
Negli ultimi anni, il tema della composizione del software è uscito dall’ambito puramente tecnico per entrare a pieno titolo nel perimetro normativo. Le istituzioni hanno preso atto di una realtà ormai evidente: la sicurezza e l’affidabilità del software dipendono dalla sua supply chain. E governare questa supply chain richiede visibilità.
In questo contesto si inseriscono iniziative come la National Cybersecurity Strategy negli Stati Uniti e, soprattutto, il Cyber Resilience Act (CRA) in Europa. Il CRA introduce obblighi chiari per chi immette sul mercato prodotti con elementi digitali, in particolare software e dispositivi che lo incorporano. Tra questi obblighi rientrano la gestione delle vulnerabilità, la sicurezza lungo il ciclo di vita e la capacità di dimostrare controllo sui componenti utilizzati.
Anche se il CRA non menziona esplicitamente la SBOM come unico strumento possibile, il principio è chiaro: non è possibile rispettare questi requisiti senza sapere di cosa è fatto il software. In pratica, la SBOM diventa il mezzo più efficace — e spesso l’unico realmente scalabile — per dimostrare conformità.
Il punto però non riguarda solo i produttori di software. Altre normative ampliano ulteriormente il perimetro.
La Direttiva NIS2 sposta l’attenzione sulle organizzazioni che utilizzano software per erogare servizi essenziali o critici. Qui il focus non è tanto sul come è stato scritto il software, quanto sulla capacità dell’organizzazione di gestire il rischio cyber e quello legato alla supply chain. Questo include la valutazione dei fornitori, la gestione delle vulnerabilità e la dimostrazione di adeguate misure di controllo. Anche in questo caso, pur senza un obbligo esplicito, la SBOM diventa uno strumento chiave per esercitare e dimostrare la dovuta diligenza.
Per il settore finanziario, il quadro è ulteriormente rafforzato dal Digital Operational Resilience Act (DORA). DORA richiede alle organizzazioni finanziarie una profonda comprensione delle proprie dipendenze ICT e la capacità di rispondere rapidamente a incidenti e vulnerabilità che coinvolgono fornitori e tecnologie critiche. Senza una visibilità chiara sulla composizione del software utilizzato, soddisfare questi requisiti diventa estremamente complesso.
Il risultato è un cambio di paradigma: il tema SBOM nasce come risposta a un’esigenza di sicurezza, ma viene reso strutturale dalla normativa. Il CRA agisce a monte, imponendo responsabilità a chi produce e distribuisce software; NIS2 e DORA agiscono a valle, spingendo le organizzazioni a pretendere trasparenza e controllo dai propri fornitori.
In questo scenario, la SBOM non è più un documento accessorio, ma un elemento abilitante per dialogare con regulator, clienti e partner. Non serve solo a “fare sicurezza meglio”, ma a dimostrare che il software è gestito in modo consapevole, responsabile e conforme alle aspettative normative attuali e future.
Una gestione SBOM realmente efficace non può ridursi a un file statico o a un documento prodotto una tantum: richiede un programma operativo in grado di offrire visibilità continua sulla composizione del software.
Questo significa disporre di un inventario completo e normalizzato di tutti i componenti — open source, commerciali e di terze parti — con versioni, identificativi univoci e metadati affidabili, ma anche comprendere le relazioni tra questi elementi, incluse dipendenze dirette e transitive, gerarchie e correlazioni. Per essere interoperabili e sostenibili nel tempo, le SBOM devono essere gestite in formati standard di settore come SPDX, particolarmente efficace per gli aspetti di licensing e compliance, e CycloneDX, più orientato alla sicurezza e alla supply chain.
Tuttavia, l’elenco dei componenti da solo non basta: una SBOM utile deve essere arricchita con informazioni operative, come vulnerabilità note, stato di exploitability, disclosure e dati di ciclo di vita (EOL ed EOS), oltre a report strutturati come VDR e VEX.
Dal punto di vista pratico, il percorso parte dall’integrazione delle SBOM fornite dai vendor. Tuttavia, la maturità del mercato su questo tema è ancora disomogenea: le SBOM possono essere rese disponibili in modalità molto diverse — tramite siti web del produttore, file “Readme” inclusi nei kit di distribuzione, contenuti estratti direttamente dai dispositivi, puntatori dal device (MUD), file forniti al cliente in formato leggibile o repository centralizzati e terze parti fidate. Questa eterogeneità rende l’integrazione complessa e introduce significative difficoltà di normalizzazione, soprattutto quando i dati non seguono formati, livelli di dettaglio o criteri di qualità omogenei.
Per rendere il processo sostenibile nel tempo, è quindi necessario attivare canali strutturati di raccolta e definire regole chiare su formati accettati, frequenza di aggiornamento, modalità di consegna e firma, nonché criteri minimi di qualità, come completezza delle informazioni, disponibilità delle istruzioni di build e tracciabilità della provenienza. Dove le SBOM non sono disponibili o risultano incomplete — come nel caso di software sviluppato internamente, soluzioni SaaS o componenti realizzati da terze parti — diventa inevitabile crearle internamente, adottando strumenti e processi in grado di generare SBOM coerenti, normalizzate e mantenibili.
In questo scenario, è importante chiarire che il CMDB non è il luogo adatto per gestire le SBOM: nato per rappresentare asset e relazioni operative, è spesso già sovraccarico di dati e non offre la granularità, l’aggiornamento continuo e le capacità di interrogazione richieste in caso di incidenti di sicurezza.
In WEGG affrontiamo il tema delle SBOM con un approccio volutamente trasversale, che parte dal Software Asset Management (SAM) ma si estende oltre i suoi confini tradizionali. Il SAM rappresenta per noi il punto di partenza naturale perché è già il luogo in cui convergono informazioni su costi, contratti e conformità; allo stesso tempo, è il contesto in cui emerge più chiaramente la necessità di andare oltre la semplice visibilità sul software installato e utilizzato.
La SBOM diventa così l’elemento di collegamento tra SAM, sicurezza e compliance, rendendo la composizione del software un dato condiviso e realmente utilizzabile. In questa logica utilizziamo Flexera One IT Visibility come piattaforma di riferimento: non come uno strumento SBOM isolato, ma come parte di un ecosistema integrato.
Abbiamo scelto questa soluzione grazie alla sua tecnologia avanzata di Software Composition Analysis (SCA) sull’open source — un ambito spesso non coperto dagli strumenti SAM tradizionali — ai dati completi e continuamente aggiornati di Technopedia, la base dati di Flexera, e al supporto lungo l’intero ciclo di vita delle SBOM, dall’ingestione alla normalizzazione fino al monitoraggio continuo. Il nostro ruolo è configurare i processi dei clienti per rendere la gestione delle SBOM un processo operativo e scalabile, integrato nei flussi di SAM, ITAM, CMDB e sicurezza.
La correlazione tra i componenti presenti nelle SBOM, la standardizzazione dei formati e l’integrazione con le informazioni sulle vulnerabilità permettono di collegare in modo naturale la gestione delle SBOM ai processi di vulnerability management, consentendo analisi di impatto rapide e mirate quando emergono nuove CVE. Allo stesso tempo, l’integrazione nei processi SAM contribuisce a garantire il rispetto dei requisiti di compliance normativa.
In questo modo, la gestione delle SBOM non viene trattata come un adempimento isolato, ma come una parte integrante del governo complessivo del software, a partire dal SAM e in dialogo con tutte le funzioni coinvolte.
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
