Il 7 ottobre 2026 l’Agenzia per la Cybersicurezza Nazionale ha annunciato l’adozione della Politica nazionale di divulgazione coordinata delle vulnerabilità, conosciuta come Coordinated Vulnerability Disclosure (CVD), dando attuazione a quanto previsto dall’articolo 16 del decreto legislativo 138/2024, che recepisce la direttiva NIS2.
Si tratta di un passaggio importante perché introduce un processo strutturato attraverso il quale i ricercatori possono segnalare vulnerabilità non ancora pubblicamente conosciute, affidando al CSIRT Italia il coordinamento delle attività con i produttori e i fornitori coinvolti, affinché possano individuare e adottare le necessarie misure correttive.
Il problema, tuttavia, non riguarda soltanto come segnalare una vulnerabilità, ma quali condizioni permettano di scoprirla, comunicarla e gestirla in un contesto di reciproca fiducia. Perché se da una parte stiamo costruendo un sistema normativo che impone alle organizzazioni una maggiore consapevolezza dei rischi informatici, dall’altra non abbiamo ancora risolto una contraddizione che riguarda direttamente il funzionamento della cyber security.
Chiediamo alle organizzazioni di conoscere i propri rischi, ma non abbiamo ancora costruito tutte le condizioni per favorire chi contribuisce a renderli visibili.
Indice degli argomenti
Il rischio non scompare perché nessuno lo segnala
Una vulnerabilità informatica esiste indipendentemente dal fatto che qualcuno l’abbia individuata, documentata o comunicata al responsabile del sistema. La sua mancata conoscenza non rappresenta una misura di protezione, ma una condizione di incertezza che può lasciare esposta l’organizzazione senza che questa ne abbia consapevolezza.
Nella gestione del rischio cyber, conoscere una debolezza significa poterla valutare, attribuirle una priorità, decidere come intervenire e verificare successivamente l’efficacia delle misure adottate. Ignorarne l’esistenza, al contrario, impedisce qualsiasi decisione consapevole.
Non tutte le vulnerabilità vengono scoperte attraverso assessment pianificati, penetration test commissionati o strumenti automatici. Alcune emergono da attività di ricerca indipendente, dall’analisi di componenti software, dall’esame di protocolli o da comportamenti inattesi delle applicazioni.
Il contributo dei ricercatori rappresenta quindi una possibile estensione delle capacità di identificazione delle vulnerabilità, certamente non un sostituto delle verifiche che ogni organizzazione deve pianificare e finanziare.
Il punto è comprendere come integrare questo contributo all’interno di un processo di governo del rischio, evitando che la scoperta di una debolezza si trasformi immediatamente in un problema di contrapposizione tra chi l’ha individuata e chi avrebbe dovuto prevenirla.
La NIS2 chiede di governare il rischio, non soltanto di documentarlo
La direttiva NIS2 ha introdotto una responsabilizzazione crescente degli organi di amministrazione e direttivi, chiedendo alle organizzazioni interessate di adottare misure tecniche, operative e organizzative proporzionate ai rischi.
Tra queste rientrano anche la sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi, comprese la gestione e la divulgazione delle vulnerabilità.
Non siamo quindi di fronte a un argomento estraneo alla compliance, ma a uno degli elementi che concorrono alla maturità del sistema di gestione della cybersecurity.
Una procedura che descrive come eseguire gli aggiornamenti software è utile, ma non esaurisce il problema. Occorre stabilire anche come vengono ricevute le segnalazioni, chi valuta la loro attendibilità, chi determina le priorità di intervento, quali informazioni devono essere condivise e come viene verificata la risoluzione della vulnerabilità.
Soprattutto, devono esistere responsabilità organizzative chiare.
Un CISO non dovrebbe trovarsi a negoziare ogni segnalazione come un caso eccezionale, così come un ricercatore non dovrebbe essere costretto a individuare casualmente il referente corretto o a interpretare il silenzio dell’organizzazione come un possibile segnale ostile.
La governance comincia quando le decisioni sono state progettate prima che il problema si manifesti. La documentazione serve a renderle esplicite, verificabili e ripetibili, non a sostituirle.
Il limite tra ricerca e accesso non autorizzato
Il riconoscimento del ruolo dei ricercatori non può naturalmente trasformarsi in una legittimazione indiscriminata delle attività di ricerca sui sistemi di terzi.
Una cosa è analizzare software legittimamente acquisito o svolgere verifiche nei limiti di un’autorizzazione, un’altra è accedere senza consenso a infrastrutture in produzione, consultare informazioni riservate o effettuare test potenzialmente destabilizzanti.
In Italia l’articolo 615-ter del Codice penale disciplina l’accesso abusivo a sistemi informatici o telematici, e la finalità dichiarata di voler segnalare una vulnerabilità non costituisce automaticamente un’esimente.
La stessa ACN, nella Relazione annuale al Parlamento sul 2025, aveva già evidenziato che la politica nazionale CVD, elaborata a legislazione vigente, non introduce una disciplina specifica di tutela dei segnalanti sotto il profilo della responsabilità civile e penale.
È una precisazione fondamentale. Non possiamo chiedere a una politica amministrativa di modificare le condizioni di applicazione della legge penale. Possiamo però domandarci se il quadro normativo sia ancora pienamente adeguato alle esigenze della sicurezza contemporanea.
Il considerando 60 della direttiva NIS2 incoraggia proprio gli Stati membri a considerare strumenti di tutela per i ricercatori, anche rispetto alla responsabilità penale e civile.
Non si tratta di garantire impunità, ma di individuare condizioni precise entro le quali una ricerca condotta in buona fede, con modalità necessarie e proporzionate, possa concorrere alla sicurezza collettiva senza generare un’incertezza giuridica sproporzionata.
La risposta delle organizzazioni misura la loro maturità
Esiste poi una questione sulla quale il legislatore non può intervenire da solo: il comportamento delle organizzazioni quando ricevono una segnalazione.
Una vulnerabilità comunicata responsabilmente non dovrebbe essere interpretata automaticamente come un attacco reputazionale. Dovrebbe innanzitutto attivare un processo tecnico di verifica, classificazione e gestione, ferme restando le necessarie valutazioni giuridiche sulle modalità attraverso cui è stata scoperta.
Questo significa definire preventivamente un canale di contatto, condizioni di ricerca eventualmente autorizzate, limiti operativi, criteri di gestione delle informazioni e modalità di comunicazione con il segnalante.
Significa anche misurare i risultati. Quanto tempo trascorre prima che una segnalazione venga presa in carico? Chi decide se la vulnerabilità è effettivamente sfruttabile? Qual è il tempo di mitigazione rispetto alla criticità e all’esposizione del sistema? Come vengono gestiti i casi nei quali il produttore non rende disponibile una correzione?
Sono domande di governance, non semplicemente questioni tecniche.
Una politica CVD pubblicata sul sito aziendale può essere un buon punto di partenza, ma diventa uno strumento effettivo soltanto quando trova corrispondenza in processi, ruoli, risorse e decisioni verificabili.
Dalla conformità alla responsabilità
Il percorso intrapreso con la NIS2 ha contribuito ad attribuire alla cybersecurity una collocazione più rilevante nei processi decisionali delle organizzazioni. Il rischio informatico non può più essere trattato esclusivamente come una questione delegata al reparto IT.
Proprio per questo, il tema della divulgazione coordinata delle vulnerabilità dovrebbe essere affrontato come parte della stessa trasformazione culturale.
Da una parte serve un legislatore capace di definire condizioni di tutela appropriate, evitando di confondere la ricerca responsabile con comportamenti realmente offensivi. Dall’altra servono organizzazioni mature, disposte a ricevere e trattare le segnalazioni come informazioni utili per assumere decisioni migliori.
La nuova politica ACN costituisce un tassello importante, ma il suo valore dipenderà anche dalla capacità di completare il quadro giuridico e di tradurre la collaborazione in pratiche operative concrete.
Abbiamo costruito una cybersecurity nella quale sappiamo sempre meglio chi deve rispondere quando si verifica un incidente. Dovremmo dedicare altrettanta attenzione a stabilire come riconoscere, organizzare e tutelare il contributo di chi può aiutarci a impedirlo.
Perché la maturità di un sistema di sicurezza non si misura soltanto dalla capacità di reagire a una vulnerabilità, ma anche dalla volontà di conoscerla prima che qualcuno decida di sfruttarla.
Partecipa alla community