Progetto Glasswing: cosa ci ha mostrato Mythos

Negli ultimi mesi, abbiamo testato una gamma di LLM incentrati sulla sicurezza sulla nostra infrastruttura. Questi LLM aiutano a identificare potenziali vulnerabilità nei nostri sistemi in modo da poterle risolvere e ci mostrano anche cosa potrebbero fare gli aggressori con i modelli più recenti.

Nessuno di questi LLM ha attirato più attenzione di Mythos Preview di Anthropic. Alcune settimane fa, siamo stati invitati a utilizzare Mythos Preview come parte di Progetto Glasswing. Lo abbiamo subito puntato su oltre cinquanta dei nostri repository, per vedere cosa avrebbe trovato e come funzionava.

Questo post condivide le nostre osservazioni, i punti di forza e di debolezza dei modelli, e come l'architettura e i processi ad essi correlati debbano cambiare affinché possano essere utilizzati su larga scala.

Mythos Preview rappresenta un vero passo avanti, ed è bene dirlo chiaramente prima di addentrarci in altro. Da tempo eseguiamo test con i nostri modelli e il salto da ciò che era possibile con i precedenti modelli di frontiera generici a ciò che Mythos Preview fa oggi non è solo un perfezionamento di ciò che c'era prima.

Si tratta di uno strumento diverso, che svolge un lavoro diverso, e questo rende difficile un confronto diretto con i modelli precedenti. Piuttosto che cercare di confrontare Mythos Preview con modelli di frontiera generici, è più utile descrivere cosa può effettivamente fare e due caratteristiche che si sono distinte durante il lavoro che abbiamo svolto con Mythos Preview:

• Costruzione di una catena di exploit: un attacco reale raramente utilizza un solo bug ma concatena diverse piccole primitive di attacco in un exploit funzionante. Ad esempio, potrebbe trasformare un bug di tipo use-after-free in una primitiva di lettura e scrittura arbitraria, dirottare il flusso di controllo e utilizzare catene di programmazione orientata al ritorno (ROP) per assumere il pieno controllo di un sistema. Mythos Preview può prendere diverse di queste primitive e ragionare su come combinarle in una dimostrazione funzionante. Il ragionamento che emerge durante il processo sembra più opera di un ricercatore senior che il risultato di uno scanner automatico.

• Generazione di prove: trovare un bug e dimostrare che è sfruttabile sono due cose diverse, e Mythos Preview può fare entrambe. Scrive del codice che attiverebbe il presunto bug, lo compila in un ambiente di test e lo esegue. Se il programma si comporta come previsto dal modello, questa è la prova. Se ciò non accade, il modello rileva l'errore, modifica la sua ipotesi e riprova. Il ciclo di test è importante tanto quanto i bug che individua, perché un presunto difetto senza una prova concreta rimane una mera speculazione, e Mythos Preview colma questa lacuna in modo autonomo.

Alcuni degli aspetti descritti sopra non sono esclusivi di Mythos Preview. Quando abbiamo testato altri modelli di frontiera con lo stesso sistema, abbiamo riscontrato un buon numero degli stessi bug di fondo e, in alcuni casi, siamo andati oltre le nostre aspettative anche sul fronte del ragionamento. Il loro errore è stato nella fase di assemblaggio dei vari pezzi. Un modello identificherebbe un bug interessante, scriverebbe una descrizione ponderata del perché sia importante e poi si fermerebbe, lasciando la catena di operazioni incompleta e la questione della sua sfruttabilità aperta. La novità introdotta con Mythos Preview è che ora un modello può individuare quei bug di bassa gravità (che tradizionalmente rimarrebbero invisibili in un backlog) e concatenarli in un unico exploit più grave. 

Il modello Mythos Preview fornito da Anthropic, nell'ambito del Progetto Glasswing, non disponeva delle misure di sicurezza aggiuntive presenti nei modelli generalmente disponibili (come Opus 4.7 o GPT-5.5).

Nonostante ciò, il modello respinge organicamente alcune richieste: proprio come le capacità informatiche che lo hanno reso utile per la ricerca di vulnerabilità, il modello ha i suoi meccanismi di protezione emergenti che a volte lo portano a respingere richieste legittime di ricerca sulla sicurezza. Come abbiamo scoperto, però, questi rifiuti spontanei non sono costanti: lo stesso compito, formulato in modo diverso o presentato in un contesto differente, potrebbe produrre risultati completamente diversi, come illustrato negli esempi seguenti.

^{Esempio di Mythos Preview che si oppone alla creazione di una prova di concetto funzionante} 

Ad esempio, il modello inizialmente si è rifiutato di effettuare una ricerca di vulnerabilità su un progetto, per poi accettare di eseguire la stessa ricerca sullo stesso codice dopo una modifica non correlata all'ambiente del progetto. Nulla del codice analizzato era cambiato. In un altro caso, il modello ha individuato e confermato diversi gravi bug di memoria in una base di codice, e si è poi rifiutato di scrivere un exploit dimostrativo. La stessa richiesta, formulata in modo diverso, ha ottenuto una risposta diversa, e persino la stessa richiesta può produrre risultati diversi in esecuzioni diverse a causa della natura probabilistica del modello. Compiti semanticamente equivalenti possono produrre risultati opposti a seconda di come e quando vengono presentati al modello.

Questo è importante perché, sebbene i rifiuti/le barriere di sicurezza organiche del modello siano reali, non sono sufficientemente costanti da costituire da sole un confine di sicurezza completo. Ecco perché qualsiasi modello di frontiera cibernetica efficace reso disponibile al pubblico in futuro dovrà includere ulteriori misure di sicurezza, oltre a questo comportamento di base, in modo da renderlo adatto a un utilizzo più ampio al di fuori di un contesto di ricerca controllato come il Progetto Glasswing.

Una delle parti più difficili della valutazione delle vulnerabilità di sicurezza è decidere quali bug sono reali, quali sono sfruttabili e quali devono essere corretti immediatamente. Questo era un problema difficile anche nel mondo pre-intelligenza artificiale. Gli scanner di vulnerabilità basati sull'IA e il codice generato dall'IA hanno peggiorato la situazione, e noi di Cloudflare abbiamo sviluppato diverse fasi di post-validazione per far fronte a questo problema.

Due fattori dominano il tasso di rumore:

• Linguaggio di programmazione: C e C++ offrono il controllo diretto della memoria e, con esso, classi di bug - buffer overflow, letture e scritture fuori dai limiti - che i linguaggi sicuri per la memoria come Rust eliminano in fase di compilazione. Abbiamo riscontrato un numero costantemente maggiore di falsi positivi nei progetti scritti in linguaggi non sicuri per la memoria.

• Pregiudizio del modello: un buon ricercatore umano ti dice cosa ha scoperto e quanto è sicuro dei suoi risultati. I modelli no. Chiedi a un modello di trovare i bug e li troverà, a prescindere dal fatto che il codice ne contenga o meno. I risultati vengono presentati con espressioni come "forse", "potenzialmente", "in teoria" e sono di gran lunga più numerosi di quelli certi. Si tratta di un pregiudizio ragionevole per uno strumento esplorativo. È un sistema disastroso per la gestione delle richieste di diagnosi, dove ogni risultato ipotetico richiede attenzione umana e gettoni per essere scartato, e questo costo si moltiplica su migliaia di risultati.

Mythos Preview rappresenta un netto miglioramento in questo senso, in particolare nella sua capacità di concatenare le primitive, combinando più vulnerabilità in una prova di concetto funzionante anziché segnalarle singolarmente. Un risultato che arriva con una prova di concetto (PoC) è un risultato su cui si può agire, e significa molto meno tempo speso a chiedersi "è davvero reale?".

I nostri sistemi di monitoraggio sono volutamente tarati per sovrastimare le segnalazioni, in modo da poter rilevare più eventi (e trascurarne di meno), il che comporta però un rumore di fondo molto maggiore. Ma in fase di triage, l'output di Mythos Preview presenta una qualità nettamente superiore: meno risultati ambigui, passaggi di riproduzione più chiari e meno lavoro per giungere a una decisione di correzione o rigetto.

Quando abbiamo iniziato la ricerca sulle vulnerabilità assistita dall'IA lo scorso anno, il nostro primo istinto è stato quello più ovvio: puntare un agente di programmazione generico verso un repository arbitrario e chiedergli di scoprire le vulnerabilità. Questo approccio funziona, nel senso che il modello produrrà dei risultati, ma non è efficace nel fornire una copertura significativa di una codebase reale e nell'identificare risultati di valore. Ci sono due ragioni principali per questo:

• Contesto: gli agenti di codifica sono ottimizzati per un flusso di lavoro specifico: creare una funzionalità, correggere un bug, scrivere un refactoring. Analizzano una grande quantità di codice sorgente, si concentrano su una singola ipotesi alla volta e la verificano iterativamente. Questa non è affatto la forma adatta per la ricerca sulla vulnerabilità, che per sua natura è ristretta e parallela. Un ricercatore umano sceglie un elemento specifico da esaminare e lo analizza a fondo. Potrebbe trattarsi di una singola funzionalità complessa, di transizioni attraverso i confini di sicurezza o di una specifica classe di vulnerabilità come le iniezioni di comandi, in cui l'input dell'attaccante viene eseguito come comando di shell. Poi lo ripetono, per una diversa funzionalità, un diverso confine di sicurezza o una diversa classe di vulnerabilità, diverse migliaia di volte nell'intero codice sorgente. Una singola sessione di un agente (anche con subagenti) su un repository di centomila righe può coprire forse un decimo dell'uno per cento della superficie in modo utile prima che la finestra di contesto del modello si riempia e si attivi la compattazione, scartando potenzialmente risultati precedenti che sarebbero stati importanti.

