SBOM: da obbligo normativo a strumento operativo. Come implementarlo davvero

Il Cyber Resilience Act impone il Software Bill of Materials su tutti i prodotti digitali. Oltre la compliance: come costruire, mantenere e integrare l’SBOM nella supply chain security, con tool open source e workflow pratici.

Il contesto normativo: perché l’SBOM è diventato urgente

Per anni l’SBOM è rimasto un concetto familiare solo agli ambienti DevSecOps più maturi. Poi sono arrivati SolarWinds, Log4Shell e una cascata di attacchi alla supply chain software che hanno reso evidente una verità scomoda: la maggior parte delle organizzazioni non sapeva cosa girasse realmente nei propri sistemi. Da quella consapevolezza è nata la spinta normativa che oggi impone alle aziende di rispondere a una domanda apparentemente banale con un documento formale, strutturato e aggiornato: di cosa è fatto il software che produciamo o utilizziamo?

Il Cyber Resilience Act (CRA), pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 20 novembre 2024 come Regolamento (UE) 2024/2847 ed entrato in vigore il 10 dicembre 2024, è il riferimento normativo più rilevante per il mercato europeo. Gli obblighi di notifica di vulnerabilità e incidenti gravi si applicano a partire dall’11 settembre 2026, mentre la piena applicazione di tutti i requisiti di sicurezza diventa obbligatoria dall’11 dicembre 2027. Il regolamento si applica a tutti i prodotti con elementi digitali immessi sul mercato UE, tra cui hardware con componenti software integrato, applicazioni, firmware e sistemi embedded.

Tra i requisiti dell’Allegato I individua esplicitamente l’obbligo per i fabbricanti di “identificare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche elaborando una distinta base del software in un formato comunemente usato e leggibile meccanicamente che copra almeno le dipendenze di primo livello dei prodotti”.

Vale la pena sottolineare una sfumatura rilevante: il CRA non impone la pubblicazione dell’SBOM, ma la sua disponibilità su richiesta delle autorità di sorveglianza del mercato. Le linee guida tecniche che CEN/CENELEC sta sviluppando, con uno standard orizzontale atteso entro metà 2026, chiariranno ulteriori aspetti applicativi, inclusa la questione interpretativa sull’estensione dell’obbligo alle dipendenze transitive oltre quelle di primo livello.

Parallelamente, il quadro normativo si articola su più livelli: la Direttiva NIS2 richiede alle organizzazioni essenziali e importanti di gestire i rischi della catena di fornitura, inclusa la sicurezza dei componenti software; il DORA impone agli enti finanziari controlli stringenti sulle dipendenze tecnologiche critiche; in ambito statunitense, l’Executive Order 14028 del 12 maggio 2021 ha reso l’SBOM un requisito per i fornitori software del governo federale, stabilendo un precedente che ha accelerato l’adozione globale. Per i produttori di software e di dispositivi connessi che operano su mercati internazionali, l’SBOM non è più una scelta architettuale: è un requisito di mercato. Per un approfondimento sugli adempimenti NIS2 in scadenza, si veda anche questo articolo di ICT Security Magazine.

Cosa è (davvero) un SBOM

Un Software Bill of Materials è un inventario formale e leggibile da macchina di tutti i componenti che compongono un artefatto software: librerie di terze parti, dipendenze transitive, moduli open source, pacchetti interni, strumenti di build incorporati. Ogni componente è descritto da un insieme di attributi minimi che ne permettono l’identificazione univoca e la correlazione con le basi di dati delle vulnerabilità note.

Il National Telecommunications and Information Administration (NTIA) statunitense ha definito nel luglio 2021, in attuazione dell’EO 14028, i sette campi dati minimi che ogni SBOM deve contenere:

• Nome del produttore (Producer Name) del componente;
• Nome del componente (Component Name);
• Versione del componente;
• Identificatore univoco aggiuntivo, quali Package URL (PURL), Common Platform Enumeration (CPE) o SWID tag;
• Relazione di dipendenza con il componente padre;
• Autore dei dati SBOM (SBOM Author);
• Timestamp di generazione.

