BA Consulting

Software Bill of Materials (SBOM): obbligo normativo o leva di sicurezza?

19/03/2026

Negli ultimi anni il concetto di Software Bill of Materials, comunemente abbreviato in SBOM, è passato da pratica di nicchia a elemento centrale nella governance del software. In origine utilizzato principalmente per la gestione delle licenze open source e per attività di vulnerability management, oggi lo SBOM è sempre più al centro di normative, audit e processi di procurement, sia in ambito pubblico sia privato.

Uno SBOM è, nella sua definizione più operativa, un inventario strutturato e machine-readable di tutti i componenti software che costituiscono un’applicazione. Include librerie, dipendenze, framework, moduli di terze parti e informazioni di versione. Standard come SPDX e CycloneDX permettono di rappresentare questi dati in modo interoperabile, rendendoli utilizzabili lungo tutta la supply chain del software.

Il cambio di paradigma è evidente. Se fino a pochi anni fa lo SBOM era adottato prevalentemente da organizzazioni con una forte maturità DevSecOps, oggi sta diventando un requisito esplicito per operare in determinati mercati. Il punto di svolta è rappresentato dall’evoluzione normativa, in particolare a livello europeo, che lega sempre più strettamente la sicurezza del software alla trasparenza della supply chain.

In questo contesto emerge una domanda chiave per chi guida organizzazioni IT: lo SBOM è un semplice obbligo normativo oppure una leva concreta per migliorare sicurezza, resilienza e competitività?

Il contesto normativo: dalla raccomandazione all’obbligo

L’adozione dello SBOM non è più guidata solo da best practice tecniche. È sempre più spesso richiesta da normative e framework regolatori che mirano a rafforzare la sicurezza del software lungo tutta la catena di fornitura.

Il Cyber Resilience Act rappresenta il riferimento principale in Europa. Questo regolamento introduce requisiti stringenti per tutti i prodotti con componenti digitali immessi sul mercato europeo, includendo software standalone, soluzioni SaaS e dispositivi IoT. Tra gli obblighi previsti rientra la capacità di documentare la composizione del software, rendendo di fatto lo SBOM un elemento necessario per dimostrare conformità.

L’impatto è significativo. Il regolamento prevede sanzioni che possono arrivare fino a 15 milioni di euro o al 2,5 percento del fatturato globale annuo in caso di violazioni gravi. Questo posiziona lo SBOM non più come strumento tecnico opzionale, ma come artefatto con valore legale e contrattuale.

Anche nel contesto italiano si osserva un’evoluzione coerente. Le normative relative agli ICT sensibili e le linee guida sulla sicurezza delle forniture richiedono sempre più frequentemente la tracciabilità dei componenti software. Questo è particolarmente rilevante per fornitori della pubblica amministrazione e per aziende che operano in settori regolati come finanza, energia e telecomunicazioni.

Negli Stati Uniti, la Cybersecurity and Infrastructure Security Agency ha promosso attivamente l’adozione dello SBOM come standard per migliorare la sicurezza della supply chain. Dopo incidenti rilevanti come SolarWinds e Log4Shell, la capacità di identificare rapidamente componenti vulnerabili è diventata un requisito operativo essenziale.

Il risultato è un allineamento globale. Lo SBOM sta emergendo come elemento comune tra normative, framework di sicurezza e richieste di mercato. Non adottarlo significa esporsi a rischi legali, ma anche a limitazioni nell’accesso a gare e opportunità commerciali.

Supply chain del software: il problema della visibilità

Per comprendere il valore dello SBOM è necessario partire da un dato strutturale. Secondo Synopsys, oltre il 96 percento delle applicazioni moderne include componenti open source, con una media di centinaia di dipendenze per progetto. Questo significa che la maggior parte del codice eseguito in produzione non è scritto internamente.

Questa complessità introduce un problema di visibilità. Senza uno SBOM, molte organizzazioni non hanno una mappa completa di ciò che è effettivamente incluso nei propri sistemi. Questo rende difficile rispondere in modo tempestivo a vulnerabilità emergenti.

L’episodio Log4Shell è emblematico. Quando la vulnerabilità è stata resa pubblica, molte aziende hanno impiegato giorni o settimane per capire se fossero esposte. In assenza di uno SBOM, l’identificazione richiedeva analisi manuali, reverse engineering e verifiche sui repository. Con uno SBOM aggiornato, la stessa operazione può essere eseguita in modo automatizzato, correlando le dipendenze con database di vulnerabilità come NVD.

Il tema non riguarda solo la sicurezza tecnica. La mancanza di visibilità impatta anche la gestione delle licenze e il rischio legale. Componenti open source con licenze incompatibili possono generare obblighi di distribuzione del codice o contenziosi, soprattutto in contesti enterprise.

Lo SBOM, in questo scenario, agisce come strumento di trasparenza. Non elimina il rischio, ma lo rende misurabile e gestibile.

SBOM come leva operativa per la sicurezza

Se utilizzato correttamente, lo SBOM diventa un elemento chiave del ciclo di vita della sicurezza del software. Non è un documento statico, ma un artefatto dinamico che evolve insieme al codice.

L’integrazione più efficace avviene all’interno delle pipeline CI CD. Lo SBOM viene generato automaticamente durante il build, aggiornato a ogni release e distribuito insieme all’applicazione. Questo consente di mantenere una visione aggiornata della composizione del software in produzione.