• Throughput: un agente a flusso singolo fa una cosa alla volta, ma le codebase reali hanno bisogno di molte ipotesi su molti componenti contemporaneamente, con la capacità di espandersi ulteriormente quando emerge qualcosa di interessante. È possibile spingere un singolo agente a dare il massimo, ma a un certo punto si smette di essere limitati dal modello e si inizia ad essere limitati dalla forma stessa dell'interazione. L'utilizzo diretto del modello in un agente di codifica si rivela efficace per le indagini manuali quando un ricercatore ha già una pista e desidera un secondo parere. Tuttavia, non è lo strumento adatto per ottenere un'elevata copertura. Una volta accettato questo fatto, abbiamo smesso di cercare di far fare a Mythos Preview la funzione sbagliata e abbiamo iniziato invece a costruire l'infrastruttura attorno ad essa.

Dall'esecuzione del progetto su larga scala sono emersi quattro insegnamenti, ognuno dei quali ha evidenziato la necessità di un sistema di gestione che coordini l'intera esecuzione:

• Un ambito ristretto produce risultati migliori: dire al modello "Trova vulnerabilità in questo repository" gli fa perdere tempo e lo fa rimanere vago. Dirgli "Cerca l'iniezione di comandi in questa specifica funzione, con questo limite di fiducia sopra, ecco il documento di architettura ed ecco la documentazione precedente su quest'area" lo fa comportarsi in modo molto più simile a quello che farebbe un ricercatore.

• La revisione avversaria riduce il rumore: l'aggiunta di un secondo agente tra il risultato iniziale e la coda - uno con un prompt diverso, un modello diverso e senza la capacità di generare i propri risultati - cattura gran parte del rumore che il primo agente non rileverebbe se si limitasse a controllare il proprio lavoro. A quanto pare, mettere deliberatamente due agenti in disaccordo è molto più efficace che limitarsi a dire a uno solo di fare attenzione.

• Dividere la catena tra gli agenti produce un ragionamento migliore: chiedere "Questo codice è pieno di bug?" e "Un aggressore può effettivamente raggiungere questo bug dall'esterno del sistema?" sono due domande diverse e il modello è più efficace in ciascuna di esse quando vengono poste separatamente, perché ogni domanda è più specifica rispetto alla versione combinata.

• Compiti ristretti in parallelo superano un agente esaustivo: la copertura migliora quando molti agenti lavorano su domande con ambito ristretto e successivamente eliminiamo i duplicati dei risultati, invece di chiedere a un agente di essere esaustivo.

Ciascuna di queste osservazioni riguarda il comportamento del modello e, messe insieme, descrivono qualcosa che non è più un'interfaccia di chat. Si tratta di un'imbracatura che ti aiuta a raggiungere i risultati finali. I primi passi per costruire un'imbracatura sono semplici, dato che si può chiedere aiuto al modello, ed è proprio quello che abbiamo fatto. Abbiamo utilizzato Mythos Preview per sviluppare, personalizzare e migliorare i nostri sistemi di imbracatura originali in modo da sfruttarne i punti di forza. Di seguito viene descritto un esempio pratico di come si presenta un'imbracatura.

Ecco come appare il nostro strumento per la scoperta delle vulnerabilità, fase per fase. È stato utilizzato per analizzare il codice in tempo reale nel nostro ambiente di runtime, nel percorso dati periferico, nello stack di protocolli, nel piano di controllo e nei progetti open source da cui dipendiamo.

