Divulgazione coordinata delle vulnerabilità: come funziona la procedura CVD dell’ACN

La divulgazione coordinata delle vulnerabilità, in inglese coordinated vulnerability disclosure (CVD), ha dal 7 ottobre 2026 una procedura nazionale. Quel giorno l’Agenzia per la cybersicurezza nazionale (ACN) ha comunicato l’adozione della Politica CVD, con determina del direttore generale Andrea Quacivi.

La Politica, di 16 pagine, spiega come segnalare una vulnerabilità al CSIRT Italia, che cosa fa l’agenzia dopo la segnalazione e in quanto tempo il fornitore deve intervenire. Non contiene una clausola di non punibilità per chi fa ricerca. Questa guida segue la procedura passo dopo passo, la confronta con le regole europee e con le politiche di Project Zero e del CERT/CC, e la mette alla prova con due casi recenti: l’alert del CSIRT Italia su Magistra e l’embargo rotto di PHP2Shell.

Che cos’è la divulgazione coordinata delle vulnerabilità

La direttiva NIS2 la descrive nel considerando 58: chi trova una vulnerabilità la segnala al fabbricante o al fornitore, che può così diagnosticarla ed eliminarla prima che i dettagli diventino pubblici. Il coordinamento riguarda anche i tempi di risoluzione e di pubblicazione.

Lo stesso considerando rimanda alle norme ISO/IEC 29147 e ISO/IEC 30111. Secondo la scheda ISO, la 29147:2018 fissa requisiti e raccomandazioni per i fornitori che ricevono le segnalazioni e pubblicano le informazioni di rimedio. Le attività tra la ricezione e la pubblicazione rientrano nella 30111. La 29147 è stata confermata nel 2024 e risulta da rivedere. Il rapporto tecnico ISO/IEC TR 5895:2022 applica le due norme ai casi con più parti coinvolte.

All’estremo opposto sta la full disclosure: rendere pubbliche subito le informazioni sulla falla. Il CERT/CC osserva che, senza una divulgazione responsabile e qualificata, chi scopre le vulnerabilità spesso sente di non avere altra scelta che pubblicarle per costringere i fornitori a intervenire. Tra i due estremi stanno le politiche di ricercatori e centri di coordinamento, che concedono al fornitore un termine e poi pubblicano; ne parla la sezione sull’embargo.

Dalla direttiva NIS2 alla Politica dell’ACN

L’articolo 12 della NIS2 impone a ogni Stato membro di designare un CSIRT come coordinatore. Il CSIRT fa da intermediario di fiducia tra chi segnala e il fabbricante o il fornitore, su richiesta di una delle parti. Individua e contatta i soggetti interessati, assiste chi segnala, negozia i tempi di pubblicazione e gestisce le vulnerabilità che toccano più soggetti. Gli Stati devono consentire la segnalazione anonima e, se l’impatto riguarda più Stati, i CSIRT cooperano nella rete.

L’articolo 16 del d.lgs. 138/2024 recepisce queste regole e designa il CSIRT Italia. Il comma 4 affida all’autorità nazionale competente NIS, cioè all’ACN, il compito di adottare la politica nazionale di divulgazione coordinata delle vulnerabilità e di realizzare i mezzi tecnici per applicarla.

La determina di adozione precisa che l’ACN ha acquisito l’intesa del Ministero della giustizia (comunicazione del 31 ottobre 2025) e ha sentito il Tavolo per l’attuazione della disciplina NIS (riunione del 18 dicembre 2025). Prevede inoltre che la Politica possa essere modificata e aggiornata periodicamente, anche a seguito di revisioni normative. La firma digitale reca la data del 6 ottobre 2026; l’ACN ne ha dato notizia il giorno dopo.

Il considerando 60 della NIS2 riguarda i ricercatori. Chiede agli Stati di affrontare, per quanto possibile, le difficoltà di chi fa ricerca sulle vulnerabilità, compresa l’esposizione alla responsabilità penale. Li incoraggia ad adottare linee guida sulla non perseguibilità e sull’esenzione dalla responsabilità civile. Il testo parla di incoraggiamento, non di obbligo.

Come segnalare una vulnerabilità all’ACN

Che cosa si può segnalare e chi può farlo

Secondo la pagina dell’ACN sulla CVD, la Politica si applica solo alle vulnerabilità zero day, cioè non ancora note al pubblico e sfruttabili da attori malevoli. Le altre restano fuori dal suo ambito. Può segnalare qualsiasi persona fisica o giuridica, anche in forma anonima.

Come si invia la segnalazione

