vulnerabilità software

Cyber Resilience Act, la sfida delle 24 ore passa dalla SBOM

Dal settembre 2026 i produttori dovranno segnalare in 24 ore le vulnerabilità sfruttate attivamente. Una SBOM dinamica, aggiornata lungo la pipeline e collegata ai database delle falle, consente di individuare componenti esposti, stabilire le priorità e superare i limiti di un inventario statico

Pubblicato il 4 nov 2026

Elia Pinto

IT Professional; Vice Presidente dell’Associazione Cyber Actors

Chiedi all'AI

Riassumi questo articolo

Approfondisci con altre fonti

Aggiungi tra i preferiti su Google

Dall’11 settembre 2026 il Cyber Resilience Act obbliga i produttori a segnalare entro 24 ore le vulnerabilità sfruttate attivamente nei loro prodotti. Per farlo bisogna sapere in fretta quali componenti contiene ciascun prodotto. La SBOM richiesta dalla norma è il punto di partenza, ma se viene generata al rilascio e poi archiviata non risponde a questa domanda. Cosa serve davvero a produttori, fornitori e PA, e quali sono i limiti degli strumenti oggi disponibili.

Cyber Resilience Act, come gestire le segnalazioni nella filiera

Nel marzo 2024 Andres Freund, ingegnere di Microsoft, notò alcuni sintomi strani su installazioni Debian unstable: gli accessi SSH consumavano molta CPU e un tentativo di accesso richiedeva circa 0,8 secondi invece di 0,3. Indagando, scoprì una backdoor nascosta in xz, una libreria di compressione open source mantenuta per anni quasi soltanto dal suo creatore, Lasse Collin. L’operazione era cominciata più di due anni prima: il primo contributo dell’account “Jia Tan” risale all’ottobre 2021. Con il tempo quell’account aveva conquistato la fiducia del progetto, fino a diventarne co-responsabile della manutenzione.

Backdoor XZ: povera la cyber che ha bisogno di eroi

Il server SSH non usava xz direttamente. Debian e altre distribuzioni Linux, però, modificano OpenSSH per collegarlo a libsystemd, che a sua volta dipende dalla libreria di xz. La backdoor arrivava da lì. Le versioni compromesse, registrate come CVE-2024-3094, erano già entrate nei rami di sviluppo e in alcune distribuzioni a rilascio continuo, come Fedora Rawhide, Debian unstable, openSUSE Tumbleweed e Kali. Come scrisse lo stesso Freund nel messaggio con cui il 29 marzo 2024 rese pubblica la scoperta, le versioni compromesse non erano ancora state integrate su larga scala, e dove lo erano si trattava soprattutto di versioni non ancora rilasciate. Il danno fu evitato quasi per caso.

Indice degli argomenti

SBOM dinamica: cosa insegnano xz e Log4Shell

Con Log4Shell, due anni e mezzo prima, andò diversamente. La vulnerabilità riguardava Log4j, una libreria Java che registra le attività delle applicazioni. Secondo il Cyber Safety Review Board statunitense, i primi sfruttamenti noti risalgono al 1° dicembre 2021, più di una settimana prima che la falla diventasse pubblica. Nel suo rapporto del luglio 2022 il Board osserva che imprese e fornitori faticarono a scoprire dove usassero Log4j, anche perché non esisteva un elenco dei prodotti in cui era integrata. E cita un dipartimento federale che dedicò 33.000 ore alla risposta.

I due casi pongono la stessa domanda: questo componente è presente nel nostro software? E dove si trova? La distinta dei componenti software, o Software Bill of Materials (SBOM), nasce per rispondere a questi interrogativi. È un inventario leggibile dai sistemi informatici. Elenca le librerie, i moduli e le relative versioni che compongono un prodotto.

Il Cyber Resilience Act europeo renderà la SBOM obbligatoria dall’11 dicembre 2027. Il rischio è che venga trattata come un semplice adempimento: un file JSON generato al rilascio e archiviato con la documentazione tecnica. Una SBOM così rispetta la lettera della norma, ma aiuta poco quando emerge una nuova minaccia come xz. Per essere utile deve restare aggiornata, includere anche le dipendenze indirette ed essere confrontata di continuo con le nuove vulnerabilità. In pratica, questo significa avere una SBOM “dinamica”.

