Analisi multilivello delle vulnerabilità: quando gli LLM servono davvero e quando no

La campagna con cui OpenAI ha cercato falle nel kernel Linux è costata 1.213.430 dollari in crediti API.

Il rapporto pubblicato il 4 novembre 2026 conta 2.308 segnalazioni candidate, 1.724 vulnerabilità riprodotte in macchina virtuale e 948 distinte di escalation locale dei privilegi (LPE), ciascuna con un exploit funzionante e una patch candidata.

Il 64% della spesa, 775.929 dollari, è servito a costruire gli exploit. Scegliere quali parti del kernel esaminare è costato 3.426 dollari.

La distanza fra queste due cifre spiega perché si parla di analisi multilivello delle vulnerabilità: una catena di controlli in cui ogni passaggio costa più del precedente e riceve meno casi.

La ricerca delle vulnerabilità con l’AI e i colli di bottiglia

OpenAI stessa scrive che cercare vulnerabilità su larga scala è sempre più facile e che i colli di bottiglia sono la convalida e l’assegnazione delle priorità. Chi progetta la catena decide che cosa affidare a regole e classificatori, che cosa a un modello linguistico e quando arrivare alla prova in sandbox.

Il rapporto di OpenAI, le formule pubblicate da AWS, uno studio dell’Università di Torino e i dati di FIRST permettono di mettere qualche numero accanto a ogni livello.

Il costo della difesa è il filo conduttore della conversazione tra Nilay Patel e Alex Stamos, chief security officer di Cognition ed ex responsabile della sicurezza di Facebook, nel podcast Decoder del 7 novembre.

Per Stamos il costo per token degli attaccanti tende a zero mentre quello dei difensori resta alto; riferisce di un collega di una grande piattaforma di sicurezza per cui una singola indagine con un modello cyber di frontiera costa 900 dollari.

La scala di strumenti che propone riguarda i SOC: davanti a terabyte di log il primo livello non può essere un LLM, serve qualcosa di più semplice come TF-IDF o un classificatore tradizionale, che fa scattare l’allarme e passa il caso a un modello piccolo e poi, se serve, a modelli più grandi.

Sul codice osserva che anche chi dispone dei modelli cyber di frontiera li usa solo sulle parti più importanti.

Dentro la campagna di OpenAI, fase per fase

Il kernel Linux supera i 40 milioni di righe di codice. Un primo gruppo di agenti, gli esploratori, ha passato in rassegna cartelle e file e ha selezionato 5.034 aree da sottoporre ad audit, scelte perché raggiungibili da un utente con privilegi limitati e rilevanti per la sicurezza: circa 2,8 milioni di righe, il 7% del totale.

Su quelle aree un secondo gruppo, gli agenti analisti, ha prodotto in 12 ore 2.308 segnalazioni al netto dei duplicati.

La convalida ha riguardato le segnalazioni raggiungibili da un utente con privilegi limitati, che non richiedevano capability speciali e che producevano prove misurabili di corruzione della memoria.

Per ognuna un agente di triage ha scritto un proof of concept e lo ha eseguito in una macchina virtuale isolata, su un kernel con KASAN, il rilevatore dinamico degli errori di memoria come gli accessi fuori dai limiti e gli use-after-free, ritoccandolo finché il difetto non si manifestava o le strade erano esaurite.

In 30 ore ne sono state riprodotte 1.724, il 74,7%.

Le altre, scrive OpenAI, per lo più richiedevano privilegi elevati o non si sono lasciate riprodurre nel tempo disponibile, per esempio per race condition difficili da innescare; solo nel 3,1% dei casi l’analisi del modello era sbagliata.

Il numero che OpenAI usa per contare le vulnerabilità

Un agente di selezione preliminare ha poi esaminato staticamente report, log dei crash e codice sorgente.

Lavorava con criteri volutamente permissivi, per non perdere segnalazioni potenzialmente gravi, ed escludeva solo i casi senza un percorso di sfruttamento plausibile: ne sono rimasti 313 come possibili fughe di informazioni e 1.238 come possibili escalation dei privilegi.