Quando collegato a strumenti di Software Composition Analysis, lo SBOM permette di identificare vulnerabilità note e di attivare processi di remediation. Il tempo di risposta agli incidenti si riduce significativamente. Studi di settore indicano che l’automazione nella gestione delle vulnerabilità può ridurre il time to patch fino al 60 percento.

Un’evoluzione importante è rappresentata dal VEX, Vulnerability Exploitability eXchange. Questo standard consente di contestualizzare le vulnerabilità, indicando se una specifica componente è effettivamente sfruttabile nel contesto dell’applicazione. Questo evita falsi positivi e consente di prioritizzare gli interventi.

Dal punto di vista operativo, lo SBOM abilita una gestione più efficiente degli aggiornamenti. In caso di vulnerabilità critica, è possibile identificare rapidamente i sistemi impattati e applicare patch mirate. Questo riduce il rischio di downtime e migliora la resilienza complessiva.

Architettura e DevSecOps: dove lo SBOM crea valore

L’adozione dello SBOM ha implicazioni dirette sull’architettura e sui modelli operativi. In un contesto DevSecOps maturo, lo SBOM diventa parte integrante dei flussi di sviluppo e rilascio.

A livello architetturale, la modularità e la standardizzazione facilitano la gestione dello SBOM. Sistemi basati su microservizi o componenti riutilizzabili consentono di isolare le dipendenze e di gestirle in modo più efficace. Tuttavia, aumentano anche il numero di artefatti da tracciare, rendendo ancora più necessaria una gestione strutturata.

Il design delle API gioca un ruolo rilevante. Fornire metadati e informazioni sulla provenienza dei componenti consente di estendere la tracciabilità lungo tutta la catena di fornitura. Questo è particolarmente importante in ecosistemi complessi, dove più fornitori contribuiscono al prodotto finale.

Dal punto di vista dei processi, l’integrazione dello SBOM richiede un allineamento tra sviluppo, sicurezza e operations. Non è sufficiente generare lo SBOM. È necessario utilizzarlo attivamente nei processi decisionali, ad esempio per bloccare build non conformi o per attivare alert su vulnerabilità critiche.

Questo approccio richiede competenze specifiche e una cultura orientata alla sicurezza. Le organizzazioni che riescono a integrare lo SBOM in modo efficace ottengono un vantaggio significativo in termini di controllo e reattività.

Oltre la compliance: il valore competitivo dello SBOM

Limitarsi a considerare lo SBOM come un obbligo normativo significa perdere una parte rilevante del suo potenziale. Le organizzazioni più mature lo utilizzano come leva per migliorare la qualità del software e differenziarsi sul mercato.

La trasparenza sulla composizione del software diventa un elemento di fiducia. Clienti enterprise e pubbliche amministrazioni richiedono sempre più spesso informazioni dettagliate sui componenti utilizzati. Essere in grado di fornire uno SBOM aggiornato e completo rappresenta un vantaggio competitivo nelle fasi di vendita e procurement.

Dal punto di vista interno, lo SBOM contribuisce a ridurre il debito tecnico. La visibilità sulle dipendenze consente di identificare componenti obsoleti o non supportati e di pianificare interventi di modernizzazione. Questo migliora la manutenibilità e riduce il rischio di vulnerabilità future.

Anche la gestione delle licenze beneficia dell’adozione dello SBOM. La possibilità di tracciare in modo preciso le componenti open source consente di evitare violazioni e di gestire in modo proattivo gli obblighi legali.

Secondo Gartner, entro il 2027 oltre il 60 percento delle organizzazioni che sviluppano software sarà obbligato a fornire SBOM ai propri clienti o partner. Questo rende lo SBOM un elemento strutturale del mercato, non una scelta opzionale.

Per molte aziende, l’adozione dello SBOM rappresenta una sfida sia tecnica sia organizzativa. La definizione di standard, l’integrazione nei processi e la gestione operativa richiedono competenze trasversali.

Una IT consultancy può supportare questo percorso partendo da assessment strutturati, identificando gap rispetto ai requisiti normativi e alle best practice di sicurezza. Può definire roadmap di implementazione che tengano conto delle priorità di business e dei vincoli tecnologici.

L’integrazione dello SBOM nelle pipeline CI CD richiede una selezione accurata degli strumenti e una configurazione coerente con l’architettura esistente. La consulenza può facilitare questo processo, riducendo tempi e rischi.

Un ulteriore ambito di valore è rappresentato dal vendor assessment. Le organizzazioni che acquistano software possono utilizzare lo SBOM come criterio di valutazione, analizzando la composizione delle soluzioni e il livello di esposizione a vulnerabilità. Questo consente decisioni più informate e riduce il rischio nella supply chain.

Lo SBOM si trova oggi al centro di una trasformazione che coinvolge normativa, sicurezza e modelli operativi. Non è più un artefatto tecnico marginale, ma un elemento chiave per la governance del software.

Per le organizzazioni che lo adottano in modo reattivo, rappresenta un obbligo necessario per evitare sanzioni e accedere al mercato. Per quelle che lo integrano in modo strategico, diventa una leva per migliorare la sicurezza, aumentare la trasparenza e rafforzare la competitività.

In un contesto in cui la complessità della supply chain continua a crescere, la capacità di sapere cosa è realmente presente nel proprio software non è più un vantaggio. È una condizione necessaria per operare in modo sostenibile.

Fonti citate: