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.