Vulnerability Disclosure Program: come crearlo per la tua azienda e collaborare con gli ethical hacker

Ha tre opzioni: ignorare il problema (e tu resti esposto), venderlo a soggetti malintenzionati, oppure pubblicarlo sui social prima che tu possa correggere la falla, innescando una crisi di immagine. Nessuna delle tre opzioni è un risultato auspicabile.

Un Vulnerability Disclosure Program risolve esattamente questo problema. In questa guida trovi cos'è, perché è diverso da un Bug Bounty, come strutturare una policy in cinque elementi, cosa includere e cosa escludere nel perimetro di test e come gestire le segnalazioni senza costruire un SOC interno da zero.

Cos'è un vulnerability disclosure program (VDP) e a cosa serve

Un Vulnerability Disclosure Program è un canale strutturato e pubblico che permette a ricercatori di sicurezza, ethical hacker e chiunque individui una vulnerabilità nei tuoi sistemi di segnalarla in modo sicuro, legale e coordinato.

Il formato più comune è una pagina web dedicata, raggiungibile all'indirizzo security.tuodominio.it o come sezione del sito, che comunica poche cose essenziali:

• a chi inviare la segnalazione e con quale metodo;
• quali sistemi possono essere testati e quali no;
• quali protezioni legali ottiene il ricercatore che si comporta correttamente;
• entro quanto tempo riceverà una risposta.

L'obiettivo non è "invitare gli hacker". È sapere di avere una porta aperta prima che la trovino i criminali. Un ricercatore che segue le regole del tuo VDP ti segnala il problema prima che venga sfruttato, senza causarti danni e spesso senza chiederti nulla in cambio.

La Coordinated Vulnerability Disclosure è oggi considerata l'approccio più etico e sicuro per la gestione delle vulnerabilità nei sistemi informatici, perché permette di ridurre il rischio di attacchi durante il periodo di rimedio. Non è una pratica riservata alle grandi aziende: anche la Commissione Europea ha adottato la propria Vulnerability Disclosure Policy come standard istituzionale.

VDP vs Bug Bounty: perché non devi per forza pagare gli hacker

Questo è il malinteso più frequente tra i titolari di PMI. Sentono parlare di programmi di divulgazione delle vulnerabilità e pensano subito ai Bug Bounty di Google o Microsoft, con premi da decine di migliaia di euro per ogni falla trovata. E si fermano prima ancora di iniziare.

La confusione è comprensibile, ma VDP e Bug Bounty sono due cose diverse. Vediamo nel dettaglio in cosa si distinguono:

Ogni Bug Bounty include gli elementi di un VDP, ma non ogni VDP include premi in denaro. Non puoi gestire un Bug Bounty senza una policy di divulgazione, ma puoi avere un VDP efficace senza offrire nessun compenso economico.

Per una PMI italiana, dove il 43% degli attacchi informatici colpisce aziende di piccole e medie dimensioni, il VDP è il punto di partenza. Il Bug Bounty è un passo successivo, da valutare quando la maturità di sicurezza dell'organizzazione lo giustifica.

AI Security Readiness: sei pronto per la rivoluzione AI della cybersecurity?

SCARICA IL SELF ASSESSMENT TOOL

I 5 elementi essenziali di una policy VDP efficace 

Una policy VDP non è un documento legale complicato. È una pagina web chiara, che comunica regole semplici. I cinque elementi che non possono mancare derivano dall'analisi dei VDP più efficaci in circolazione.

1. La promessa del brand

L'apertura della policy dichiara che la sicurezza è una priorità. Non è un elemento formale: stabilisce il tono e comunica al ricercatore che la sua segnalazione verrà presa sul serio, non ignorata o usata contro di lui.

Un esempio concreto: "Ci teniamo alla sicurezza dei nostri sistemi e dei dati dei nostri clienti. Se hai trovato una vulnerabilità, vogliamo saperlo."

2. Il Safe Harbor (porto sicuro)

