Claude Mythos e la cybersecurity che corre troppo veloce

Quando si è iniziato a parlare di Claude Mythos, il caso ha fatto subito rumore. La narrativa pubblica è andata subito nella direzione dell’AI “cattiva” chiusa in laboratorio perché troppo potente per essere rilasciata.

Tuttavvia Mythos è interessante perché sembra indicare un salto di capacità nei modelli frontier, soprattutto nell’intersezione tra coding, ragionamento multi-step e cybersecurity.

Non parliamo solo di un modello che scrive codice meglio. Parliamo di un sistema capace di leggere basi di codice complesse, formulare ipotesi su una vulnerabilità, testarle in sequenza e arrivare, in alcuni casi, a un exploit funzionante.

La stessa capacità che permette a un team di sicurezza di trovare e correggere una falla può aiutare un attaccante a capirla, riprodurla e sfruttarla.

Con Mythos è ormai fin troppo chiaro che l’AI sta iniziando ad accelerare alcune attività tecniche che fino a ieri richiedevano tempo, competenze specialistiche e molti tentativi.

E quando si accelerano analisi del codice, bug hunting, exploit development e patch diffing, cambiano anche le priorità operative per chi deve difendere sistemi reali.

Cos’è Claude Mythos

Facciamo un passo indietro, per chi non ha ancora seguito tutta la storia.

Claude Mythos è il modello avanzato di Anthropic finito al centro dell’attenzione perché, secondo quanto riportato da diverse ricostruzioni, durante alcuni test interni avrebbe mostrato capacità cyber molto superiori rispetto ai modelli precedenti.

Durante un test in ambiente isolato, Mythos avrebbe trovato un modo per uscire parzialmente dalla sandbox e inviare un’email al ricercatore che stava supervisionando l’esperimento. Il ricercatore, secondo il racconto ripreso dalla stampa, si sarebbe accorto del successo ricevendo quella mail mentre era in un parco a mangiare un panino.

Mythos sembra indicare un salto di qualità in una combinazione molto delicata: coding, ragionamento multi-step e cybersecurity.

Non è un prodotto consumer. Non è un modello pubblico. Non è semplicemente “un Claude più potente”.

Per questo Anthropic ha deciso di renderlo disponibile solo in accesso limitato nell’ambito di Project Glasswing, un’iniziativa pensata per mettere capacità AI avanzate a disposizione di organizzazioni selezionate, ricercatori e grandi player tecnologici con finalità difensive.

Secondo le informazioni disponibili, Mythos è un modello general purpose con prestazioni particolarmente elevate nel ragionamento, nello sviluppo software e nell’analisi tecnica applicata alla sicurezza.

Un modello molto forte nel coding può leggere codice reale, può analizzare dipendenze, interpretare patch, confrontare versioni, individuare anomalie e generare ipotesi tecniche.

Un modello molto forte nel ragionamento può gestire attività composte da più passaggi. Non si limita a rispondere a una domanda. Mantiene contesto, interpreta output, corregge la traiettoria e prova strade alternative.

Un modello efficace in ambito cyber può usare queste capacità per individuare vulnerabilità, validarle, ricostruire catene di sfruttamento e proporre mitigazioni.

Per la difesa, tutto questo è estremamente utile.

Può supportare attività come:

• analisi di codice complesso;
• vulnerability research;
• bug hunting;
• patch analysis;
• triage di vulnerabilità;
• secure development;
• supporto ai red team;
• validazione delle mitigazioni.

Ma la stessa lista, letta dall’altro lato, spiega anche perché Anthropic abbia scelto un rilascio controllato.

Perché Mythos è stato confinato

Mythos sembra avvicinare tra loro tre fasi che, normalmente, richiedono competenze diverse: individuare una vulnerabilità, capirne l’impatto e trasformarla in qualcosa di sfruttabile.