La SBOM nel Cyber Resilience Act: obblighi e limiti

Il regolamento (UE) 2024/2847 è in vigore dal 10 dicembre 2024 e si applica in più fasi. Dall’11 settembre 2026 i produttori di prodotti con elementi digitali devono segnalare le vulnerabilità sfruttate attivamente e gli incidenti gravi. Per le vulnerabilità, i tempi sono stretti: preallarme entro 24 ore da quando il produttore ne viene a conoscenza, notifica entro 72 ore e relazione finale entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione.

Le segnalazioni passano attraverso una piattaforma unica e arrivano contemporaneamente all’ENISA e al gruppo nazionale per la risposta agli incidenti informatici (CSIRT) designato come coordinatore. La maggior parte degli altri obblighi, compresi i requisiti essenziali di sicurezza, si applica dall’11 dicembre 2027.

La SBOM compare nell’allegato I. Il produttore deve redigerla in un formato di uso comune e leggibile dai sistemi informatici, e deve includere almeno le dipendenze di primo livello. La SBOM fa parte della documentazione tecnica, che va tenuta a disposizione delle autorità di vigilanza del mercato per almeno dieci anni dall’immissione sul mercato, o per tutto il periodo di assistenza se più lungo. Le autorità possono chiederla con una richiesta motivata.

Il regolamento chiarisce invece, nel considerando 77, che il produttore non è obbligato a pubblicarla; se sceglie di metterla a disposizione degli utilizzatori, deve indicare dove trovarla. La Commissione può definire meglio formato ed elementi della SBOM con atti di esecuzione.

La parola decisiva è “almeno”. Le dipendenze di primo livello sono quelle dichiarate direttamente dallo sviluppatore. Nel caso di xz, una SBOM del server SSH limitata a questo livello non avrebbe mostrato la libreria compromessa. È comprensibile che il regolamento stabilisca un requisito minimo e verificabile. Ma per rispettare davvero il termine di 24 ore bisogna conoscere anche le dipendenze indirette.

In Italia l’articolo 15 della legge di delegazione europea 2025 (legge 17 marzo 2026, n. 36) delega il Governo ad adeguare la normativa nazionale al CRA entro sei mesi dall’entrata in vigore della legge. Tra i criteri c’è l’individuazione dell’Agenzia per la cybersicurezza nazionale (ACN) come autorità di notifica e come autorità di vigilanza del mercato, ai sensi degli articoli 36 e 52 del regolamento.

Per molte imprese questi doveri si aggiungono a quelli del decreto NIS2 (d.lgs. 138/2024). L’articolo 24 del decreto include, tra le misure di gestione del rischio, la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori diretti. E chiede di tenere conto della qualità complessiva dei prodotti e delle pratiche di sicurezza dei fornitori, comprese le loro procedure di sviluppo sicuro. Le organizzazioni soggette a NIS2 hanno quindi buone ragioni per chiedere ai fornitori come controllano i componenti software di terze parti. La SBOM è il documento più immediato per dimostrarlo.

Perché l’inventario software statico perde affidabilità

Il primo limite è la profondità dell’analisi. Molti strumenti e script interni leggono i file in cui lo sviluppatore dichiara le dipendenze: package.json per JavaScript, requirements.txt per Python e pom.xml per Java. Ogni libreria dichiarata, però, ne usa altre. Queste, a loro volta, possono richiamarne ancora. Le dipendenze indirette, dette transitive, possono essere molte. Uno studio presentato a USENIX Security nel 2019 ha calcolato che installare un pacchetto npm medio significa fidarsi implicitamente di 79 pacchetti di terze parti e di 39 manutentori.

Componenti che sfuggono ai file delle dipendenze

Ci sono poi i componenti che non passano dal gestore dei pacchetti. Per esempio: i file eseguibili copiati nell’immagine del container, il codice di terzi aggiunto a mano al repository e le librerie di sistema presenti nell’immagine di base. Un inventario costruito solo sui file delle dipendenze non li rileva.

Strumenti diversi, risultati diversi

Il secondo limite è l’affidabilità degli strumenti. Un gruppo di ricerca del KTH di Stoccolma ha confrontato sei strumenti che generano SBOM su 26 progetti Java open source. Lo studio, pubblicato nel 2023 su IEEE Security & Privacy, mostra che sugli stessi progetti gli strumenti individuano insiemi di dipendenze diversi. In uno dei progetti analizzati, solo 20 dipendenze sono state identificate correttamente da tutti e sei. Una SBOM è una misura: il risultato dipende anche dallo strumento usato.

Software in produzione e vulnerabilità cambiano nel tempo

Il terzo limite è il tempo. Il software in produzione cambia. Le immagini di base dei container vengono ricostruite con pacchetti aggiornati. Una correzione urgente può sostituire una libreria. In alcuni casi, nuovi componenti vengono installati direttamente nell’ambiente di produzione. Ciò che è in esecuzione oggi può quindi essere diverso da ciò che era stato descritto al momento del rilascio.

C’è infine un aspetto spesso trascurato. Anche una SBOM accurata cambia valore nel tempo, perché emergono nuove vulnerabilità. Un componente senza vulnerabilità note al momento del rilascio può ricevere una segnalazione critica, identificata da un codice CVE, mesi dopo. E questo può accadere senza modificare il software. Una SBOM “dinamica” deve quindi fare due cose: seguire i cambiamenti del software e confrontare di continuo l’inventario con le nuove vulnerabilità.

Come costruire una SBOM dinamica nella pipeline CI/CD

Il primo passo è generare automaticamente una SBOM per ogni versione del software. La generazione deve avvenire durante la compilazione, nelle procedure di integrazione e rilascio continui (CI/CD). In questo modo ogni versione ha il proprio inventario. I formati di riferimento sono due: CycloneDX, nato in ambito OWASP e standardizzato da Ecma International come ECMA-424, e SPDX, promosso dalla Linux Foundation e standardizzato come ISO/IEC 5962:2021.

Strumenti open source e policy gate

Tra gli strumenti open source ci sono Syft, sviluppato da Anchore, cdxgen del progetto CycloneDX e Trivy di Aqua Security. Le piattaforme commerciali, come Snyk, JFrog Xray e Anchore Enterprise, aggiungono spesso regole automatiche di controllo, dette policy gate. Queste regole possono bloccare la compilazione se rilevano un componente vietato, una versione con vulnerabilità note o una licenza incompatibile.

Archivi centrali e fonti sulle vulnerabilità

Generare le SBOM, però, non basta. Serve un archivio centrale per raccoglierle, versione per versione e prodotto per prodotto, e confrontarle di continuo con le fonti sulle vulnerabilità. Il principale strumento open source è OWASP Dependency-Track. Importa SBOM in formato CycloneDX e le verifica con fonti come la NVD statunitense, GitHub Advisories e OSV. Esistono anche piattaforme commerciali con cruscotti, collegamenti ai sistemi SIEM e portali per condividere le SBOM con i clienti. In Europa, dal 13 maggio 2025 l’ENISA gestisce la banca dati europea delle vulnerabilità (EUVD), prevista dall’articolo 12 della direttiva NIS2.

La differenza emerge quando viene resa pubblica una vulnerabilità critica. Senza un archivio, per sapere quali prodotti usano la versione vulnerabile bisogna cercare tra gruppi di lavoro, repository e fornitori: è la situazione che il Cyber Safety Review Board descrive per Log4j. Con un archivio aggiornato basta un’interrogazione. Da questa rapidità dipende la possibilità concreta di inviare il preallarme entro 24 ore.

SBOM dinamica e analisi di raggiungibilità

Un inventario più completo produce più avvisi. Più dipendenze indirette ci sono, più aumenta la probabilità che qualcuna abbia una vulnerabilità nota. Chi si occupa della sicurezza delle applicazioni può così ricevere liste troppo lunghe da verificare una per una. Spesso gli avvisi sono corretti: il componente è presente e vulnerabile. Ma l’applicazione potrebbe non usare mai la parte di codice difettosa.

L’analisi di raggiungibilità, in inglese reachability analysis, serve a capire se l’applicazione usa davvero il codice vulnerabile. Non confronta soltanto nomi e versioni con i database delle vulnerabilità. Ricostruisce anche il grafo delle chiamate, o call graph: la mappa delle funzioni che si richiamano tra loro. Poi verifica se il codice dell’applicazione può raggiungere la funzione vulnerabile della libreria.

Dal grafo delle chiamate alla priorità degli interventi

Un esempio chiarisce il metodo. Un’applicazione usa una libreria per leggere documenti in diversi formati. Una vulnerabilità critica riguarda il modulo che gestisce un formato mai usato dall’applicazione. Se l’analisi non trova un percorso verso quel modulo, il gruppo di lavoro può ridurre la priorità dell’avviso. Può quindi pianificare l’aggiornamento nel normale ciclo di rilascio, senza intervenire d’urgenza.

Virtual patching quando il codice vulnerabile è raggiungibile

Se il percorso esiste, lo strumento mostra la catena di chiamate fino alla funzione vulnerabile. Gli sviluppatori possono così individuare il punto su cui intervenire. Il gruppo di sicurezza può anche decidere se applicare una protezione temporanea in attesa della correzione. Per esempio, può aggiungere una regola al sistema che filtra il traffico verso l’applicazione, chiamato web application firewall. Questa tecnica è nota come virtual patching.

CVSS, EPSS e VEX nel contesto operativo

Il sistema comune di valutazione delle vulnerabilità (CVSS) ne misura la gravità intrinseca. Non indica quanto una falla sia grave per una specifica organizzazione. La versione 4.0, pubblicata da FIRST il 1° novembre 2023, affianca alle metriche di base quelle sulla minaccia e sull’ambiente, che tengono conto del contesto, più un gruppo di metriche supplementari. Secondo la guida di FIRST, però, le metriche di minaccia e di ambiente spettano a chi usa il software, mentre i produttori e database come la NVD forniscono di norma solo il punteggio di base.

Due fonti aiutano a decidere quali vulnerabilità affrontare prima. L’Exploit Prediction Scoring System (EPSS), sviluppato da FIRST, stima la probabilità che una vulnerabilità venga sfruttata nei trenta giorni successivi. Il catalogo delle vulnerabilità già sfruttate, o KEV, gestito dalla CISA, elenca invece i casi per cui lo sfruttamento è già noto.

Il Vulnerability Exploitability eXchange (VEX) serve a comunicare queste valutazioni all’esterno. È un documento leggibile dai sistemi informatici e collegato alla SBOM. Il produttore indica lo stato del prodotto rispetto a una vulnerabilità: interessato, non interessato, corretto o in analisi. Se dichiara “non interessato”, deve indicare una giustificazione o descriverne l’impatto. Una delle giustificazioni previste è che il codice vulnerabile non si trova nei percorsi di esecuzione.

I requisiti minimi del VEX sono stati definiti dalla CISA nell’aprile 2023; il documento indica tre formati in grado di esprimerlo: CSAF, CycloneDX e OpenVEX. Il vantaggio per il cliente è concreto: il suo strumento di controllo può smettere di segnalare una vulnerabilità già valutata e documentata dal fornitore.

I fornitori di strumenti per l’analisi di raggiungibilità dichiarano forti riduzioni degli avvisi da gestire. Endor Labs, per esempio, parla di riduzioni fino al 90% per le immagini dei container e fino al 95% per l’analisi a livello di funzione. Questi dati richiedono cautela: provengono dagli stessi fornitori, su casi scelti da loro, e i risultati cambiano in base al linguaggio e all’architettura dell’applicazione. Prima di basare un processo su queste stime, è quindi opportuno verificarle sul proprio codice.

Limiti dell’analisi nella gestione dinamica delle vulnerabilità