La Politica indica come canale la piattaforma segnalazioni.acn.gov.it. Nella schermata iniziale, tra i profili di identificazione, compare la voce «CVD»; il portale chiede nome, cognome, email personale e un codice di sicurezza. Avverte anche che la segnalazione non costituisce denuncia, querela o esposto, per i quali rinvia alle forze di polizia e all’autorità giudiziaria. L’anonimato si richiede al momento della segnalazione.

La segnalazione deve contenere almeno:

• i riferimenti del segnalante, se non chiede l’anonimato;
• il servizio o il prodotto in cui ha trovato la vulnerabilità;
• la versione e la configurazione;
• per i protocolli e le specifiche, ogni implementazione nota;
• una descrizione dettagliata, con i passi per riprodurla e le possibili mitigazioni, se esistono;
• l’impatto sul servizio o sul prodotto;
• se la vulnerabilità è già stata segnalata al fornitore;
• se è già stato chiesto un CVE ID, indicando la CNA.

Sull’anonimato, la Politica dice che l’ACN tutela la riservatezza delle informazioni che potrebbero identificare il segnalante e che derivano dal mezzo usato, come indirizzo IP, email e numero di telefono. L’agenzia può comunque comunicare le informazioni alle autorità competenti, in particolare se ravvisa una notizia di reato.

Che cosa deve fare il segnalante

La Politica chiede a chi segnala di:

• verificare che si tratti di una vulnerabilità zero day;
• non agire oltre quanto prevede la normativa vigente;
• segnalare non appena ne ha consapevolezza;
• non condividere con terzi alcun dettaglio senza l’autorizzazione del CSIRT Italia, comprese le tecnologie usate per rilevare o sfruttare la vulnerabilità;
• fornire le informazioni necessarie alle analisi tecniche e collaborare se il CSIRT lo chiede.

Che cosa fa il CSIRT Italia dopo la segnalazione

La Politica divide il processo in tre fasi.

Fase 1: segnalazione e analisi preliminare

Il CSIRT Italia verifica se quanto segnalato sia davvero una vulnerabilità. Se non lo è, lo comunica al segnalante e il processo si chiude. Altrimenti assegna alla segnalazione un identificativo univoco, da usare nelle comunicazioni finché non esiste il CVE ID, e contatta il fabbricante o il fornitore.

Fase 2: validazione e cooperazione

Con il fornitore, e con il segnalante se serve, il CSIRT accerta che si tratti di uno zero day e che sia davvero sfruttabile. Se l’esito è negativo, il processo si chiude per mancata validazione. Se è positivo, il CSIRT:

• chiede alla CNA (CVE Numbering Authority) un CVE ID per ciascuna vulnerabilità validata;
• valuta gli impatti, anche transfrontalieri, e attiva la rete dei CSIRT se i soggetti coinvolti sono in più Stati membri;
• definisce, se serve, la misura di mitigazione e può comunicarla al pubblico prima della patch, dopo aver confrontato i costi con il rischio di sfruttamento;
• raccoglie dal fornitore i tempi di rilascio della patch.

Fase 3: divulgazione e tempi

Il CSIRT negozia con il fornitore tempi, modi e contenuti della pubblicazione, tenendo conto sia dei tempi della patch sia di quelli che servono agli utenti per aggiornare. La Politica fissa tre riferimenti:

• la mitigazione si individua entro 7 giorni solari dalla validazione, salvo elementi di elevata complessità;
• la patch si realizza entro 90 giorni solari dalla validazione, salvo elevata complessità o specifici rischi per l’utilizzatore che richiedano più tempo;
• la pubblicazione avviene a patch completata, salvo esigenze di pubblicazione anticipata, per esempio se risulta in corso uno sfruttamento diffuso.

A quel punto il CSIRT conclude il rilascio del CVE ID, pubblica il rapporto sul sito dell’ACN e alimenta la banca dati europea delle vulnerabilità gestita da ENISA. Se la vulnerabilità è molto diffusa, diffonde il rapporto anche sui canali social. Pubblica inoltre i CVE ID degli zero day più rilevanti, d’accordo con il fornitore, e si coordina con il segnalante sulla pubblicazione del suo nome se questi non ha chiesto l’anonimato.

Per gli scambi tra il CSIRT e il fornitore, la Politica indica come canale primario l’indirizzo cvdacn.gov.it, con cifratura PGP e scambio preventivo delle chiavi pubbliche. Chi segnala usa invece la piattaforma. I messaggi citano l’identificativo univoco e, dopo il rilascio, il CVE ID.