Gli agenti di sviluppo degli exploit hanno lavorato su macchine virtuali con un sistema desktop in configurazione standard e le protezioni attive. Hanno considerato riuscito solo l’attacco che apriva una shell di root.

Ne sono usciti 291 proof of concept di fuga di informazioni e 1.169 exploit. L’analisi delle varianti ha portato a 948 patch distinte, ed è quel numero che OpenAI usa per contare le vulnerabilità.

Per ogni caso la pipeline consegna un’analisi della causa radice, un proof of concept minimo che provoca il crash, una proposta di patch e l’exploit completo.

Prima di scrivere ai manutentori, i ricercatori dell’azienda hanno rivisto exploit, patch e gravità proposta.

In una prova precedente quel controllo aveva scoperto che 20 exploit su 200 dichiarati riusciti arrivavano a root sfruttando una zero-day diversa da quella assegnata; da allora una verifica indipendente accerta che l’exploit usi il bug previsto.

Restano numeri dichiarati dall’azienda.

Dove sono finiti 1,21 milioni di dollari

La voce più pesante è la fase di Exploitation, cioè il lavoro degli agenti che sviluppano gli exploit dentro quella che OpenAI chiama valutazione della sfruttabilità: 775.929 dollari, di cui 691.000 per i casi di possibile escalation dei privilegi e 84.929 per quelli di fuga di informazioni.

La ricerca delle segnalazioni è costata 316.549 dollari, la convalida 73.330, la selezione preliminare 44.194.

La somma delle cinque voci è 1.213.428 dollari, due in meno del totale dichiarato; la generazione delle patch non compare con una cifra propria.

Dove si concentra il costo API della campagna Linux

Dividendo ogni costo per i casi trattati si ottiene il prezzo di un singolo passaggio.

Una segnalazione candidata è costata in media 137 dollari, il tentativo di riprodurla 32, la selezione preliminare 26.

Lavorare un caso di possibile escalation dei privilegi è costato in media 558 dollari, il doppio di un caso di fuga di informazioni, ma la media nasconde due dati: ogni exploit riuscito è costato circa 360 dollari, ogni tentativo fallito 3.922.

I fallimenti sono stati 69 su 1.238, dovuti secondo OpenAI a vulnerabilità difficili da sfruttare come le race condition, e hanno assorbito circa 270 mila dollari, più di un quinto dell’intera campagna.

La campagna in cifre: casi trattati e costo di ogni fase

OpenAI presenta questi costi come un limite superiore, perché la campagna serviva a misurare le capacità del modello e nessuno ha ottimizzato la spesa. Indica anche dove tagliare.

Una condizione di interruzione, per esempio fermare il tentativo dopo un’ora senza progressi, avrebbe ridotto in modo significativo il costo dello sviluppo degli exploit.

Inoltre, poiché convalidare un falso positivo costa quanto convalidare un vero positivo, eliminare i falsi positivi nelle prime fasi rende l’intera pipeline sensibilmente più efficiente.

Il confronto con la campagna di fine luglio, condotta con GPT-5.6 Sol, mostra quanto cambiano in fretta i prezzi: allora 166 falle per 513.690 dollari, circa 3.094 l’una; a ottobre 948 per 1.213.430, cioè 1.279 l’una.

In tre mesi il costo unitario è sceso del 59%.

Analisi multilivello delle vulnerabilità: i livelli e il loro prezzo

Messe in fila, le fonti disegnano una scala di controlli dal costo crescente. La tabella che segue è una sintesi di questo articolo e non descrive la pipeline di un fornitore.

Dal controllo gratuito all’exploit completo: sette livelli a confronto

Dove un modello non aggiunge nulla

Alcune fasi hanno un oracolo deterministico, un modo meccanico di stabilire se il finding è vero.

Un crash sotto sanitizer durante il fuzzing è una prova, e nessun modello la rende più vera.