È importante precisare che l’hash crittografico del componente, spesso citato erroneamente come campo obbligatorio, non rientra nei sette campi minimi della versione originale NTIA 2021: il documento lo classifica esplicitamente tra i campi “beyond minimum”, ovvero raccomandati per casi d’uso ad alta garanzia ma non obbligatori nella baseline. Solo la revisione proposta da CISA nell’agosto 2025, ancora in fase di commento pubblico al momento della redazione, propone di elevare l’hash a campo minimo obbligatorio, insieme a licenza e contesto di generazione.

Attorno a questi campi minimi esistono due formati standard che si sono affermati come dominanti nel settore, entrambi riconosciuti dal NTIA insieme al formato SWID.

SPDX (Software Package Data Exchange), mantenuto dalla Linux Foundation e pubblicato come standard internazionale ISO/IEC 5962:2021 nel settembre 2021, è nato in ambito open source e privilegia la completezza delle informazioni di licenza oltre che di sicurezza. Supporta formati di serializzazione multipli: tag-value, JSON, YAML, RDF e XML. La versione 3.0, rilasciata nell’aprile 2024, estende il modello a componenti hardware, AI, dati e sistemi di build.

CycloneDX, sviluppato da OWASP, è progettato esplicitamente per i casi d’uso di sicurezza: integra nativamente il concetto di VEX (Vulnerability Exploitability eXchange), supporta la descrizione di servizi e di componenti hardware, e dispone di un ecosistema di tool particolarmente maturo. È il formato preferito dalla maggior parte dei workflow DevSecOps moderni. Per un’analisi comparativa approfondita dei due formati nel contesto CRA, si veda l’articolo di ICT Security Magazine SBOM e Cyber Resilience Act: come SPDX 3.0 e CycloneDX ridefiniscono la sicurezza della supply chain software.

La scelta tra i due dipende dal contesto: SPDX è preferibile quando la gestione della compliance delle licenze open source è prioritaria o quando si opera in ecosistemi che richiedono la certificazione ISO; CycloneDX è più adatto quando l’obiettivo primario è l’integrazione nella pipeline di vulnerability management.

Il problema delle dipendenze transitive

Il valore di un SBOM si misura nella sua completezza, e la completezza è il problema più difficile da risolvere. Un’applicazione moderna non dichiara solo dipendenze dirette: ogni dipendenza diretta porta con sé le proprie dipendenze, e queste a loro volta le proprie, in un grafo che può raggiungere centinaia di nodi per un’applicazione di medie dimensioni.

Log4Shell ha dimostrato plasticamente questa criticità. La vulnerabilità CVE-2021-44228, divulgata pubblicamente il 9 dicembre 2021 e classificata con punteggio CVSS 10.0 su 10.0, colpiva il modulo log4j-core di Apache Log4j 2, una libreria di logging Java. L’exploit sfruttava le funzionalità JNDI (Java Naming and Directory Interface) per consentire l’esecuzione remota di codice arbitrario tramite una stringa di input appositamente costruita. Log4j2 era inclusa come dipendenza in numerosi framework Apache, tra cui Struts2, Solr, Druid e Flink, e in prodotti di sicurezza e infrastruttura ampiamente diffusi come Elasticsearch, Logstash e Apache Kafka. Le organizzazioni che non disponevano di un inventario completo delle dipendenze transitive hanno impiegato settimane per valutare la propria esposizione.

Un SBOM efficace deve quindi essere generato a partire dall’artefatto compilato, ossia il binario, il container o il pacchetto di distribuzione, e non soltanto dai file di manifesto del progetto sorgente come pom.xml, package.json o requirements.txt. Questi ultimi dichiarano le dipendenze intenzionali; i tool di analisi dell’artefatto rilevano le dipendenze effettive, incluse quelle introdotte indirettamente.