Il fornitore deve cooperare alle analisi e fornire gli elementi per valutare gli impatti, compresi i riferimenti degli utilizzatori. Deve inoltre individuare la mitigazione e produrre la patch nei tempi concordati. Se lo zero day è sfruttato attivamente, la Politica richiama l’obbligo di collaborare con l’ACN previsto dall’articolo 7, comma 1, lettera n-bis), del d.l. 82/2021.

Un caso concreto: l’alert su Magistra del 3 novembre 2026

Il 3 novembre 2026 alle 9:19 il CSIRT Italia ha pubblicato l’alert AL01/261103/CSIRT-ITA su Magistra, il software di Galeno Sistemi per la gestione del laboratorio galenico di farmacia. L’alert dichiara che i ricercatori di sicurezza hanno individuato le vulnerabilità e che il CSIRT le ha coordinate con il fornitore nell’ambito del processo CVD.

Le vulnerabilità sono quattro, tutte nella versione 3.12, con punteggio CVSS v4.0 tra 4,4 e 6,3:

• CVE-2026-112168: conservazione in chiaro di informazioni sensibili, con cifratura inadeguata e compressione obsoleta (6,0);
• CVE-2026-112169: aggiramento dell’autenticazione tramite una funzionalità di backdoor non documentata, che consentirebbe di creare un account privilegiato (6,1);
• CVE-2026-112170: scaricamento di codice senza controllo di integrità nella procedura di aggiornamento (6,3);
• CVE-2026-112171: gestione inadeguata dei dati inseriti dall’utente nelle query SQL (4,4).

L’ACN raccomanda di aggiornare attraverso i canali del fornitore e classifica l’impatto sistemico come medio (61,92). L’alert non riporta la data della segnalazione né quella della validazione, quindi su questo caso non si possono misurare i tempi di 7 e 90 giorni.

I limiti della Politica: responsabilità penale e obbligo di denuncia

La Politica richiama chi segnala al rispetto della legge: le attività di ricerca non devono integrare alcuna fattispecie criminosa. Gli esempi, non esaustivi, sono l’accesso abusivo a un sistema informatico (art. 615-ter del codice penale), l’intercettazione illecita di comunicazioni informatiche (art. 617-quater), il danneggiamento di dati e programmi (art. 635-bis) e il trattamento illecito di dati (art. 167 del d.lgs. 196/2003). Il comunicato dell’ACN ripete lo stesso avvertimento.

Il personale del CSIRT Italia ha la qualifica di pubblico ufficiale e, se ha notizia di un reato perseguibile d’ufficio, deve comunicare le informazioni all’autorità giudiziaria. Nella Politica non compare alcuna clausola di non punibilità per i segnalanti. La Relazione annuale al Parlamento 2025 dell’ACN conferma il punto: elaborata a legislazione vigente, la Politica non disciplina la tutela dei segnalanti sotto i profili della responsabilità civile e penale.

Una tutela è prevista, per ora solo come criterio di delega, nel disegno di legge S. 1441, presentato dal senatore Basso il 3 aprile 2025 nella XIX legislatura. Il testo delega il Governo a varare una strategia contro il ransomware. Alla lettera q) dell’articolo 1, comma 1, indica tra i criteri direttivi un «safe harbor», cioè una protezione giuridica per chi segnala in buona fede vulnerabilità informatiche rilevanti secondo le procedure di divulgazione responsabile. Finché non esistono i decreti legislativi, la posizione dei segnalanti non cambia.

Per il profilo penale si rinvia all’articolo di Maurizio Siracusa, pubblicato su ICT Security Magazine il 21 ottobre 2026. Tratta il rapporto tra la Politica, l’articolo 615-ter e le soluzioni adottate in altri Paesi europei.

Perché l’embargo si rompe

La Politica lega la pubblicazione alla patch. Un embargo regge però finché le informazioni restano in un cerchio ristretto, e ogni parte che le riceve ne allarga i confini. La guida del CERT/CC alla divulgazione coordinata osserva che una fuga diventa più probabile quando le parti aumentano e l’embargo si allunga. Aggiunge che le prove di sfruttamento attivo sono di norma un motivo per anticipare la divulgazione.

Le scadenze degli altri

Project Zero di Google concede al fornitore 90 giorni per la patch. Se la correzione arriva in tempo, pubblica i dettagli dopo altri 30 giorni. Su richiesta, un periodo di grazia di 14 giorni sposta la pubblicazione al giorno 120. Per le vulnerabilità sfruttate attivamente il termine è di 7 giorni, con una grazia di 3. Sono i termini della pagina attuale della politica, che richiama l’edizione 2021 del 15 aprile 2021.

Dal 29 luglio 2025 Project Zero applica una prova di trasparenza: rende pubblico entro una settimana che una vulnerabilità è stata segnalata al fornitore, con la scadenza dei 90 giorni. I termini non cambiano. Secondo le FAQ, la condivisione dei rapporti sotto embargo ha prodotto più rischio di fughe, rilasci più lenti e criteri di inclusione incoerenti. La politica generale di Google prevede lo stesso termine di 7 giorni per le falle sfruttate e ne spiega il motivo: ogni giorno in cui una falla sfruttata resta non divulgata e senza patch, più dispositivi o account vengono compromessi.

Il CERT/CC applica un termine predefinito di 45 giorni dalla segnalazione iniziale, a prescindere dalla disponibilità di patch o mitigazioni. Può anticiparlo o rinviarlo in circostanze eccezionali: sfruttamento attivo, minacce di natura particolarmente grave (o banale) e modifiche a uno standard consolidato. Informa i fornitori dei piani di pubblicazione e, quando serve, negozia con loro calendari alternativi.

La Politica dell’ACN, invece, non indica una data oltre la quale il CSIRT pubblica comunque. I 7 e i 90 giorni valgono per la mitigazione e la patch e sono estendibili. La pubblicazione segue la patch, salvo l’anticipo per sfruttamento diffuso.

Il caso PHP2Shell

Il caso PHP2Shell mostra come si rompe un embargo con molti partecipanti. Le fonti primarie sono il post della PHP Foundation del 21 ottobre 2026 e il comunicato congiunto di Commissione europea, ENISA, CERT-EU, Europol EC3 e rete dei CSIRT. La cronologia completa, con le fonti in disaccordo, è nell’articolo di ICT Security Magazine sul caso.

Le due vulnerabilità sono la CVE-2026-109618 e la CVE-2026-109619. Secondo la PHP Foundation, il primo indizio risale a un audit esterno del 2024, ma la correzione si è poi fermata per mesi: la Foundation la definisce un fallimento strutturale. Il 30 luglio 2026 Calif ha avviato un audit di PHP e l’11 agosto ha segnalato un’esecuzione di codice remota con la stessa causa. OpenAI ha segnalato in modo indipendente la stessa causa e Wiz ha aggiunto altri vettori. Le correzioni sono uscite il 21 ottobre 2026 nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35; il comunicato congiunto indica le 13:40 UTC.

La Foundation racconta che la divulgazione coordinata ha funzionato fino a due giorni prima della data prevista. Poi:

• il 20 ottobre, verso le 15:00 UTC, gli identificativi CVE hanno cominciato a circolare su forum e social, con un orario di rilascio sbagliato e un CVSS di 10,0 invece di 9,2; il post non indica chi li abbia diffusi;
• il progetto ha anticipato il preavviso alle 19:30 UTC e ha spostato il rilascio dal 22 ottobre alle 14:00 UTC al 21 ottobre alla stessa ora;
• verso le 20:00 UTC Calif, uno dei gruppi che avevano segnalato le falle, ha pubblicato per errore un video con una dimostrazione di sfruttamento; il video è stato cancellato, ma ne sono circolate copie;
• verso le 23:00 UTC la Foundation ha dato consigli di mitigazione a pochi fornitori di infrastrutture critiche, e riferisce che potrebbero essere trapelati;
• il 21 ottobre alle 07:41 UTC Chainguard ha pubblicato immagini con la correzione, oltre sei ore prima del rilascio concordato: la Foundation parla di rottura unilaterale dell’embargo.

Sempre secondo la Foundation, Chainguard, come altri distributori, aveva ricevuto la patch in anticipo, e il suo gruppo di sicurezza non ha individuato exploit funzionanti al momento del rilascio. Dan Lorenc, di Chainguard, ha spiegato la scelta in un post su LinkedIn del 21 ottobre. Scrive di avere pubblicato dopo che altri fornitori avevano confermato exploit in circolazione e di essersi rifatto alle linee guida della divulgazione coordinata sul rilascio in caso di sfruttamento. Racconta anche che Chainguard aveva ritrovato la falla in modo indipendente con un modello avanzato, e riconosce di avere aumentato lo stress dei manutentori. Sono affermazioni di Chainguard: il post non riporta le prove di sfruttamento che cita.

