Bug bounty: cos'è e quando ha senso per un'azienda

Un bug bounty è un programma con cui un'azienda invita ricercatori di sicurezza esterni a cercare vulnerabilità nei propri sistemi, entro un perimetro e con regole pubblicate, e paga una ricompensa per ogni segnalazione valida. Si paga il risultato, non il tempo. Ha senso solo dopo due cose: un canale pubblico per ricevere le segnalazioni, la vulnerability disclosure policy, e un processo interno capace di correggere quello che arriva.

Qui il bug bounty è visto dal lato dell'azienda: come funziona, in cosa si distingue da penetration test e VDP, cosa serve prima di aprirne uno, cosa chiedono NIS2 e Cyber Resilience Act. In fondo c'è una sezione breve per chi cerca il bug bounty come lavoro.

Come funziona un bug bounty

L'azienda pubblica le regole del programma: quali sistemi si possono testare, quali tecniche sono escluse, come si invia una segnalazione, quanto vale ogni categoria di vulnerabilità. I ricercatori cercano e segnalano; l'azienda verifica, corregge e paga.

L'ENISA, nel report Coordinated Vulnerability Disclosure Policies in the EU dell'aprile 2022, descrive i programmi di bug bounty come iniziative di crowdsourcing che ricompensano i ricercatori per le vulnerabilità trovate e segnalate, e ne distingue due forme (resa nostra dall'inglese):

• Programmi pubblici: aperti a chiunque, con la possibilità di escludere singoli ricercatori in base ai loro precedenti.
• Programmi privati: su invito, riservati a ricercatori selezionati.

Lo stesso report ricorda che molte aziende, tra cui Microsoft, Mozilla e Google, gestiscono il programma in casa, mentre altre si appoggiano a piattaforme che fanno da intermediario tra chi possiede i sistemi e la comunità dei ricercatori, e cita come esempi Bugcrowd, HackerOne e YesWeHack.

Un ordine di grandezza lo dà un programma pubblico. Google scrive di aver assegnato nel 2025, con il suo Vulnerability Reward Program, oltre 17 milioni di dollari a più di 700 ricercatori, con un aumento di oltre il 40% rispetto al 2024 (VRP 2025 Year in Review, 31 marzo 2026). È la scala di una piattaforma globale, non un metro per un'azienda del mid-market: dice però quanto lavoro esterno un programma maturo riesce ad attirare.

Bug bounty, penetration test e VDP: tre cose diverse

Vulnerability disclosure policy (VDP)

Una VDP è la pagina in cui l'azienda dice come ricevere una segnalazione di vulnerabilità e cosa si impegna a fare. Non prevede ricompense. La CISA, l'agenzia statunitense per la cybersicurezza, con la Binding Operational Directive 20-01 del 2 settembre 2020 l'ha resa obbligatoria per le agenzie federali dell'esecutivo statunitense e ne elenca gli elementi:

• quali sistemi sono nel perimetro, e quali test sono ammessi e quali no;
• l'impegno a non raccomandare né intraprendere azioni legali contro chi fa ricerca in buona fede secondo la policy;
• dove e come inviare la segnalazione, con la possibilità di farlo in forma anonima;
• i tempi attesi per la presa in carico e la trasparenza sulle correzioni.

La stessa direttiva precisa che non obbliga le agenzie ad aprire programmi di bug bounty: la VDP è la base, la ricompensa è una scelta in più.

Penetration test

Un penetration test è un incarico: un team identificato, un perimetro concordato, una finestra di tempo, una metodologia e un report finale. Si paga il lavoro e si ottiene una copertura verificabile di quel perimetro. Il bug bounty rovescia il modello: molti ricercatori, tempi aperti, pagamento solo per ciò che trovano, nessuna garanzia su cosa verrà guardato. Come si svolge un test è spiegato nell'articolo sul penetration test.

In sintesi

• VDP: canale e regole per ricevere segnalazioni, senza compenso.
• Penetration test: verifica sistematica, a tempo, su un perimetro concordato, con un fornitore che firma il report.
• Bug bounty: ricerca continua e distribuita, pagata a risultato. Può trovare ciò che sfugge a una verifica a tempo, ma non sostituisce la copertura sistematica.

Non sono alternative: si costruiscono in quest'ordine.

Quando ha senso per un'azienda

Il report ENISA è franco sui limiti. Secondo gli intervistati, le organizzazioni sottovalutano spesso il costo di avvio di un bug bounty, e alcuni settori non lo vedono di buon occhio perché i dati trattati sono troppo sensibili per affidarli a soggetti esterni o perché temono la sottrazione di segreti industriali. La conclusione è che i programmi funzionano bene in alcune circostanze, per esempio nelle grandi aziende interessate a esternalizzare una parte della propria sicurezza.

Tradotto in criteri pratici, un bug bounty ha senso quando:

• la superficie esposta cambia spesso: applicazioni web, API, app mobili, prodotti software rilasciati di continuo;
• i test periodici trovano sempre meno: i penetration test chiudono con poche criticità e servono occhi diversi;
• c'è chi legge le segnalazioni in giorni, non in mesi, e un processo che porta la correzione in produzione;
• il budget regge un costo variabile, che dipende da quante vulnerabilità valide arrivano.

Se l'esposizione su internet è limitata, se le correzioni si accumulano già oggi o se nessuno ha il tempo di rispondere a un ricercatore, un bug bounty produce soprattutto segnalazioni in attesa. In quel caso conviene partire dai passi che seguono.

Cosa serve prima di aprirne uno

1. Un inventario di ciò che è esposto. Il perimetro del programma si scrive su asset noti: domini, applicazioni, API, ambienti. Senza inventario si rischia di invitare ricercatori su sistemi che nessuno sa di avere.
2. Una vulnerability disclosure policy pubblicata. Perimetro, test ammessi, canale di invio, tempi di risposta, impegno verso chi segnala in buona fede. Il file security.txt, definito dalla RFC 9116 (IETF, aprile 2022), dice ai ricercatori dove trovarla: per i servizi web va pubblicato nel percorso /.well-known/ del dominio e deve contenere almeno un contatto e una data di scadenza.
3. Un processo di gestione delle vulnerabilità che regge. Ricevere, riprodurre, classificare per gravità, correggere, verificare, rispondere a chi ha segnalato. I riferimenti sono la ISO/IEC 29147 (divulgazione delle vulnerabilità) e la ISO/IEC 30111 (processi di gestione delle vulnerabilità), che la direttiva NIS2 cita nel considerando 58.
4. Almeno un penetration test recente. Pagare un ricercatore per una falla che una scansione avrebbe trovato è il modo più caro di scoprirla. Prima si chiudono le vulnerabilità note con il vulnerability assessment e con i test, poi si apre alla comunità.
5. Regole economiche e legali scritte. Ricompense per livello di gravità, gestione dei duplicati, divieti (dati personali, interruzione del servizio, ingegneria sociale), tutela per chi rispetta le regole, e chi decide in caso di contestazione.

Il percorso tipico parte da un programma privato, con pochi ricercatori invitati e un perimetro stretto, e si allarga quando il team dimostra di reggere il ritmo.

Cosa chiedono NIS2 e Cyber Resilience Act

NIS2

Nessuna norma europea o italiana obbliga un'azienda ad avere un bug bounty. La NIS2 chiede però di saper ricevere e gestire le vulnerabilità.

• Il D.Lgs. 138/2024, all'articolo 24, comma 2, lettera e), mette tra le misure minime la "sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità".
• Le misure di base ACN (determinazione 379907/2025, allegati 1 e 2) lo traducono nella misura ID.RA-08: "Sono stabiliti processi per la ricezione, l'analisi e la risposta alle divulgazioni di vulnerabilità." In concreto chiedono di monitorare almeno i canali del CSIRT Italia e di eventuali CERT e ISAC di settore, di risolvere prontamente le vulnerabilità con aggiornamenti o mitigazioni oppure di accettare e documentare il rischio, e di avere un piano di gestione delle vulnerabilità approvato dagli organi di amministrazione e direttivi. Per i soggetti essenziali si aggiunge il monitoraggio dei canali dei fornitori del software ritenuto critico.
• L'articolo 16 dello stesso decreto, in attuazione dell'articolo 12 della direttiva (UE) 2022/2555, designa il CSIRT Italia coordinatore della divulgazione coordinata delle vulnerabilità: fa da intermediario di fiducia tra chi segnala e il fabbricante o fornitore, su richiesta di una delle parti, e consente di segnalare in forma anonima.

Le misure ACN non chiedono di pubblicare una VDP, tanto meno di pagare ricompense. Chiedono un processo che riceve, analizza e risponde: una VDP pubblica è il modo più diretto per aprirlo anche a chi trova un problema dall'esterno. Il quadro degli obblighi è nella guida completa alla NIS2.

Cyber Resilience Act

Per chi fabbrica prodotti con elementi digitali, software compreso, il Regolamento (UE) 2024/2847 va oltre. L'Allegato I, parte II, chiede ai fabbricanti di mettere in atto e applicare una "politica di divulgazione coordinata delle vulnerabilità" e di fornire un indirizzo di contatto per segnalare quelle individuate nel prodotto. Il regolamento si applica dall'11 dicembre 2027; gli obblighi di segnalazione dell'articolo 14 si applicano dall'11 settembre 2026. Il dettaglio è nell'articolo sul Cyber Resilience Act.

Se cerchi il bug bounty come lavoro

Molti di quelli che cercano bug bounty vogliono farlo, non aprirne uno. Tre cose oneste.

• Il reddito è variabile. Si viene pagati solo per segnalazioni valide e accettate, quindi le settimane senza risultati non rendono nulla. Conviene affiancarlo a un lavoro da penetration tester o da analista, almeno all'inizio.
• Il perimetro è la linea legale. Si testa solo ciò che il programma include, con le tecniche ammesse. In Italia l'art. 615-ter del codice penale punisce l'accesso abusivo a un sistema informatico protetto da misure di sicurezza, e la direttiva NIS2, nel considerando 60, riconosce che in alcuni Stati membri chi fa ricerca sulle vulnerabilità potrebbe essere esposto a responsabilità penale e civile. La segnalazione al CSIRT Italia prevista dall'art. 16 del D.Lgs. 138/2024 regola la comunicazione di una vulnerabilità, non autorizza prove sui sistemi altrui. Sul confine tra test e reato c'è l'articolo sull'ethical hacking.
• Conviene partire dal web. Servono basi solide di HTTP, autenticazione e logica applicativa, e la capacità di scrivere un report che chi corregge capisce al primo colpo. Le piattaforme pubblicano programmi aperti a chiunque, da cui si può cominciare.

Da dove partire

Per molte aziende del mid-market il primo passo non è il bug bounty: è una VDP pubblicata, un processo che dà seguito alle segnalazioni e penetration test periodici sui sistemi esposti. Il bug bounty arriva dopo, quando quella base regge. Se vuoi capire a che punto sei e cosa manca, i nostri servizi di cybersecurity partono da lì: inventario di ciò che è esposto, test, gestione delle vulnerabilità.