Questo approccio è tanto più rilevante considerando che il CRA, nella sua formulazione attuale, richiede le sole dipendenze di primo livello come minimo, ma le best practice di settore e le linee guida ENISA in sviluppo convergono verso la copertura completa del grafo delle dipendenze. Per il ruolo degli SBOM nella supply chain security in relazione alla NIS2, si veda l’intervento presentato al Forum ICT Security 2025 disponibile su ICT Security Magazine.

Tool open source per generare SBOM

L’ecosistema dei tool open source per la generazione di SBOM si è consolidato significativamente negli ultimi anni. Di seguito i principali, con le rispettive caratteristiche operative.

Syft (Anchore)

Syft è uno degli strumenti di generazione SBOM più diffusi nell’ecosistema cloud-native. Supporta container images, filesystem, archivi e artefatti in formato OCI ed è in grado di rilevare componenti in un’ampia varietà di ecosistemi: Java (Maven, Gradle), JavaScript (npm, yarn), Python (pip, poetry, conda), Go, Rust, Ruby, .NET, PHP, Swift e molti altri.

Syft si integra nativamente con Grype, il vulnerability scanner della stessa Anchore, creando un workflow coerente dalla generazione dell’inventario alla correlazione con le CVE.

Grype (Anchore)

Grype consuma SBOM generati da Syft (o da altri tool compatibili) e li correla con database di vulnerabilità multipli: NVD, GitHub Security Advisories, OSS-Index, RedHat, Ubuntu Security Notices e altri.

L’opzione –fail-on è particolarmente utile per l’integrazione in pipeline CI/CD: permette di bloccare il build se vengono rilevate vulnerabilità al di sopra di una soglia di severità definita.

Trivy (Aqua Security)

Trivy è un vulnerability scanner all-in-one che include capacità native di generazione SBOM. Supporta container, repository Git, filesystem, pacchetti Kubernetes e file di Infrastructure as Code.

Trivy è spesso preferito in ambienti Kubernetes per la sua capacità di aggregare l’analisi di sicurezza dell’infrastruttura con quella del software applicativo.

cdxgen (OWASP)

cdxgen è il generatore SBOM del progetto CycloneDX di OWASP e produce output nativamente in formato CycloneDX. Si distingue per la profondità dell’analisi in ecosistemi specifici, in particolare Java e JavaScript, e per la capacità di generare SBOM anche da codice sorgente senza dover compilare l’artefatto.

SBOM Tool (Microsoft)

Microsoft SBOM Tool è lo strumento rilasciato open source da Microsoft, progettato per funzionare in ambienti enterprise con build system eterogenei. Supporta sia SPDX che CycloneDX e si integra con i workflow Azure DevOps.

Integrare l’SBOM nella pipeline CI/CD

La generazione di un SBOM come attività manuale e occasionale non produce valore operativo. Per essere utile, l’SBOM deve essere generato automaticamente a ogni build, versionato insieme all’artefatto e consumato da sistemi di analisi che producono alert azionabili.

Un workflow CI/CD maturo per la supply chain security si articola tipicamente in cinque fasi.

Fase 1: Generazione. L’SBOM viene prodotto durante il build dell’artefatto, a partire dal risultato compilato. L’integrazione in GitHub Actions può avere questa forma:

Fase 2: Firma e attestazione. L’SBOM deve essere firmato crittograficamente per garantirne l’autenticità e la non ripudiabilità. Sigstore/Cosign è diventato lo strumento standard per la firma di artefatti software nel mondo cloud-native.

Fase 3: Archiviazione e versionamento. L’SBOM firmato viene archiviato in un repository dedicato, associato alla versione dell’artefatto. In ambienti container, una pratica emergente è quella di allegare l’SBOM direttamente all’immagine OCI come attestation, seguendo le specifiche SLSA (Supply-chain Levels for Software Artifacts).

Fase 4: Analisi continua delle vulnerabilità. Le CVE vengono scoperte dopo il rilascio del software. Un SBOM generato al momento del build deve essere analizzato periodicamente rispetto ai database di vulnerabilità aggiornati, non solo al momento della sua creazione. Tool come Dependency-Track (OWASP) permettono di caricare SBOM e ricevere notifiche automatiche quando nuove vulnerabilità vengono associate a componenti già in inventario.