Una dipendenza con una Common Vulnerabilities and Exposures (CVE) nota si trova confrontando versioni, un secret con pattern ed entropia, una misconfiguration con una policy eseguibile.

Scoping e asset inventory vivono di discovery di rete e di inventari. In questi casi un LLM aggiunge costo e una fonte di errore non ripetibile.

Ogni filtro perde qualcosa

Il pericolo principale di un sistema a cascata è il falso negativo iniziale. Questa procedura fa risparmiare perché scarta, e ogni scarto può contenere una vulnerabilità vera.

Se i filtri sbagliano in modo indipendente, la quota di falle reali che li supera tutti è il prodotto delle quote di ciascuno: tre passaggi che ne trattengono il 95% ne lasciano arrivare in fondo l’85,7%.

AWS ha misurato lo scambio su un’applicazione costruita apposta, con dieci vulnerabilità note: otto sfruttabili e due mitigate dall’infrastruttura.

Senza istruzioni di triage il modello le ha trovate tutte. Con il file di istruzioni che impone la verifica strutturale ne ha trovate nove: gli è sfuggita una credenziale scritta nel codice di test, definita ma mai richiamata.

In cambio sono sparite le segnalazioni inventate, che senza verifica erano circa il 30% del totale e citavano strutture di codice inesistenti nel repository.

La letteratura sulle cascate di modelli linguistici promette risparmi ampi. FrugalGPT, lavoro del 2023 di Chen, Zaharia e Zou, riporta fino al 98% di costi in meno a parità di prestazioni con GPT-4.

Sono compiti generali di elaborazione del testo. Per la ricerca di vulnerabilità nessuna delle fonti consultate offre un dato equivalente.

TF-IDF, il livello che non consuma token

TF-IDF (Term Frequency-Inverse Document Frequency) pesa ogni termine di un testo in base a quante volte vi compare e a quanto è raro nel resto della raccolta.

Nella formulazione di scikit-learn il peso è tf(t, d) × idf(t), con idf(t) = log[(1 + n) / (1 + df(t))] + 1, dove n è il numero dei documenti e df(t) quello dei documenti che contengono il termine.

Ne esce un vettore sparso che un classificatore lineare, per esempio una regressione logistica, elabora su una normale CPU, senza GPU e senza token.

La similarità del coseno fra due vettori dice quanto due segnalazioni si somigliano e serve a riconoscere i duplicati.

Tre ricercatori dell’Università di Torino, Rustam Talibzade, Idilio Drago e Francesco Bergadano, hanno confrontato questo approccio con gli embedding generati da LLM e con l’interrogazione diretta dei modelli, riproducendo ed estendendo un benchmark sulla classificazione dei metadati delle CVE.

Il lavoro, On Using LLMs for Vulnerability Classification, presentato a ottobre 2025 al workshop LAMPS della conferenza ACM CCS, assegna il primo posto a TF-IDF con il 74% di accuratezza; secondo arriva l’approccio generativo.

Gli autori lo spiegano con la natura dei testi: le descrizioni delle CVE sono molto schematiche e poche parole chiave ne determinano già le caratteristiche, cosa che i modelli generalisti con prompt generici non colgono.

Il 74% significa un errore ogni quattro classificazioni: troppo per chiudere un caso senza altri controlli.

Inoltre, il compito è classificare testi già scritti, e lo studio non dice nulla sulla capacità di trovare una falla nuova nel codice.

Stamos, del resto, pensa a TF-IDF per analizzare i log.

Per le CVE note: EPSS, KEV e qualche soglia

Quando la vulnerabilità ha già un identificativo CVE, è possibile sfruttare due segnali gratuiti che consentono un notevole risparmio nell’analisi. EPSS (Exploit Prediction Scoring System), curato da un gruppo di lavoro di FIRST con i dati di Empirical Security, stima ogni giorno la probabilità che per una CVE si osservi attività di sfruttamento nei 30 giorni successivi.

Il catalogo KEV di CISA elenca le vulnerabilità il cui sfruttamento è confermato.