Una conferma esterna alla disputa viene da Amazon. In un post sul blog di sicurezza di AWS del 21 ottobre, Amazon Threat Intelligence dichiara di avere visto nei propri honeypot un tentativo di sfruttamento il 17 ottobre, quattro giorni prima della divulgazione. Cita anche più prove di concetto dalle 02:00 UTC del 21 ottobre, prima del rilascio previsto per le 14:00 UTC. Scrive di non sapere come l’autore abbia avuto le informazioni né se i tentativi avrebbero funzionato su sistemi reali. Ne ricava che l’embargo protegge i difensori solo finché nessun altro trova lo stesso errore, e che la divulgazione coordinata resta il modello giusto.

Cyber Resilience Act: cosa cambia per i fabbricanti

La Politica dell’ACN riguarda gli zero day segnalati da terzi. Il Cyber Resilience Act (regolamento UE 2024/2847) riguarda un altro punto del ciclo, quello delle vulnerabilità già sfruttate. Le sue regole di segnalazione sono operative dall’11 settembre 2026, come ricorda l’articolo di ICT Security Magazine sulle scadenze.

Il regolamento impone al fabbricante, all’articolo 14, di notificare ogni vulnerabilità attivamente sfruttata al CSIRT designato come coordinatore e all’ENISA, tramite la piattaforma unica di segnalazione. I termini sono tre: un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva. L’ENISA ha messo in funzione la prima fase della piattaforma l’11 settembre 2026, come annuncia il suo comunicato.

L’articolo 15 prevede anche una segnalazione volontaria: fabbricanti e altre persone fisiche o giuridiche possono notificare qualsiasi vulnerabilità a un CSIRT coordinatore o all’ENISA. Il paragrafo 5 stabilisce che la segnalazione volontaria non impone al notificante obblighi aggiuntivi, fatti salvi la prevenzione, l’indagine, l’accertamento e il perseguimento di reati.

La parte II dell’allegato I chiede ai fabbricanti di mettere in atto e applicare una politica di divulgazione coordinata delle vulnerabilità e di fornire un indirizzo di contatto per le segnalazioni. Secondo il considerando 126, il regolamento si applica dall’11 dicembre 2027, salvo gli obblighi di segnalazione già in vigore dall’11 settembre 2026.

Divulgazione coordinata delle vulnerabilità: che cosa cambia in pratica

Per chi trova uno zero day in un prodotto o in un servizio, la Politica offre un canale istituzionale con quattro caratteristiche:

• un intermediario, il CSIRT Italia, che contatta il fornitore al posto del segnalante;
• la possibilità di chiedere l’anonimato;
• un calendario di riferimento, con 7 giorni per la mitigazione e 90 per la patch;
• il rilascio del CVE ID e la pubblicazione del rapporto sul sito dell’ACN.

In cambio chiede riservatezza verso i terzi e il rispetto della legge, senza una clausola di non punibilità. Per i fornitori, la divulgazione coordinata delle vulnerabilità significa dare al CSIRT gli elementi per valutare l’impatto, indicare una mitigazione e consegnare la patch nei tempi concordati.

Sui tempi effettivi, l’alert su Magistra non offre ancora un riscontro, perché non riporta le date della segnalazione e della validazione. Il caso PHP2Shell, invece, mostra che anche un processo ben coordinato dipende dalla riservatezza di tutti i suoi partecipanti.

Domande frequenti

Come si segnala una vulnerabilità zero day all'ACN?

Si usa la piattaforma segnalazioni.acn.gov.it, scegliendo la voce CVD. La segnalazione può essere anonima e indica almeno prodotto, versione, descrizione, impatto e passi per riprodurre la vulnerabilità.

In quanto tempo il fornitore deve intervenire su una vulnerabilità segnalata all'ACN?

La Politica prevede la mitigazione entro 7 giorni solari dalla validazione e la patch entro 90 giorni solari. I termini si allungano per elevata complessità o per specifici rischi per l'utilizzatore.

La Politica CVD dell'ACN protegge i ricercatori dalle denunce penali?

No, il testo non contiene una clausola di non punibilità. Chiede che la ricerca non integri reati, come l'accesso abusivo dell'art. 615-ter, e prevede la comunicazione all'autorità giudiziaria dei reati perseguibili d'ufficio.

Si possono segnalare all'ACN anche vulnerabilità già note al pubblico?

No, la Politica si applica solo alle vulnerabilità zero day, cioè non ancora note al pubblico e sfruttabili da attori malevoli. Le altre restano fuori dal suo ambito di applicazione.

Che differenza c'è tra la Politica CVD dell'ACN e le segnalazioni del Cyber Resilience Act?

La Politica riguarda gli zero day segnalati da terzi al CSIRT Italia. L'articolo 14 del CRA obbliga invece i fabbricanti, dall'11 settembre 2026, a notificare le vulnerabilità già sfruttate entro 24 e 72 ore.