Fase 5: VEX (Vulnerability Exploitability eXchange). Non tutte le vulnerabilità rilevate in un SBOM sono effettivamente sfruttabili nel contesto di deployment specifico. Il VEX è un documento complementare all’SBOM che permette al produttore di dichiarare lo stato di exploitability di ogni vulnerabilità identificata, secondo quattro stati possibili: not affected, affected, fixed e under investigation. CycloneDX supporta nativamente i VEX document, consentendo ai clienti finali di contestualizzare i risultati delle scansioni automatiche. Il requisito VEX è menzionato esplicitamente anche nelle raccomandazioni ENISA per il CRA.

Dependency-Track: la piattaforma operativa

Dependency-Track, progetto OWASP in stato di maturità avanzata, è la piattaforma open source di riferimento per la gestione continuativa degli SBOM in ambienti enterprise. Offre un’interfaccia web per l’importazione di SBOM in formato CycloneDX e SPDX, la correlazione automatica con database di vulnerabilità multipli, la gestione delle policy di sicurezza e l’integrazione con sistemi di notifica e ticketing.

Il deployment tramite Docker Compose è la modalità più comune per ambienti di sviluppo e staging:

Una volta avviato, Dependency-Track può ricevere SBOM tramite API REST, permettendo l’automazione del caricamento dalla pipeline CI/CD, e li analizza continuamente man mano che i database di vulnerabilità vengono aggiornati. Il sistema supporta l’integrazione con Jira, Slack, Teams e webhook generici per la notifica degli alert.

SBOM nella supply chain: estendere il perimetro

L’SBOM generato internamente copre il software prodotto dall’organizzazione. La supply chain security richiede però di estendere la visibilità anche ai componenti acquistati da fornitori terzi, compresi i prodotti COTS (Commercial Off-The-Shelf) e i sistemi embedded. Per un inquadramento normativo dell’interazione tra NIS2, DORA e CRA su questi temi, si rimanda alla lettura di NIS2 e oltre: la cybersicurezza diventa governance aziendale su ICT Security Magazine.

Il CRA stabilisce che i fabbricanti devono essere in grado di fornire l’SBOM alle autorità di sorveglianza del mercato su richiesta motivata. In parallelo si sta sviluppando una catena documentale lungo la supply chain: il produttore finale deve raccogliere gli SBOM dei componenti che integra, inclusi quelli dei propri fornitori, e produrre un SBOM composito che rappresenti l’intero stack software del prodotto.

In pratica questo impone di aggiornare i contratti con i fornitori di software per includere il requisito di fornitura dell’SBOM, e di definire processi per la verifica e l’integrazione degli SBOM ricevuti nella propria piattaforma di gestione. Le linee guida ENISA sulla sicurezza della supply chain e il documento NTIA sui minimi elementi forniscono i criteri di qualità che un SBOM ricevuto da un fornitore deve soddisfare per essere considerato valido.

Un aspetto spesso sottovalutato riguarda i componenti open source per i quali l’SBOM non viene fornito da un produttore identificato: in questo caso la responsabilità di generazione ricade sull’organizzazione che integra il componente, a prescindere dalla modalità di acquisizione.

Le sfide operative: cosa non funziona ancora

Nonostante la maturità crescente dell’ecosistema, alcune sfide operative restano aperte e richiedono consapevolezza.

Completezza versus precisione. Gli strumenti di analisi automatica tendono a generare falsi positivi, ossia componenti rilevati che non sono effettivamente presenti nell’artefatto finale, oppure a non rilevare componenti inclusi tramite meccanismi non standard. La qualità dell’SBOM dipende dalla configurazione dello strumento e dalla conoscenza del sistema di build utilizzato.