I tassi di base aiutano a leggerli. Secondo FIRST il catalogo KEV copre circa lo 0,5% delle CVE pubblicate e in una finestra di 30 giorni si osserva attività di sfruttamento per il 2,5-3%.

Per questo quasi tutti i punteggi EPSS sono vicini a zero e una probabilità del 10% colloca già una CVE intorno al 95° percentile.

FIRST non indica una soglia valida per tutti, ricorda che il punteggio ignora l’impatto e il contesto dell’organizzazione e sconsiglia di moltiplicarlo per il CVSS.

Se una CVE è nel catalogo KEV, quel dato prevale su un EPSS basso.

Il file di AWS traduce questi segnali in incrementi di punteggio: +0,30 per una CVE presente nel KEV, +0,15 se associata a campagne ransomware, +0,20 con EPSS pari o superiore a 0,5, +0,10 da 0,1 in su, +0,05 da 0,01, +0,10 se esiste un proof of concept pubblico.

Il totale non può superare +0,50.

Patch automatiche o riviste: le fonti non concordano

Per Stamos le correzioni vanno generate, verificate con test scritti dalla macchina e integrate senza passaggio umano, perché a mano servirebbero anni; racconta di un’azienda in cui Cognition sta procedendo così su migliaia di bug.

Quando una scansione ne trova diecimila, aggiunge, riscrivere il codice partendo da specifiche e test costa meno che correggerlo.

AWS è più prudente: la sua pipeline produce un elenco ordinato per priorità, e i risultati vanno comunque rivisti da un umano prima di toccare il codice. OpenAI sta nel mezzo.

Considera la generazione automatica delle patch indispensabile per tenere il passo delle scoperte, ma dentro un processo iterativo guidato da esperti: le prime versioni neutralizzavano il proof of concept e a volte introducevano codice in eccesso, costi di prestazione, scostamenti dalle convenzioni del progetto, oppure lasciavano scoperte varianti della stessa falla.

C’è poi una questione di tempi.

Quando scansione e analisi manuale si sono concluse, dopo dieci giorni, 61 vulnerabilità LPE erano già state corrette upstream da altri, 43 avevano una patch in staging e 299 erano oggetto di segnalazioni e discussioni pubbliche.

OpenAI ne ricava un’indicazione per chi automatizza il triage: riconvalidare ogni segnalazione sul codice più recente prima di inviarla, per non caricare i manutentori di rapporti duplicati o superati.

Una correzione accolta a monte, inoltre, non è ancora sui sistemi in produzione: Sakshi Grover, research director di IDC, consiglia a CSO Online di verificare con i distributori i tempi dei backport e di cominciare da host multi-tenant, runner CI/CD e piattaforme container.

Nel frattempo, avverte OpenAI, un account con privilegi limitati su un sistema non aggiornato va considerato di fatto equivalente a root per un attaccante dotato di risorse.

Che cosa misurare prima di comprare

Il prezzo per token dice poco. I dati di OpenAI suggeriscono di chiedere a un fornitore, o di misurare in una prova interna sullo stesso campione di codice, almeno cinque grandezze.

Le prime due sono classiche: quante vulnerabilità note vengono ritrovate (recall) e quante segnalazioni reggono alla verifica (precision).

Poi il costo per vulnerabilità riprodotta e per patch accettata, il costo medio di un tentativo fallito con la regola che lo interrompe, il numero di falle gravi archiviate dal primo filtro, misurato a campione, e il tempo fra la segnalazione e la patch distribuita.

Chi lavora su codice proprietario deve sapere anche dove finiscono i sorgenti inviati al modello e chi autorizza i test.

Su Cybersecurity360 sono già usciti un’analisi sul costo dei token nell’agentic AI e un confronto fra le diverse famiglie di modelli per la cyber security. OpenAI dice di avere già inviato ai manutentori centinaia di segnalazioni e patch per le vulnerabilità critiche; le altre arriveranno a scaglioni, attraverso i partner del programma Patch the Planet.