È la clausola legale più importante del documento. Il Safe Harbor garantisce al ricercatore che, se segue le regole definite nella policy, non verrà perseguito legalmente per le attività di test. Senza questa protezione, nessun ricercatore serio invierà mai una segnalazione: in Italia, le attività di test non autorizzate possono configurarsi come accesso abusivo a sistema informatico ai sensi dell'Art. 615-ter del Codice Penale.

3. Il canale di segnalazione

Indica esattamente come inviare la segnalazione: un indirizzo email dedicato (es. security@tuodominio.it), con indicazione opzionale di come cifrare il messaggio con PGP per proteggere i dati sensibili contenuti nel report.

4. Lo scope (perimetro di test)

Definisce quali sistemi possono essere testati (In-Scope) e quali sono esclusi (Out-of-Scope). Il perimetro deve essere preciso: l'ambiguità genera contenziosi e dissuade i ricercatori seri.

5. I tempi di risposta

Indica entro quanto tempo il ricercatore riceverà un primo feedback. Lo standard di mercato è 5 giorni lavorativi per la conferma di presa in carico. La trasparenza sui tempi è un segnale di rispetto verso chi segnala e aumenta la probabilità che il ricercatore mantenga riservata la vulnerabilità nel periodo di rimedio.

Cosa includere (in-scope) e cosa escludere (out-of-scope)

Definire il perimetro è una delle decisioni più concrete nella costruzione del VDP. La regola di base: includi i sistemi su cui hai visibilità e capacità di intervento, escludi tutto ciò che non controlli direttamente o che il test potrebbe danneggiare in modo non reversibile.

Sistemi che rientrano tipicamente nell'In-Scope:

• Il dominio principale del sito web aziendale e i sottodomini attivi;
• Le API pubbliche documentate;
• I portali di accesso clienti o partner;
• Le applicazioni web interne accessibili da internet.
• Attacchi di tipo DoS o DDoS (Denial of Service), che possono causare interruzioni di servizio reali;
• Phishing o social engineering rivolti ai dipendenti;
• Accesso o modifica di dati di clienti reali durante il test;
• Attacchi fisici agli uffici o ai dispositivi aziendali;
• Test su sistemi di terze parti non di proprietà dell'azienda.

Attività che rientrano tipicamente nell'Out-of-Scope:

La distinzione non è arbitraria. Le attività Out-of-Scope sono escluse perché il loro impatto è difficile da controllare, potenzialmente dannoso per soggetti terzi, o impossibile da distinguere operativamente da un attacco reale. Quel che è certo è che un perimetro chiaro protegge sia l'azienda sia il ricercatore.

Come gestire le segnalazioni: il processo di triage e remediation

Hai pubblicato la policy. Arriva la prima e-mail da un ricercatore. Cosa succede?

Questo è il punto in cui molte PMI si bloccano. Non per mancanza di volontà, ma per assenza di un processo definito. Chi apre quella mail? Chi verifica se la vulnerabilità è reale? Chi coordina la correzione senza bloccare le attività ordinarie?

Il flusso di gestione standard si articola in quattro fasi:

• Ricezione e acknowledgment. La segnalazione arriva al canale dedicato. Entro 5 giorni lavorativi, il ricercatore riceve una conferma scritta che il report è stato preso in carico. Questo primo feedback è obbligatorio per mantenere la fiducia del ricercatore e ridurre il rischio che pubblichi la vulnerabilità prima che tu abbia avuto il tempo di correggerla.
• Triage. Il team tecnico analizza la segnalazione per verificarne la validità. La vulnerabilità esiste davvero? Riguarda sistemi In-Scope? È già nota o già corretta? Il triage determina la priorità dell'intervento in base all'impatto potenziale.
• Remediation. Il team corregge la vulnerabilità, testa la correzione e verifica che il problema sia effettivamente risolto. Il ricercatore viene aggiornato sui progressi, almeno con una comunicazione a chiusura del processo.
• Chiusura e riconoscimento. Il caso viene chiuso formalmente. Se il VDP prevede una Hall of Fame pubblica, il nome del ricercatore viene inserito con il suo consenso. Questo riconoscimento, pur non economico, ha valore reale nella comunità della sicurezza.

