La fine del bug bounty?Immagine in evidenza rielaborata con intelligenza artificiale (ChatGPT)
L’applicazione dell’intelligenza artificiale nella cybersicurezza genera, da
sempre, sentimenti contrastanti. Le potenzialità dell’AI rappresentano, da una
parte, un’opportunità per migliorare il livello di automazione nelle attività di
rilevamento e risposta agli attacchi dei criminali informatici. L’altra faccia
della medaglia è rappresentata dalla possibilità che gli stessi cybercriminali
ne sfruttino le capacità per aumentare l’efficacia degli attacchi.
È qualcosa che sta già accadendo e che viene messo nero su bianco, per esempio,
nel Global Threat Report 2026 di CrowdStrike. Stando ai dati pubblicati dalla
società di cybersecurity, gli attacchi portati utilizzando l’AI sarebbero
aumentati dell’89% anno su anno.
Ma l’impatto dell’AI non si esaurisce negli attacchi veri e propri. La stessa
tecnologia che li accelera sta mettendo sotto pressione, in particolare,
l’ecosistema che fino a oggi ha garantito l’attività di identificazione e
analisi delle vulnerabilità software. In altre parole, l’AI sta rompendo gli
equilibri che per anni hanno permesso di mitigare il rischio di attacchi
informatici.
COME FUNZIONA LA VULNERABILITY DISCOVERY
Per comprendere l’impatto dell’AI in questo particolarissimo settore è
indispensabile comprenderne i meccanismi. La vulnerability discovery è infatti
una macchina complicata, in cui si intrecciano interessi diversi e convivono
varie contraddizioni.
Il concetto alla base del sistema è quello di individuare eventuali falle di
sicurezza di software e sistemi operativi prima che questi vengano scovati dai
cyber criminali. Un’attività che vede impegnate centinaia (migliaia) di aziende
e ricercatori indipendenti, spesso all’interno dei cosiddetti programmi di bug
bounty, cioè processi controllati attraverso i quali gli sviluppatori
ricompensano economicamente chi segnala una nuova vulnerabilità potenzialmente
pericolosa, permettendo loro di correggerla attraverso patch di aggiornamento.
L’importanza del fattore tempo emerge proprio nella fase finale del processo di
responsible disclosure, quando vengono rilasciati l’aggiornamento e i dettagli
della vulnerabilità. È in questo momento che si apre una finestra temporale
particolarmente delicata: quella in cui un cybercriminale può sfruttare la
vulnerabilità creando un exploit (la tecnica che permette di portare un attacco)
in grado di “bucare” i sistemi non aggiornati.
Fino a oggi, il tempo necessario per realizzare il codice che sfrutta una falla
di sicurezza per portare un attacco era, nella maggior parte dei casi, di
settimane o al massimo di qualche giorno. Un margine sufficiente perché gli
aggiornamenti venissero distribuiti. Di conseguenza, il rischio che qualcuno
rimanesse “scoperto” era relativamente basso.
A causa degli strumenti basati su intelligenza artificiale generativa, però, le
cose sono cambiate. Utilizzando l’AI è possibile realizzare un exploit con una
velocità prima impensabile. Secondo i ricercatori di sicurezza Efi Weiss e
Nahman Khayet, autori di un progetto dedicato, per creare un exploit con l’AI
partendo da una vulnerabilità nota sarebbero sufficienti anche solo 15 minuti.
UN’ONDATA DI SEGNALAZIONI
Lo scorso 7 aprile, un comunicato ufficiale di Anthropic ha scosso il settore
della cybersecurity. Oggetto dell’annuncio era il nuovo large language model
Claude Mythos Preview, che gli sviluppatori dell’azienda californiana hanno
sostanzialmente classificato come uno strumento troppo pericoloso per essere
distribuito pubblicamente. Il motivo? Il nuovo LLM sarebbe in grado di
individuare vulnerabilità all’interno dei software con un’efficacia senza
precedenti. Rilasciarlo pubblicamente, di conseguenza, sarebbe troppo rischioso.
L’azienda ha quindi deciso di avviare un progetto, battezzato con il nome di
Project Glasswing, che coinvolge un numero limitato di soggetti come Microsoft,
Apple, Google, AWS, Cisco, Nvidia e Linux Foundation. Qualche controindicazione,
però, è emersa quasi subito. Lo stesso giorno dell’annuncio, il 7 aprile, un
gruppo riunito in un forum Discord privato è riuscito ad accedere a Mythos — non
con un attacco sofisticato, ma combinando le credenziali del dipendente di un
fornitore terzo con un’ipotesi azzeccata sull’URL del modello. La vicenda è
emersa pubblicamente circa due settimane dopo, grazie a un’inchiesta di
Bloomberg. Considerato che Mythos era stato tratteggiato come una sorta di “arma
fine di mondo”, con accesso soggetto a strettissime restrizioni, non si tratta
proprio di un esordio rassicurante.
Al netto del sensazionalismo dell’annuncio, che secondo molti rappresenta un
marchio di fabbrica del marketing di Anthropic, la vicenda di Claude Mythos
Preview si inserisce in un fenomeno più ampio, che gli esperti di sicurezza
informatica stanno segnalando da tempo come estremamente problematico: la
crescita esponenziale del numero di vulnerabilità segnalate.
In sintesi, il problema non è tanto la possibilità che i gruppi dediti al cyber
crimine riescano a sfruttare gli LLM avanzati per individuare nuove
vulnerabilità zero-day (falle di sicurezza ancora sconosciute), quanto il fatto
che l’implementazione di strumenti automatizzati per l’analisi dei software sta
generando troppe segnalazioni rispetto a quelle che gli sviluppatori sono in
grado di gestire.
Una cosa, infatti, è individuare una falla. Un’altra è correggere il codice per
eliminare il rischio che la vulnerabilità venga sfruttata per portare un
attacco. Qualsiasi aggiornamento di un software o – a maggior ragione – di un
sistema operativo richiede infatti una serie di verifiche e test per validarne
l’efficacia e, non ultimo, escludere eventuali conflitti o “effetti collaterali”
indesiderati nel suo funzionamento. Insomma: rimediare a una vulnerabilità
richiede più impegno e più tempo rispetto a sfruttarla per scopi malevoli.
IL FATTORE TEMPO
A livello intuitivo, si potrebbe pensare che questo squilibrio tra il numero di
segnalazioni e la capacità di elaborarne il contenuto possa avere come
conseguenza un semplice rallentamento delle operazioni. Non è così.
Per prassi consolidata, infatti, il processo di responsible disclosure prevede
che al destinatario della segnalazione sia concesso un termine – solitamente di
60-90 giorni – entro il quale deve rilasciare l’aggiornamento. Trascorso il
termine, chi ha inviato la segnalazione è autorizzato a rendere pubblici i
dettagli della vulnerabilità.
Si tratta di un accorgimento che ha un duplice obiettivo. Il primo è quello di
evitare che lo sviluppatore possa “snobbare” la segnalazione, anche solo per
negare il meritato compenso del ricercatore che l’ha effettuata. La seconda è
quella di ridurre il rischio che qualcun altro scopra la falla o che questa
diventi pubblica per un qualsiasi motivo prima che l’aggiornamento sia
disponibile.
Anche se piuttosto rari, in passato si sono verificati casi in cui gli
sviluppatori non sono riusciti a rispettare la scadenza e si sono trovati di
fronte a una pubblicazione dei dettagli di una vulnerabilità quando non avevano
ancora preso le dovute contromisure. Nel nuovo scenario, in cui le segnalazioni
piovono a una velocità impressionante, rispettare le scadenze rischia di
diventare molto più difficile.
I PRIMI SCRICCHIOLII
La cronaca recente conferma tutti i timori legati al massiccio impiego dell’AI
nell’individuazione delle vulnerabilità. La società di cybersecurity HackerOne
ha sospeso il suo programma Internet Bug Bounty (IBB), attività finanziata in
crowdfunding che gestisce dal 2013. Il motivo? L’eccessivo numero di
segnalazioni stava mettendo in difficoltà chi ha il compito di correggere il
codice del software. E questo soprattutto in ambito open source, dove la
gestione dei progetti è spesso affidata a programmatori che prestano la loro
opera a titolo volontario.
La pagina web di HackerOne è un perfetto riassunto dei problemi che vive il
settore. Nelle sue policy, spiega che ricompenserà solo quelle vulnerabilità che
“siano state segnalate in modo responsabile, riconosciute, analizzate (triage),
risolte e divulgate tramite un Security Advisory o una CVE (Common
Vulnerabilities and Exposures, un sistema di catalogazione pubblico e
standardizzato delle vulnerabilità di sicurezza informatica note – ndR). Se una
vulnerabilità viene segnalata da più persone ed è riconosciuta all’interno del
security advisory, solo il primo segnalatore (come identificato dai maintainer
del progetto) avrà diritto alla ricompensa”.
In questo passaggio si leggono tutte le criticità legate a un ecosistema che è
ormai andato fuori controllo. Traducendo dal “politically correct” adottato
nelle policy, HackerOne ammette di trovarsi in una situazione in cui vengono
segnalate vulnerabilità che non sono state sufficientemente approfondite, che in
molti casi vengono scovate da più soggetti e per le quali non viene fornita una
soluzione. Insomma: si trova ad avere a che fare con troppo “pattume” generato
dall’AI. Motivazioni simili hanno indotto la piattaforma Bugcrowd a introdurre
una serie di regole e restrizioni per contrastare il fenomeno che hanno
battezzato come “sloptimism” (segnalazioni basate su AI inviate con troppa
fiducia e poca verifica).
L’AI TROVA VERE VULNERABILITÀ?
Guardando più nel dettaglio il fenomeno, emerge anche un altro dato. A gennaio
2026 i volontari che gestiscono cURL – software open source che gestisce lo
scambio di dati con Internet e che, pur sconosciuto al grande pubblico, è
installato in miliardi di dispositivi (telefoni, automobili, TV) – hanno
annunciato che dal mese successivo avrebbero smesso di accettare segnalazioni
tramite HackerOne. In un aggiornamento pubblicato ad aprile, il creatore Daniel
Stenberg ha diffuso un grafico da cui emerge una tendenza abbastanza chiara:
nonostante da febbraio non sia stata accettata alcuna segnalazione, il totale
del 2026 era già arrivato a 87.
Al di là della crescita esponenziale di segnalazioni, spicca il fatto che nel
2025 sono stati registrati numerosi report classificati come “likely AI slop”
(probabile pattume AI), cioè vulnerabilità di bassissimo impatto o inventate
dall’intelligenza artificiale. Il loro numero, però, è diminuito percentualmente
nel corso dell’anno successivo.
Prima di considerare questi dati come confortanti, è però opportuno considerare
un altro aspetto: non tutte le vulnerabilità validate rappresentano un reale
rischio di sicurezza. Come spiega Naz Bozdemir in un post sul blog di HackerOne,
delle 22 vulnerabilità individuate da Claude Opus 4.6 nel codice di Mozilla
Firefox – 14 delle quali ad alta gravità – soltanto due si sono rivelate
effettivamente sfruttabili per costruire un exploit. In altre parole: erano
tutte difetti reali, ma solo due rappresentavano un rischio imminente e
concreto.
L’idea che una maggiore efficienza porti automaticamente a più sicurezza, alla
fine, si sta rivelando un’illusione. L’uso intensivo dell’AI sta dimostrando
esattamente il contrario: senza la capacità di selezionare, comprendere e
intervenire, rischia di generare semplicemente caos.
L'articolo La fine del bug bounty? proviene da Guerre di Rete.
