Per anni, la gestione delle vulnerabilità nei prodotti software è rimasta una pratica informale per la maggioranza delle aziende europee. I vendor più maturi avevano una casella di posta security@ e qualche procedura interna; i più piccoli gestivano le segnalazioni caso per caso, spesso con approcci reattivi e improvvisati.
I ricercatori di sicurezza che scoprivano falle nei prodotti altrui navigavano in un territorio giuridicamente ambiguo, oscillando tra la collaborazione e il rischio di azioni legali.
Indice degli argomenti
Vulnerability Disclosure Policy: il nodo che il CRA porta in superficie
Il Cyber Resilience Act, il Regolamento europeo 2024/2847 pubblicato in Gazzetta Ufficiale dell’Unione Europea nell’ottobre 2024 e con applicazione progressiva fino al 2027, chiude questa stagione di ambiguità.
Per la prima volta in Europa, i fabbricanti di prodotti con elementi digitali hanno obblighi legali precisi sulla gestione e la comunicazione delle vulnerabilità: canali di segnalazione accessibili, tempi di risposta definiti, notifiche alle autorità con scadenze stringenti.
La Vulnerability Disclosure Policy smette di essere una buona pratica facoltativa e diventa un requisito normativo.
Ma la conformità al CRA è solo metà del problema. L’altra metà è gestire la comunicazione delle vulnerabilità senza trasformare ogni disclosure in una crisi di immagine. Perché una falla di sicurezza resa pubblica in modo goffo, intempestivo o incompleto può danneggiare la reputazione di un’azienda molto più della vulnerabilità in sé.
Proviamo, dunque, ad affrontare entrambe le dimensioni: il piano normativo e quello comunicativo, con un approccio pratico orientato a chi deve costruire o aggiornare la propria VDP oggi.
Cos’è una Vulnerability Disclosure Policy
Una Vulnerability Disclosure Policy è il documento che definisce come un’organizzazione riceve, gestisce e comunica le segnalazioni di vulnerabilità nei propri prodotti o servizi.
Non è un documento tecnico: è un impegno pubblico che stabilisce le regole del gioco tra il vendor, i ricercatori di sicurezza e gli utenti. La sua funzione principale è duplice: da un lato, fornire ai ricercatori un canale sicuro e legalmente protetto per segnalare le vulnerabilità; dall’altro, garantire al vendor un processo strutturato per gestirle prima che diventino di dominio pubblico.
Avere una casella di posta security@ senza una VDP è come avere un numero di telefono d’emergenza senza un piano di crisi. Il canale esiste, ma non esiste il processo: non è chiaro chi riceve la segnalazione, chi la valuta, in quanto tempo risponde, cosa succede se il ricercatore non ottiene risposta, se e quando la vulnerabilità verrà comunicata pubblicamente.
In questo vuoto, i ricercatori più pazienti aspettano; quelli meno pazienti pubblicano. E quando pubblicano senza coordinamento, il vendor si trova a gestire una crisi invece di una disclosure ordinata.
VDP vs Bug Bounty: differenze strutturali e obiettivi diversi
La Vulnerability Disclosure Policy e il Bug Bounty Program sono strumenti distinti con obiettivi diversi, spesso confusi anche da chi lavora nel settore.
La VDP è un framework di gestione delle segnalazioni: definisce il processo, le regole e le protezioni legali per chi segnala. Non prevede necessariamente una remunerazione economica per il ricercatore, ma garantisce che la segnalazione venga presa in carico, gestita con serietà e risolta entro tempi ragionevoli.
Il suo obiettivo primario è la riduzione del rischio attraverso la collaborazione strutturata con la comunità di sicurezza.
Il Bug Bounty Program aggiunge alla VDP un meccanismo di incentivazione economica: i ricercatori che trovano e segnalano vulnerabilità ricevono un compenso in funzione della criticità della falla.
È uno strumento potente per attrarre talenti di sicurezza verso i propri prodotti, ma richiede risorse significative, sia economiche sia organizzative, e non è adatto a tutte le realtà.
Il Cyber Resilience Act non richiede un Bug Bounty Program: richiede una Vulnerability Disclosure Policy. Le organizzazioni che non hanno ancora nemmeno una VDP strutturata dovrebbero iniziare da lì, prima di valutare se e quando introdurre un programma di bug bounty.
I principi fondanti di una VDP efficace: safe harbour, tempi e canali
Tre elementi distinguono una VDP efficace da un documento di facciata.
Il primo è il safe harbour: una dichiarazione esplicita che il vendor non intraprende azioni legali nei confronti dei ricercatori che segnalano vulnerabilità in buona fede, nel rispetto delle regole definite dalla policy. Senza questa protezione, i ricercatori non segnalano: il rischio legale è troppo elevato. Il safe harbour deve essere redatto con attenzione giuridica, perché deve essere credibile e applicabile, non solo una formula di stile.
Il secondo elemento è la definizione chiara dei tempi: entro quanto il vendor conferma la ricezione della segnalazione (tipicamente 5 giorni lavorativi), entro quanto fornisce una valutazione preliminare della criticità (tipicamente 15-30 giorni), entro quanto si impegna a rilasciare una patch o una mitigazione (variabile in funzione della complessità, ma con un massimale dichiarato, spesso 90 giorni).
Il terzo elemento è la chiarezza dei canali: un indirizzo e-mail dedicato con chiave PGP per le comunicazioni cifrate, eventualmente affiancato da una piattaforma di disclosure gestita, e l’indicazione dello scope, ossia quali prodotti, servizi e sistemi sono inclusi nella policy e quali ne sono esplicitamente esclusi.
Il Cyber Resilience Act e gli obblighi di disclosure: cosa cambia concretamente
Il CRA introduce per la prima volta nell’ordinamento europeo un quadro normativo organico per la sicurezza dei prodotti digitali, con obblighi che toccano l’intero ciclo di vita del prodotto: dalla progettazione alla distribuzione, dalla gestione delle vulnerabilità al fine vita.
Per le aziende che sviluppano o distribuiscono software, hardware connesso o prodotti con componenti digitali, il CRA non è un aggiornamento incrementale della compliance esistente: è un cambio di paradigma.
A chi si applica il CRA e quali prodotti coinvolge
Il perimetro di applicazione del CRA è ampio: si applica a tutti i prodotti con elementi digitali immessi sul mercato dell’Unione Europea, intendendo per tali qualsiasi prodotto software o hardware che elabora dati in modo diretto o indiretto attraverso una connessione di rete.
Rientrano nel perimetro smartphone, router, telecamere IP, software applicativo, sistemi operativi, componenti software integrati in prodotti fisici, e molto altro.
Il regolamento distingue tre categorie di prodotti in funzione del livello di rischio:
- prodotti standard (la grande maggioranza);
- prodotti critici di Classe I (che includono browser, gestori di password, software di sicurezza, sistemi di controllo degli accessi);
- prodotti critici di Classe II (che includono sistemi operativi per uso industriale, hypervisor, firewall industriali, microprocessori).
Le classi più critiche sono soggette a requisiti di conformità più stringenti, inclusa la valutazione da parte di organismi notificati. Per tutte le categorie, gli obblighi di gestione e notifica delle vulnerabilità si applicano in modo uniforme.
Le scadenze di notifica del CRA: 24 ore, 72 ore e disclosure coordinata
Il CRA introduce un regime di notifica delle vulnerabilità attivamente sfruttate che richiama, per logica e struttura, quello previsto dalla NIS2 per gli incidenti di sicurezza.
Quando un fabbricante viene a conoscenza di una vulnerabilità attivamente sfruttata nel proprio prodotto, ha l’obbligo di notificare l’ENISA (Agenzia dell’Unione Europea per la Cybersicurezza) e gli CSIRT nazionali competenti entro 24 ore dalla scoperta, con una notifica preliminare che include la descrizione della vulnerabilità e, ove disponibile, delle misure di mitigazione o correzione.
Entro 72 ore dalla scoperta, la notifica deve essere aggiornata con informazioni più dettagliate sulla natura della vulnerabilità, i prodotti interessati, la severità stimata e lo stato delle contromisure.
Entro 14 giorni dal rilascio di una patch o di una misura di mitigazione, il fabbricante deve inviare una relazione finale che includa la descrizione completa della vulnerabilità, le cause radice, le versioni interessate e la soluzione adottata.
Questi obblighi si applicano alle vulnerabilità attivamente sfruttate: per le vulnerabilità segnalate ma non ancora sfruttate, il CRA richiede la gestione attraverso un processo di Coordinated Vulnerability Disclosure, senza le medesime scadenze di notifica immediata alle autorità.
Il rischio reputazionale nella gestione delle vulnerabilità: anatomia di una crisi
La maggioranza delle crisi reputazionali legate alle vulnerabilità software non nasce dalla vulnerabilità in sé, ma dalla gestione della sua comunicazione.
I clienti, i partner e i media sono generalmente disposti ad accettare che il software abbia bug (è una realtà universalmente riconosciuta). Ciò che non accettano è la scoperta che un vendor sapeva di una vulnerabilità e non ha agito, ha cercato di minimizzarla o ha gestito la comunicazione in modo opaco.
Quando la disclosure diventa un danno: i casi in cui la comunicazione peggiora la situazione
Ci sono scenari ricorrenti in cui la gestione della disclosure amplifica il danno reputazionale invece di contenerlo.
- Il primo è la scoperta tardiva: il vendor rilascia una patch senza comunicare la natura della vulnerabilità corretta, ma un ricercatore indipendente analizza il patch diff e pubblica i dettagli tecnici completi. Il vendor si trova nella posizione peggiore possibile: ha tentato di silenziare il problema, non ci è riuscito, e ora deve gestire sia la vulnerabilità che la percezione di opacità.
- Il secondo scenario è la risposta legale ai ricercatori: un vendor invia una diffida a un ricercatore che ha scoperto e segnalato una vulnerabilità, accusandolo di accesso non autorizzato ai sistemi.
- La notizia si diffonde rapidamente nella comunità di sicurezza, il vendor viene boicottato dai ricercatori e perde l’accesso a un canale di segnalazione volontaria che aveva un valore enorme.
- Il terzo scenario è la disclosure prematura da parte del ricercatore: dopo settimane o mesi senza risposta dal vendor, il ricercatore pubblica i dettagli della vulnerabilità. Il vendor è impreparato, non ha una patch pronta, e deve gestire una crisi in condizioni di massima pressione.
Tutti e tre questi scenari sono prevenibili con una VDP ben strutturata e applicata con coerenza.
La finestra di esposizione: come gestire il tempo tra scoperta e patch
Il periodo più delicato nella gestione di una vulnerabilità è quello che intercorre tra la scoperta da parte del ricercatore o del vendor stesso e il rilascio della patch.
In questo intervallo, la vulnerabilità esiste, è potenzialmente sfruttabile, e il numero di persone che ne è a conoscenza cresce progressivamente.
Gestire questa finestra richiede una strategia che bilanci tre esigenze spesso in tensione tra loro: dare al team di sviluppo il tempo necessario per produrre una patch di qualità, limitare la diffusione delle informazioni per ridurre il rischio di sfruttamento, e mantenere la fiducia del ricercatore che ha segnalato.
La pratica del 90-day disclosure (adottata da Google Project Zero e diventata uno standard de facto nel settore) stabilisce che il ricercatore pubblica i dettagli della vulnerabilità dopo 90 giorni dalla segnalazione, indipendentemente dallo stato della patch.
Questo approccio crea un incentivo forte per il vendor a rispettare i tempi, ma richiede che il vendor sia in grado di produrre una patch in quell’arco temporale.
Per vulnerabilità particolarmente complesse, l’estensione concordata dei tempi è possibile, ma deve essere negoziata esplicitamente con il ricercatore e comunicata in modo trasparente.
Come strutturare una Vulnerability Disclosure Policy conforme al CRA
Una Vulnerability Disclosure Policy conforme al CRA non è necessariamente un documento lungo o complesso. Deve essere chiaro, accessibile, giuridicamente solido e operativamente praticabile.
La tentazione di produrre un documento esaustivo che copra ogni scenario possibile si scontra con la necessità pratica di avere una policy che i ricercatori leggano effettivamente e che il team interno sia in grado di applicare con coerenza.
Gli elementi obbligatori di una VDP: scope, canali, tempistiche e safe harbour
Lo scope definisce cosa è coperto dalla policy: prodotti specifici, versioni, sistemi, domini. Una scope eccessivamente vaga genera ambiguità e richieste di segnalazione fuori perimetro; una scope troppo restrittiva scoraggia le segnalazioni legittime. La best practice è definire uno scope positivo (cosa è incluso) e uno negativo (cosa è esplicitamente escluso), con esempi concreti dove necessario.
I canali di segnalazione devono essere accessibili e funzionali: un indirizzo email dedicato con chiave PGP pubblica pubblicata, eventualmente affiancato da una piattaforma di terze parti come HackerOne, Bugcrowd o Intigriti per le organizzazioni che preferiscono una gestione strutturata.
Le tempistiche devono essere dichiarate e rispettate: il tempo di conferma della ricezione, il tempo di valutazione preliminare, il tempo massimo di risoluzione.
Il safe harbour deve essere redatto con linguaggio chiaro e non ambiguo, specificando le condizioni che il ricercatore deve rispettare per beneficiarne e che tipicamente sono:
- non sfruttare la vulnerabilità per accedere a dati di terzi;
- non divulgare i dettagli prima della risoluzione concordata;
- agire in buona fede;
- limitarsi al necessario per dimostrare l’esistenza della vulnerabilità.
Il processo interno: dal ricevimento della segnalazione alla chiusura coordinata
La VDP pubblica è la faccia esterna del processo; il processo interno è ciò che determina se quella policy viene rispettata nella pratica.
Il processo interno deve definire:
- chi riceve e filtra le segnalazioni in ingresso;
- chi ha la responsabilità tecnica di valutare la criticità della vulnerabilità;
- chi coordina la comunicazione con il ricercatore;
- chi autorizza la comunicazione esterna e quando.
Un elemento spesso sottovalutato è la gestione del duplicato: cosa succede quando la stessa vulnerabilità viene segnalata da più ricercatori indipendentemente, oppure quando il vendor scopre internamente una vulnerabilità già segnalata da un ricercatore esterno.
Il processo deve prevedere questi scenari e definire come vengono gestiti, anche in termini di comunicazione con i ricercatori coinvolti.
La chiusura coordinata, ossia il momento in cui il vendor e il ricercatore concordano la data e le modalità della disclosure pubblica, è il passaggio finale del processo e richiede comunicazione proattiva, non reattiva.
Coordinated Vulnerability Disclosure: il modello europeo e il ruolo degli CSIRT
Il CRA adotta esplicitamente il modello della Coordinated Vulnerability Disclosure (CVD) come approccio standard per la gestione delle vulnerabilità.
La CVD è un processo in cui il ricercatore che scopre una vulnerabilità la segnala al vendor in modo riservato, dandogli il tempo necessario per sviluppare e distribuire una correzione prima che i dettagli vengano resi pubblici.
È un modello basato sulla collaborazione e sulla fiducia reciproca, che richiede regole chiare e rispettate da entrambe le parti.
Come funziona la CVD e quando coinvolgere le autorità
Il processo CVD standard prevede quattro fasi.
- La prima è la segnalazione riservata: il ricercatore comunica la vulnerabilità al vendor attraverso i canali definiti dalla VDP, con tutti i dettagli tecnici necessari per la riproduzione.
- La seconda è la verifica e la valutazione: il vendor conferma la ricezione, verifica l’esistenza della vulnerabilità e ne valuta la criticità secondo framework standardizzati come il Common Vulnerability Scoring System (CVSS).
- La terza è lo sviluppo della correzione: il team tecnico produce la patch o la mitigazione, con un timeline concordato con il ricercatore.
- La quarta è la disclosure coordinata: vendor e ricercatore concordano una data di pubblicazione e le modalità di comunicazione pubblica.
Il coinvolgimento degli CSIRT entra in gioco in due scenari principali. Il primo è quello previsto dal CRA per le vulnerabilità attivamente sfruttate, con le scadenze di notifica già descritte. Il secondo è quello in cui il processo CVD si inceppa: il vendor non risponde, rifiuta di riconoscere la vulnerabilità o non rispetta i tempi concordati.
In questo caso, il ricercatore può coinvolgere lo CSIRT nazionale come mediatore, e lo CSIRT può esercitare pressione sul vendor per sbloccare il processo.
È una valvola di sicurezza del sistema che il CRA formalizza e che le organizzazioni devono conoscere, sia come vendor che potrebbero essere coinvolti che come ricercatori che potrebbero utilizzarla.
La gestione dei ricercatori di sicurezza: dalla diffidenza alla collaborazione
Il cambio culturale più difficile per molte organizzazioni è passare da una postura difensiva (i ricercatori che trovano vulnerabilità nei nostri prodotti sono una minaccia) a una collaborativa (i ricercatori che trovano vulnerabilità nei nostri prodotti ci stanno aiutando a migliorare la sicurezza prima che lo facciano gli attaccanti).
Questo cambio non è solo filosofico: ha conseguenze pratiche dirette sulla qualità della VDP, sul rispetto dei tempi e sulla reputazione dell’organizzazione nella comunità di sicurezza.
I ricercatori di sicurezza sono un network altamente connesso e con memoria lunga.
Un vendor che risponde prontamente comunica in modo trasparente e riconosce pubblicamente il contributo dei ricercatori attraverso hall of fame, ringraziamenti nei security advisory o compensi economici, costruisce nel tempo una reputazione positiva che si traduce in un flusso di segnalazioni di qualità.
Un vendor che diffida, risponde con ritardi, minimizza o querela, si trova rapidamente in una situazione in cui i ricercatori più capaci evitano di segnalargli le vulnerabilità, e quelle vulnerabilità finiscono altrove.
Comunicare una vulnerabilità senza danneggiare il brand: il piano di comunicazione
La comunicazione esterna di una vulnerabilità è uno degli atti comunicativi più delicati che un’azienda tecnologica possa compiere.
Fatta bene, rafforza la fiducia: dimostra che il vendor prende la sicurezza sul serio, gestisce i problemi con trasparenza e mette gli utenti in condizione di proteggersi. Fatta male, amplifica il danno: attira attenzione mediatica negativa, genera panico tra gli utenti e offre agli attaccanti informazioni aggiuntive per sfruttare la vulnerabilità.
Il security advisory: struttura, tono e contenuto minimo
Il security advisory è il documento attraverso cui il vendor comunica pubblicamente una vulnerabilità. Non è un comunicato stampa, non è una nota legale, non è un post sul blog: è un documento tecnico con una struttura standardizzata che consente agli utenti e agli amministratori di sistema di valutare rapidamente il proprio livello di esposizione e le azioni necessarie.
Il contenuto minimo di un security advisory include: un identificativo univoco (tipicamente un CVE, Common Vulnerabilities and Exposures, assegnato da MITRE), la descrizione della vulnerabilità in termini comprensibili senza rivelare dettagli che facilitino lo sfruttamento, i prodotti e le versioni interessate, la severità secondo il punteggio CVSS, le misure di mitigazione disponibili nell’immediato, la patch disponibile con le istruzioni di aggiornamento, e il riconoscimento del ricercatore che ha segnalato (salvo sua esplicita rinuncia).
Il tono deve essere diretto, tecnico e privo di linguaggio evasivo: espressioni come “un potenziale problema di sicurezza” o “una situazione che potrebbe in alcune circostanze” erodono la credibilità e fanno percepire il vendor come evasivo.
Stakeholder interni ed esterni: chi informare, quando e come
Prima della disclosure pubblica, il vendor deve gestire una serie di comunicazioni riservate con gli stakeholder che hanno bisogno di sapere prima degli altri.
I clienti Enterprise con contratti di supporto attivi hanno spesso diritto a una notifica anticipata che consenta loro di pianificare l’aggiornamento senza essere colti di sorpresa dalla disclosure pubblica.
I partner tecnologici il cui prodotto dipende dal componente vulnerabile devono essere informati per aggiornare le proprie integrazioni. Il team legale e il management devono essere allineati prima che la notizia diventi pubblica.
La sequenza ottimale è quella che minimizza la finestra tra la preparazione della patch e la disclosure pubblica, massimizzando il tempo in cui gli utenti hanno accesso alla correzione prima che i dettagli tecnici della vulnerabilità siano di dominio pubblico.
In pratica: patch disponibile, notifica agli stakeholder enterprise, disclosure pubblica con security advisory, comunicazione ai media se la vulnerabilità ha rilevanza pubblica.
Ogni fase deve avere un responsabile identificato, un messaggio preparato in anticipo e un canale di comunicazione definito.
L’improvvisazione nella gestione della comunicazione di una vulnerabilità è la causa più frequente di crisi reputazionali evitabili: la Vulnerability Disclosure Policy, in ultima analisi, non è solo uno strumento di compliance. È un piano di crisi preventivo.