Il problema pratico per le PMI è che questo processo richiede competenze tecniche specifiche e capacità di risposta costante. Affidarsi a un partner che svolga la funzione di filtro tecnico permette di validare le segnalazioni, escludere i falsi positivi e guidare la correzione senza che ogni email di un ricercatore esterno debba necessariamente arrivare all'IT interno.

Perché il VDP migliora la tua reputazione e la tua postura di sicurezza

Adottare un VDP produce effetti concreti su due dimensioni che spesso vengono tenute separate: la sicurezza tecnica e la percezione esterna dell'azienda.

Sul lato tecnico, il VDP apre un canale di intelligence esterna che i soli strumenti interni non possono replicare. I ricercatori operano in modo continuativo, con motivazioni diverse e angolazioni di attacco che il penetration test periodico non sempre intercetta.

Sul lato reputazionale, la logica è controintuitiva ma verificata: i tuoi clienti si fidano di più di un'azienda che ammette apertamente di poter avere vulnerabilità e dimostra di gestirle in modo strutturato, rispetto a una che non ne parla. La trasparenza è una forma di maturità, non di debolezza.

Sul fronte normativo, il quadro si sta consolidando rapidamente. Le Vulnerability Disclosure Policies introdotte con NIS2 sono strumenti che promuovono la creazione di un processo strutturato per la raccolta e la gestione delle segnalazioni da parte di ethical hacker. L'Art. 12 della direttiva formalizza l'obbligo di Coordinated Vulnerability Disclosure per i settori regolati e introduce una banca dati europea delle vulnerabilità (EUVD) gestita da ENISA.

Sotto NIS2 e EU 2024/2690, ogni passo del processo di divulgazione deve essere registrato, verificabile e collegato alla responsabilità del vertice aziendale. Anche per le organizzazioni non direttamente soggette alla direttiva, avere un VDP attivo è un elemento positivo nei questionari di due diligence dei clienti enterprise e negli audit di certificazione ISO 27001.

FAQ: domande frequenti sul vulnerability disclosure program 

What is a vulnerability disclosure program?

È un programma formale che un'organizzazione mette a disposizione per permettere a ricercatori di sicurezza e ethical hacker di segnalare vulnerabilità nei suoi sistemi in modo sicuro e legale. Definisce le regole di ingaggio: chi può testare, cosa può testare, come inviare la segnalazione e quali protezioni legali ottiene chi si comporta correttamente.

Cosa succede se non ho un VDP?

In assenza di un canale dedicato, un ricercatore che trova una falla nei tuoi sistemi non ha un modo sicuro per contattarti. Può scegliere di ignorare il problema, pubblicarlo sui social media prima che tu possa correggerlo, o venderlo a soggetti malintenzionati. L'assenza di un VDP non riduce il numero di vulnerabilità presenti: le lascia senza un canale di gestione controllata.

Devo pagare per le segnalazioni ricevute tramite VDP?

No. Un VDP puro non prevede compensi economici. Il riconoscimento al ricercatore avviene solitamente attraverso una Hall of Fame pubblica, che ha valore reputazionale nella comunità della sicurezza. I premi in denaro caratterizzano i Bug Bounty program, che sono un programma distinto, con costi e struttura diversa.

Chi gestisce le segnalazioni in arrivo?

La gestione ideale prevede un referente tecnico interno (IT Manager o CISO) e, se le risorse interne non sono sufficienti, un partner esterno con funzione di filtro tecnico. Il partner valida le segnalazioni, esclude i falsi positivi, assegna la priorità e coordina il processo di correzione, senza che ogni email di un ricercatore debba necessariamente arrivare al tuo IT interno.

Conclusione

Pubblicare un Vulnerability Disclosure Program non significa aprire le porte agli hacker. Significa costruire un canale formale che trasforma una potenziale crisi in un vantaggio operativo e reputazionale. Un ricercatore che ti segnala una vulnerabilità prima che venga sfruttata vale più di qualsiasi strumento di scansione automatica. Se vuoi capire come strutturare un VDP adatto alla tua realtà aziendale, dalla policy al processo di gestione delle segnalazioni, parla con un nostro consulente: in meno di un'ora puoi avere un quadro chiaro da dove partire e cosa serve davvero.