SBOM per firmware e sistemi embedded. L’analisi di componenti in sistemi embedded, firmware proprietari e stack software per OT/ICS è significativamente più complessa rispetto agli stack applicativi tradizionali. Tool specializzati come Binwalk sono in grado di estrarre e analizzare layer da immagini firmware, ma richiedono competenze specifiche e producono risultati che necessitano di validazione manuale.

Aggiornamento e ciclo di vita. Un SBOM non aggiornato è peggio di nessun SBOM: genera falsa sicurezza. Ogni modifica al software, che si tratti di aggiornamento di dipendenze, refactoring o inclusione di nuovi componenti, deve innescare la rigenerazione dell’SBOM. Questo richiede che il processo di generazione sia completamente automatizzato e che esistano controlli per verificare che la versione dell’SBOM sia allineata alla versione del software in produzione.

Gestione delle licenze. L’SBOM espone non solo le vulnerabilità ma anche le licenze open source dei componenti inclusi. Licenze copyleft come GPL v3 possono avere implicazioni rilevanti per i prodotti commerciali. Una pipeline SBOM matura deve includere l’analisi delle licenze e la verifica della compatibilità con la politica di licensing dell’organizzazione. Tool come FOSSology (open source) o il modulo licenze di Dependency-Track supportano questo caso d’uso. Vale la pena notare che il draft CISA 2025 per i minimi elementi SBOM propone di elevare l’informazione di licenza a campo obbligatorio, a conferma della sua rilevanza operativa.

Un framework di implementazione in quattro livelli

Per le organizzazioni che devono strutturare un percorso di adozione, è utile pensare all’implementazione dell’SBOM secondo una progressione per livelli di maturità.

Livello 1: Visibilità di base. Generazione manuale o semi-automatica dell’SBOM per i prodotti principali, in formato CycloneDX o SPDX. Analisi periodica con Grype o Trivy. Obiettivo: avere un inventario documentato dei componenti critici.

Livello 2: Integrazione CI/CD. Generazione automatica dell’SBOM a ogni build, integrata nella pipeline. Alert automatici per vulnerabilità critiche. Archiviazione versionata degli SBOM. Obiettivo: nessun artefatto rilasciato senza SBOM aggiornato.

Livello 3: Gestione continua. Deployment di Dependency-Track o soluzione equivalente. Monitoraggio continuativo delle vulnerabilità anche per release già distribuite. Integrazione con il sistema di ticketing per la gestione della remediation. Produzione di VEX document per le vulnerabilità non exploitabili. Obiettivo: vulnerability management basato sull’inventario reale.

Livello 4: Supply chain estesa. Raccolta degli SBOM dai fornitori terzi. Verifica e integrazione nella piattaforma centrale. Politiche contrattuali che includono requisiti SBOM. Reportistica di compliance per il CRA e NIS2. Obiettivo: visibilità completa sull’intera supply chain software.

Conclusioni

L’SBOM non risolve il problema della sicurezza software: non impedisce che le vulnerabilità esistano e non sostituisce le pratiche di secure development. Quello che fa è rendere possibile una risposta rapida ed efficace quando le vulnerabilità vengono scoperte, che è esattamente il punto critico messo in luce da attacchi come SolarWinds e Log4Shell.

Il Cyber Resilience Act ha trasformato questa capacità da best practice in requisito normativo. Le organizzazioni che si trovano oggi a dover dimostrare compliance hanno un vantaggio se interpretano il percorso di adozione non come un adempimento documentale ma come un’opportunità per costruire infrastruttura operativa: pipeline automatizzate, inventari vivi, processi di risposta agili.

L’ecosistema open source offre oggi strumenti sufficientemente maturi per coprire l’intero ciclo, dalla generazione alla firma, dall’archiviazione all’analisi continua, senza richiedere investimenti in soluzioni commerciali nella fase iniziale. Il costo reale dell’implementazione non è tecnologico: è organizzativo, e riguarda la capacità di mantenere l’SBOM sincronizzato con il software reale nel tempo. È lì che si misura la differenza tra un documento di compliance e uno strumento operativo.