L’analisi statica della raggiungibilità ha limiti documentati. Un grafo delle chiamate costruito senza eseguire il programma può non vedere alcuni percorsi reali. Uno studio presentato a ICSE 2020 su programmi Java ha misurato questi buchi. Le cause principali non erano la reflection, come spesso si pensa, ma gli oggetti creati o usati tramite metodi nativi e le chiamate avviate dalla macchina virtuale Java, che non compaiono nel codice dell’applicazione.

Può sfuggire anche un percorso che dipende dalla configurazione e cambia da un’installazione all’altra. In questi casi il rischio non è un avviso in più. È un avviso in meno: una vulnerabilità reale può finire in fondo alla lista.

Con il CRA entra in gioco anche la responsabilità del produttore. Il regolamento gli chiede di affrontare e correggere tempestivamente le vulnerabilità dei propri prodotti. Un documento VEX che dichiara un prodotto “non interessato” orienta le decisioni dei clienti, che su questa base possono scegliere di non intervenire. Se la dichiarazione è sbagliata, resta aperta una vulnerabilità che il produttore era tenuto a gestire. È quindi prudente usare l’analisi di raggiungibilità per stabilire le priorità, non per chiudere da sola una segnalazione. Per le vulnerabilità critiche serve almeno una verifica umana.

C’è infine il problema dei costi. Per una grande azienda di software, l’infrastruttura descritta fin qui amplia procedure già esistenti. Per una piccola o media impresa (PMI) che produce firmware o applicazioni, la situazione è diversa. Anche se rientra nel CRA, mantenere strumenti open source richiede tempo e competenze. Per queste imprese il requisito minimo previsto dalla norma rischia quindi di diventare il massimo risultato possibile.

SBOM e vulnerabilità: le priorità per produttori, clienti e PA

Chi produce software o dispositivi connessi deve collegare la SBOM alla gestione delle vulnerabilità. Non basta inserirla nella documentazione tecnica. Occorre generarla a ogni compilazione, includere anche le dipendenze indirette e conservare l’inventario di ogni versione rilasciata. Il sistema deve permettere ricerche rapide quando emerge una nuova vulnerabilità. La domanda da porsi è semplice: quanto tempo serve oggi per sapere se sono esposti tutti i prodotti ancora supportati?

Chi acquista software, comprese le imprese soggette a NIS2 e le pubbliche amministrazioni, ha interesse a inserire la SBOM nei contratti e nei capitolati. Non basta chiederne la consegna. Occorre indicare il formato, la frequenza degli aggiornamenti e la profondità dell’inventario. Bisogna chiarire se comprende solo le dipendenze dirette o anche quelle indirette. Va inoltre specificato se il fornitore consegnerà i documenti VEX. Una SBOM fornita una sola volta, in PDF e alla firma del contratto, è poco utile.

Per i vertici aziendali il tema non è solo tecnico. Dall’11 settembre 2026 chi immette prodotti digitali sul mercato europeo deve segnalare entro 24 ore le vulnerabilità sfruttate attivamente nei propri prodotti, comprese quelle presenti nei componenti di terzi integrati nei prodotti: l’articolo 14 parla di qualsiasi vulnerabilità sfruttata “contenuta nel prodotto”. Clienti istituzionali e grandi committenti hanno quindi interesse a chiedere ai fornitori di dimostrare questa capacità.

La SBOM dinamica come metodo oltre gli obblighi di legge

La backdoor di xz è stata scoperta perché un ingegnere ha notato mezzo secondo di ritardo in un accesso. La sicurezza, però, non può dipendere dal caso.

La SBOM prevista dal Cyber Resilience Act elenca i componenti presenti nel software al momento del rilascio. Ma l’obbligo di segnalazione entro 24 ore richiede di più. Bisogna sapere quali componenti sono ancora in uso e quali espongono davvero l’organizzazione. La SBOM risponde alla prima esigenza. Per la seconda serve un controllo continuo. Le aziende che lo attiveranno prima del dicembre 2027 saranno più pronte ad affrontare minacce come quella di xz.