Nei test citati nelle valutazioni pubbliche, Mythos avrebbe mostrato capacità molto superiori ai modelli precedenti in scenari cyber avanzati. L’AI Security Institute del Regno Unito avrebbe osservato, tra le altre cose, un successo del 73% in task CTF di livello esperto e la riuscita completa di una simulazione d’attacco aziendale a 32 step in 3 tentativi su 10.

Questo dato indica che il modello non si limita a produrre risposte isolate. Riesce a mantenere contesto, ragionare su passaggi successivi, scegliere strumenti, interpretare output e correggere la traiettoria.

Ed è esattamente ciò che rende un modello agentico interessante, ma anche sensibile.

Perché molte attività sono difficili perché richiedono sequenza, adattamento e contesto.

E quando una macchina inizia a gestirle meglio è inevitabile chiedersi:

chi può usarlo, con quali limiti e con quali controlli?

Dagli exploit ai patch diff

Uno degli aspetti più rilevanti del caso Mythos riguarda il rapporto tra patch ed exploit.

Quando un vendor pubblica una patch, non pubblica solo una correzione. Pubblica anche un indizio.

Chi fa reverse engineering può confrontare il codice prima e dopo, capire quale difetto è stato corretto e provare a ricostruire la vulnerabilità. Una pratica che esiste da anni ma con un modello come Mythos le parti del processo si accelerano: leggere diff complessi, individuare pattern sospetti, proporre ipotesi, generare proof of concept, adattare il codice quando il primo tentativo non funziona.

Il rischio è una riduzione del tempo tra patch pubblicata ed exploit disponibile.

Per un team di sicurezza, questa è la parte davvero operativa. Perché il patching non avviene mai nel vuoto: ci sono sistemi legacy, finestre di manutenzione, test applicativi, dipendenze da fornitori, ambienti industriali, servizi che non possono essere fermati senza impatto.

Se il tempo dell’attaccante si riduce e il tempo interno resta lo stesso, il rischio cresce.

Mythos e il confronto con i modelli precedenti

Mythos non viene descritto solo come “più bravo”, ma come qualitativamente diverso rispetto a modelli precedenti.

Il confronto con Claude Opus è utile proprio per questo.

Nei test sul motore JavaScript di Firefox, Opus sarebbe riuscito a generare exploit funzionanti solo in pochi casi, mentre Mythos avrebbe prodotto molti più exploit validi, arrivando in alcuni scenari a ottenere controllo di sistema.

Anche qui serve cautela: sono test specifici, in ambienti controllati e con condizioni definite.

Ma se un modello migliora non solo nel trovare una vulnerabilità, ma nel trasformarla in un exploit affidabile, allora non stiamo parlando soltanto di automazione del bug hunting.

Stiamo parlando di un’accelerazione dell’intero ciclo vulnerabilità-exploit-mitigazione.

E questa accelerazione ha un impatto diretto su vulnerability management, patch management e hardening.

Perché il settore finanziario osserva Mythos con attenzione

Il caso Mythos è diventato rilevante anche per il settore finanziario perché tocca un punto già caldo: la velocità con cui le organizzazioni riescono a valutare, testare e applicare le patch.

Secondo quanto riportato dalla stampa finanziaria, la BCE ha richiamato le banche europee sulla necessità di prepararsi a un contesto in cui modelli AI avanzati potrebbero rendere più rapida l’individuazione e lo sfruttamento delle vulnerabilità.

E se l’analisi tecnica accelera, anche i processi di difesa devono diventare più rapidi e più tracciabili.

Questo riporta l’attenzione su attività che sembrano di base, ma che in molte organizzazioni restano difficili da governare bene: asset inventory, patching, hardening, segmentazione, logging, threat intelligence e capacità di risposta.

Cosa cambia per chi difende sistemi reali

Il vero problema del caso Mythos è che rende più urgenti problemi già noti.

Il primo è la visibilità.