Fase	Cosa fa	Perché è importante
Ricognizione	Un agente legge il repository dall'alto verso il basso, si dirama verso i sub-agenti responsabili di ciascun sottosistema e produce un documento di architettura che include i comandi di compilazione, i limiti di fiducia, i punti di ingresso e la probabile superficie di attacco. Genera inoltre la coda iniziale di attività per la fase successiva.	Fornisce a ogni agente a valle un contesto condiviso. Riduce il problema del vagare.
Caccia	Ogni attività corrisponde a una classe di attacco associata a un suggerimento di ambito. I cacciatori (ovvero gli agenti che effettivamente cercano i bug) operano simultaneamente, in genere una cinquantina alla volta, ognuno dei quali si dirama verso un piccolo gruppo di agenti secondari incaricati dell'esplorazione. Ogni cacciatore ha accesso a strumenti che compilano ed eseguono codice proof-of-concept in una directory temporanea specifica per ogni attività.	Ecco dove avviene la maggior parte del lavoro. Molte attività specifiche svolte in parallelo, non un unico agente che si occupi di tutto.
Convalida	Un agente indipendente rilegge il codice e cerca di confutare il risultato originale. Utilizza un prompt diverso e non ha la capacità di emettere nuove scoperte autonomamente.	Cattura una frazione significativa del rumore che il sistema di rilevamento non riuscirebbe a individuare durante la revisione del proprio lavoro.
Riempimento delle lacune	I cacciatori segnalano le aree che hanno toccato ma che non hanno coperto a fondo. Quelle aree vengono ricodificate per un altro passaggio.	Contrasta la tendenza del modello a virare verso classi di attacco con cui ha già ottenuto successo.
Deduplicazione	I risultati che condividono la stessa causa principale vengono raggruppati in un unico record.	L'analisi delle varianti è una funzionalità, non un modo per riempire la coda con duplicati.
Tracciamento	Per ogni riscontro confermato in una libreria condivisa, un agente di tracciamento si distribuisce (un'istanza per repository di consumo), utilizza un indice di simboli tra repository e decide se l'input controllato dall'attaccante ha effettivamente raggiunto il bug dall'esterno del sistema.	Trasforma "c'è un difetto" in "c'è una vulnerabilità sfruttabile". Questa è la fase che conta di più.
Feedback	Le tracce raggiungibili diventano nuove attività di ricerca nei repository dei consumatori dove il bug è effettivamente esposto.	Chiude il ciclo. La pipeline migliora man mano che viene eseguita.
Report	Un agente redige un report strutturato secondo uno schema predefinito, corregge eventuali errori di validazione rispetto allo stesso schema e invia il report a un'API di acquisizione.	L'output è costituito da dati interrogabili, non da testo libero.

La reazione più forte da parte degli altri responsabili della sicurezza alla Mythos Preview riguarda la velocità: scansionare più velocemente, applicare le patch più velocemente, comprimere i tempi di risposta. Più di un team con cui abbiamo parlato ora opera con un SLA di due ore dal rilascio della CVE all'implementazione della patch in produzione. L'istinto è comprensibile: quando i tempi dell'aggressore si accorciano, anche quelli di chi si difende devono accorciarsi di conseguenza. Essere più veloci non basterà, e pensiamo che molte squadre stiano per spendere molto tempo, impegno e denaro per impararlo a proprie spese.

Applicare le patch più velocemente non modifica la struttura della pipeline che le produce. Se i test di regressione richiedono un giorno, non è possibile raggiungere un SLA di due ore senza saltarli, e i bug che si introducono quando si saltano i test di regressione tendono ad essere peggiori dei bug che si stava cercando di correggere. Abbiamo appreso una versione di questo fenomeno quando abbiamo provato a lasciare che il modello scrivesse le proprie patch e abbiamo visto alcune di esse, che risolvevano il bug originale ma che silenziosamente causavano problemi a qualcos'altro da cui dipendeva il codice, essere rilasciate.

La questione più complessa è quale dovrebbe essere l'architettura necessaria per gestire la vulnerabilità. Il principio è quello di rendere più difficile lo sfruttamento da parte di un aggressore anche in presenza di un bug, in modo che il lasso di tempo tra la divulgazione di una vulnerabilità e la sua correzione diventi meno rilevante. Ciò significa che si tratta di difese che si interpongono tra l'applicazione e il dispositivo di protezione, impedendo che il bug venga sfruttato. Significa progettare l'applicazione in modo tale che una falla in una parte del codice non possa consentire a un utente malintenzionato di accedere ad altre parti. Significa essere in grado di implementare una correzione contemporaneamente in tutti i punti in cui il codice è in esecuzione, anziché attendere che i singoli team la distribuiscano. 

Riconosciamo inoltre che questo argomento ha risvolti contrastanti. Le stesse capacità che ci hanno aiutato a trovare bug nel nostro codice, se finissero nelle mani sbagliate, accelererebbero gli attacchi contro ogni applicazione presente su Internet. Cloudflare si trova davanti a milioni di queste applicazioni e i principi architetturali descritti sopra sono esattamente quelli che i nostri prodotti sono progettati per applicare a beneficio dei clienti. Nelle prossime settimane condivideremo maggiori dettagli su cosa ciò significhi per i clienti.

Se il tuo team sta svolgendo un lavoro simile e desidera confrontarsi, contattaci all'indirizzo security-ai-research@cloudflare.com.

La nostra ricerca con Mythos Preview è stata condotta in un ambiente controllato sul nostro codice; ogni vulnerabilità emersa durante questo lavoro è stata analizzata, convalidata e corretta laddove necessario, secondo la procedura formale di gestione delle vulnerabilità di Cloudflare.

Questo lavoro è stato uno sforzo di squadra. Grazie ad Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl e Rohit Chenna Reddy per i loro contributi alla ricerca, ingegneria e analisi che stanno alla base di questo post sul blog.