Se un’organizzazione non sa con precisione quali asset sono esposti su Internet, quali versioni sono in uso, quali servizi appartengono a fornitori e quali sistemi supportano processi critici, ogni nuova vulnerabilità diventa una corsa al buio.

Il secondo è la prioritizzazione.

Una CVE non pesa allo stesso modo ovunque. Conta se il sistema è esposto. Conta se esiste exploit pubblico o exploitability probabile. Conta se il servizio è critico. Conta se ci sono controlli compensativi. Conta se la patch può essere applicata senza interrompere l’operatività.

Il terzo è il processo decisionale.

Quando una patch critica impatta un sistema delicato, non basta sapere che “va applicata”. Serve sapere chi decide, in quanto tempo, con quali evidenze e con quale piano alternativo se il patching immediato non è possibile.

Il quarto è l’hardening.

MFA, segmentazione, riduzione dei servizi esposti, controllo degli account privilegiati, logging completo, dismissione degli asset dimenticati: sono controlli noti, ma diventano più importanti quando il tempo per reagire diminuisce.

Il quinto è il threat modeling.

Non basta chiedersi quali vulnerabilità esistono ma quali potrebbero diventare rapidamente sfruttabili se un attaccante avesse strumenti migliori per analizzarle.

“Avremo accesso a Mythos?”

Per la maggior parte delle aziende, la risposta per adesso è no.

Tuttavia se ci chiedessimo

quanto tempo ci serve oggi per capire quanto una nuova vulnerabilità ci riguarda davvero?

Se servono giorni solo per capire quali asset sono coinvolti, il problema non è Mythos.
È l’inventario.

Se la priorità dipende solo dal CVSS, il problema non è Mythos.
È la mancanza di contesto.

Se ogni patch critica apre una discussione improvvisata tra IT, security, business e fornitori, il problema non è Mythos.
È il processo.

Se una mitigazione temporanea non viene documentata, il problema non è Mythos.
È l’auditability.

Con Mythos la cybersecurity ha cominciato a corre più veloce, e non possiamo difenderci con processi lenti, opachi e frammentati.

Rafforzare i processi

Serve dunque rafforzare i processi che permettono di ridurre il tempo tra segnale tecnico e decisione operativa.

In pratica:

• mantenere aggiornata la mappa degli asset esposti;
• collegare vulnerabilità, esposizione e criticità del servizio;
• distinguere tra patch urgente, patch ordinaria e mitigazione temporanea;
• definire ownership chiare su sistemi critici e fornitori;
• documentare le eccezioni quando una patch non può essere applicata subito;
• testare il processo con scenari brevi basati su vulnerabilità reali;
• integrare threat intelligence e vulnerability management in un unico flusso decisionale.

Non solo conoscerli ma farli funzionare quando arriva una vulnerabilità critica, il business chiede continuità e il fornitore risponde che l’aggiornamento “va pianificato”.

In Digimetrica lavoriamo proprio su questo: trasformare segnali tecnici in priorità operative.

Con CyberSonar osserviamo la superficie esposta dall’esterno, individuando asset, servizi, configurazioni e segnali di rischio visibili da Internet. Con i servizi di Cyber Check Up e Security Operations aiutiamo le aziende a leggere queste informazioni dentro un quadro più ampio: impatto, priorità, readiness, evidenze e capacità di risposta.

In uno scenario accelerato dall’AI, la domanda importante è sapere quali vulnerabilità possono diventare un problema prima di riuscire a reagire?

E soprattutto se esiste un processo per deciderlo.

La vera rivoluzione di Mythos sta nel mostrare una soglia.

Un modello AI può diventare abbastanza efficace da aiutare seriamente la difesa, ma anche abbastanza sensibile da non poter essere distribuito senza controllo.

Se l’AI rende più veloce l’analisi del codice, delle vulnerabilità e delle patch, allora i team di sicurezza devono diventare più rapidi nel vedere, valutare, decidere e documentare.

Il vero rischio non è Mythos.

È arrivare dopo.