Forse non a tutti è chiaro quanto rapida sta evolvendo la cybersecurity, nel bene e nel male (soprattutto nel male) nell’ultimo mese a causa dell’intelligenza artificiale.
Non parliamo solo di Anthropic Mythos che, con Openai 5.5 Cyber, sta trovando moltissime vulnerabilità (da ultimo in Firefox). Più banalmente, l’AI sta rendendo molto più facile attacchi con exploit che un’azienda normale non è in grado ora di bloccare.
Indice degli argomenti
Com’è accelerato il rischio cyber con l’AI LLM
Caso esemplare questa settimana: Google ha bloccato quello che sembra il primo zero day sfruttato con un LLM (large language model, AI generativa), non nominato ma non certo Mythos, quindi un modello disponibile a tutti probabilmente. Registriamo anche che le banche USA con Mythos hanno cominciato una corsa contro il tempo per fixare i propri sistemi, mentre oggi la BCE ha lanciato l’allarme alle banche UE (che a Mythos ancora non hanno ottenuto accesso).
Il problema: “quante aziende anno la stessa forza di proteggersi di Google? Certo le aziende che non usano le AI nemmeno si sarebbero accorte dell’attacco”, dice Alessio Pennasilico del Clusit, tra i più noti esperti cyber in Italia. “Quanti governi, quante infrastrutture critiche nel mondo sarebbero riusciti a parare l’attacco?”, aggiunge.
Mythos e Gpt 5.5 Cyber sono a uso limitato, nelle mani rispettivamente di decine e centinaia (a breve migliaia) di soggetti (aziende, istituzioni; l’UE accede ora solo al secondo). Ma “il caso Google dimostra che non serve avere questi modelli per fare attacchi difficilissimi da parare”, aggiunge Claudio Telmon, del Clusit. “Quindi avremo prossimamente un aumento importante di 0-day, e gli stessi strumenti possono essere utilizzati anche per scrivere il codice che li sfrutta, automatizzando e velocizzando tutto il processo. Finché non si stabilizza il fenomeno, il rischio aumenterà molto”, continua.
E come si stabilizza? Gli esperti sono d’accordo. Serve che l’AI per la difesa si diffonda di più nelle aziende, quelle che sviluppano e soprattutto quelle che adottano software (ossia tutte le aziende al mondo o quasi). Certo, premettiamo: non vuol dire solo dotarsi di soluzioni tecniche di difesa con l’AI ma anche fare importanti cambi organizzativi per ottimizzare igiene cyber, policy di patching, formazione anti phishing eccetera.
Al tempo stesso è corretto analizzare l’attuale panorama di soluzioni AI cyber e prendere confidenza con nomi quali Project Glasswing di Anthropic, Big Sleep, CodeMender (entrambi Google) e OpenAI Daybreak (lanciato ieri).
Quattro modi diversi di usare modelli avanzati per spostare la sicurezza più a monte, dentro il ciclo di vita del software.
Prima del confronto, è utile sintetizzare il posizionamento dei quattro approcci.
| Soluzione | Funzione prevalente | Modello di accesso | Evidenza pubblica principale | Rischio/limite principale |
| Project Glasswing | Ricerca e triage di vulnerabilità su software critico | Molto ristretto, partner selezionati | Dichiarazioni Anthropic su Mythos Preview, partner e scala del programma | Bassa verificabilità esterna, forte dipendenza dal vendor |
| Big Sleep | Scoperta di vulnerabilità reali e variant analysis | Ricerca interna/controllata | Casi pubblici su SQLite e disclosure Google | Difficile misurare replicabilità e generalizzazione |
| CodeMender | Patching e validazione automatizzata | Ricerca avanzata, non piattaforma generalista pubblica | 72 fix upstreamed, workflow con validazione automatica | Automazione utile ma ancora da governare con review umana |
| Daybreak | Integrazione nei workflow di difesa enterprise | Accesso graduato e verificato | Use case dichiarati e framework Trusted Access | Dipendenza da policy di accesso, integrazione e controlli organizzativi |
LLM e cybersecurity: dalla discovery alla remediation. Project Glasswing-Mythos di Anthropic, Big Sleep, CodeMender (entrambi Google) e OpenAI Daybreak
Vediamo in dettaglio
Mythos-Project Glasswing
Project Glasswing è l’iniziativa con cui Anthropic sta mettendo a disposizione di partner selezionati Claude Mythos Preview, un modello che l’azienda descrive come capace di trovare vulnerabilità ad alta gravità su larga scala. La logica è chiaramente quella dell’accesso ristretto: partner industriali e finanziari, oltre a più di 40 organizzazioni aggiuntive legate a software e infrastrutture critiche, con una forte enfasi sul fatto che capacità di questo livello possano essere utili alla difesa ma anche rischiose se diffuse senza controllo. Anthropic collega il programma a crediti d’uso fino a 100 milioni di dollari e a donazioni per la sicurezza open source.
Qui c’è un elemento che rafforza il punto sulla governance: Anthropic dice di avere esteso l’accesso anche a oltre 40 organizzazioni che costruiscono o mantengono infrastrutture software critiche e promette un report pubblico entro 90 giorni sui risultati divulgabili. C’è quindi un programma con obiettivi di disclosure e apprendimento condiviso, pur restando dentro un perimetro molto chiuso.
Alcuni esperti cyber ritengono che questo approccio, security by obscurity, è vecchio ed è il contrario di quello che serve, ossia mettere nelle mani di quante più aziende possibile gli strumenti più potenti ora disponibili per la cyber.
Big Sleep Google e CodeMender
Big Sleep, sviluppato da Google Project Zero e Google DeepMind, presidia soprattutto la parte di vulnerability discovery. L’evoluzione dal progetto Naptime a Big Sleep è stata raccontata da Google come il passaggio da un framework di valutazione delle capacità offensive dei modelli a un agente impiegato su codice reale. Google ha attribuito a Big Sleep la scoperta di una vulnerabilità reale in SQLite già nel 2024 e, nel 2025, ha parlato di più vulnerabilità trovate in contesti reali, inclusa una falla in SQLite che sarebbe stata vicina allo sfruttamento.
Il caso SQLite Google lo presenta come il primo esempio pubblico di un agente AI capace di trovare una vulnerabilità di memory safety sconosciuta e sfruttabile in software reale ampiamente usato, corretta lo stesso giorno prima di una release ufficiale. Allo stesso tempo, Project Zero invita a non mitizzare il risultato: parla di evidenze ancora sperimentali e osserva che, allo stato attuale, un attacco mirato tradizionale può in certi casi restare almeno altrettanto efficace.
CodeMender, sempre in casa Google DeepMind, si colloca invece più avanti nella catena: non tanto trovare la falla, quanto produrre patch, validarle e ridurre il rischio di regressioni. DeepMind lo presenta come un agente basato su Gemini Deep Think, dotato di strumenti di analisi e verifica automatica, capace di generare fix ad alta qualità da sottoporre a revisione umana. Nelle comunicazioni ufficiali Google parla di 72 security fix upstreamed in sei mesi su progetti open source, anche molto grandi.
DeepMind non descrive CodeMender come un semplice generatore di patch. Nella documentazione ufficiale parla di analisi statica e dinamica, differential testing, fuzzing e solver SMT usati per verificare che il fix corregga la causa radice, non introduca regressioni e resti coerente con il codice esistente. È anche così che Google collega i 72 fix upstreamed a una catena di validazione più credibile, su progetti arrivati fino a 4,5 milioni di linee.
OpenAI Daybreak
Daybreak, infine, è la proposta con cui OpenAI prova a trasformare queste capacità in una piattaforma di impiego operativo per team di difesa. La pagina ufficiale la presenta come una combinazione di modelli OpenAI, Codex come harness agentico e controlli graduati di accesso. Le funzioni dichiarate coprono secure code review, threat modeling, patch validation, dependency risk analysis, detection e remediation guidance.
OpenAI distingue anche livelli di accesso diversi, dal general purpose fino a modelli e workflow con Trusted Access for Cyber per uso difensivo verificato.
Nelle pagine pubblicate a maggio 2026, OpenAI ha anche reso più esplicita la stratificazione del servizio: GPT-5.5 per uso general purpose, GPT-5.5 con Trusted Access for Cyber per workflow difensivi verificati e GPT-5.5-Cyber per attività autorizzate più specialistiche, con controlli più forti a livello di account. È un chiarimento utile perché mostra che la governance non è un accessorio, ma una parte della proposta di prodotto.
LLM e cybersecurity: quale anello della catena presidiano
Utile sintetizzare il posizionamento dei quattro approcci.
La tabella sopra mostra il punto centrale: Glasswing e Big Sleep stanno soprattutto sul lato discovery, CodeMender sul lato remediation, Daybreak sull’orchestrazione e l’integrazione nei workflow difensivi. Questo cambia anche il criterio con cui valutarli. Un CISO, un responsabile applicativo o un buyer pubblico non dovrebbe chiedersi solo se il modello “trova più bug”, ma se la soluzione riduce davvero il tempo tra scoperta, fix, verifica e messa in produzione, lasciando tracce auditabili e mantenendo il controllo umano dove serve.
LLM e cybersecurity: perché la governance conta più del modello
La prima differenza forte riguarda l’accesso. Anthropic, con Glasswing, parte dall’assunto che capacità molto elevate di vulnerability discovery possano avere un impatto difensivo enorme ma anche un valore offensivo tale da giustificare una distribuzione ristretta. OpenAI, con Trusted Access for Cyber e Daybreak, adotta una logica più graduata: l’accesso cresce in funzione dell’autorizzazione, del contesto d’uso e dei controlli associati. Google, nel caso di Big Sleep e CodeMender, comunica soprattutto risultati e direzione strategica, meno una disponibilità aperta come servizio general purpose.
La seconda differenza riguarda le prove pubbliche. Big Sleep dispone di alcuni esempi concreti legati a vulnerabilità reali e a disclosure pubbliche; CodeMender offre numeri e descrizioni di workflow di validazione; Daybreak, almeno per ora, espone soprattutto casi d’uso, schema di accesso e integrazione nella difesa; Glasswing, invece, presenta affermazioni molto forti sulle capacità di Mythos Preview, ma con una verificabilità esterna inevitabilmente più bassa, perché il modello non è disponibile in modo aperto e il perimetro resta chiuso. Questo non invalida il programma, ma rende ancora più importante distinguere tra claim del vendor, prova pubblica e impatto operativo misurabile.
La terza differenza riguarda l’human review. Sia Google sia OpenAI insistono sul fatto che il ciclo non sia “modello decide, macchina esegue”, ma un processo con test, monitoraggio, revisione e validazione. È un punto decisivo: nella sicurezza del software, il problema non è solo trovare una soluzione plausibile, ma produrre una modifica corretta, non regressiva, documentabile e compatibile con il contesto applicativo. Qui si gioca gran parte della distanza tra un copilota impressionante e un vero strumento enterprise.
LLM e cybersecurity tra benchmark e casi reali
Un pezzo del quadro arriva dai benchmark.
CyberSecEval 2, pubblicato da Meta, è una suite di valutazione ampia per modelli LLM in compiti di cybersecurity e rappresenta uno dei riferimenti più citati per misurare capacità offensive e difensive in modo comparabile.
Google Project Zero, con il progetto Naptime, ha usato proprio quel benchmark come base di partenza per mostrare che un impianto agentico con strumenti e verifiche iterative può spingere i modelli oltre il semplice prompting statico. In altre parole, il salto prestazionale non dipende solo dal modello, ma anche dal modo in cui lo si incardina in un workflow di tool use, verifica e iterazione.
Anche i numeri aiutano a ridimensionare gli entusiasmi facili. CyberSecEval 2 segnala che il prompt injection resta un problema aperto: nei test pubblicati da Meta tutti i modelli valutati hanno mostrato tassi di successo tra il 25% e il 50%. Naptime, però, suggerisce che l’architettura conta quasi quanto il modello: nel benchmark buffer overflow Google mostra che GPT-4 Turbo passa da 0,20 in Reproduced@20 a 1,00 in Naptime@20, mentre Gemini 1.5 Pro sale da 0,02 a 0,99. Il punto non è il decimale in sé, ma il fatto che tool use e verifica iterativa cambiano radicalmente il risultato.
Ma il benchmark, da solo, non basta. Il passaggio che sta ridefinendo il mercato è quello verso casi reali, repository reali, disclosure reali, patch reali. Big Sleep è importante proprio per questo: Google lo presenta come un agente capace di trovare vulnerabilità su codice reale, non solo su benchmark.
CodeMender è rilevante perché sposta l’attenzione dall’individuazione del problema alla generazione di fix verificati. Daybreak interessa perché prova a innestare queste capacità nelle routine quotidiane di sicurezza e sviluppo. Glasswing, infine, segnala che i vendor ritengono ormai plausibile l’esistenza di modelli con capacità cyber abbastanza avanzate da richiedere programmi di accesso ristretti e partnership mirate.
LLM e cybersecurity: il segnale pubblico che arriva da DARPA
Se si cerca un esempio esterno ai vendor, oggi il riferimento più forte è AIxCC di DARPA. Nella finale 2025, i sistemi in gara hanno analizzato oltre 54 milioni di linee di codice, trovato 54 vulnerabilità sintetiche su 63, corretto 43 di queste, individuato anche 18 vulnerabilità reali non sintetiche e prodotto 11 patch per bug reali, con un tempo medio di sottomissione delle patch di 45 minuti. Non è ancora il mondo enterprise quotidiano, ma è la prova pubblica più robusta che la filiera find-prove-patch sta diventando misurabile.
Conta anche un altro aspetto: DARPA ha reso disponibili come open source quattro dei sette cyber reasoning system finalisti. Questo riduce, almeno in parte, la dipendenza dai soli claim dei vendor e apre uno spazio di verifica più vicino a ciò che imprese, PA e comunità open source chiederanno ai prodotti commerciali nei prossimi mesi.
LLM e cybersecurity per imprese e PA
Per imprese e amministrazioni, il primo cambiamento è che la sicurezza applicativa tende a spostarsi più a sinistra, dentro progettazione, sviluppo, code review e supply chain software. Qui il riferimento utile è il paradigma secure by design promosso da CISA e dai partner internazionali: la responsabilità di ridurre il rischio non può restare in capo all’utente finale o al team che interviene solo dopo l’incidente, ma deve essere assorbita il più possibile da chi sviluppa e gestisce il software. Gli LLM cyber diventano interessanti se aiutano davvero questo spostamento.
Un segnale pubblico ulteriore viene dal fatto che CISA continua a leggere il tema dentro il paradigma secure by design: il valore degli LLM cyber non sta nel sostituire il team umano, ma nel portare prima nel ciclo di sviluppo discovery, verifica e remediation. È una distinzione decisiva per la PA, dove procurement, audit e responsabilità amministrativa contano quasi quanto la performance tecnica dello strumento.
Per questo, il tema non è comprare “un assistente AI per la security”, ma capire dove si inserisce. In una grande impresa può avere senso partire da code review, threat modeling e patch validation; in ambienti regolati o nella PA può contare ancora di più la tracciabilità del processo, la segregazione degli accessi, la possibilità di audit e la coerenza con policy di procurement e gestione del rischio.
Una piattaforma come Daybreak parla a questo bisogno di integrazione controllata; Big Sleep e CodeMender mostrano invece quanto valore possa generarsi quando discovery e remediation vengono collegati; Glasswing porta al centro un’altra questione, cioè la gestione di capacità che potrebbero essere utili ai difensori ma anche sensibili dal punto di vista dell’abuso.
LLM e cybersecurity: i criteri per valutarli davvero
Per chi deve decidere, ci sono almeno cinque domande più utili del semplice confronto tra brand.
- Quanto del workflow copre davvero?
Una soluzione che individua il bug ma non aiuta a validare il fix lascia ancora molto lavoro umano. Una soluzione che genera patch ma non si integra nei repository, nei test e negli strumenti di controllo resta confinata a demo ad alto impatto visivo. - Che livello di verifica esterna esiste?
Casi pubblici, CVE, fix upstreamed, disclosure tracciabili e metriche di qualità contano più di claim generici sulle capacità del modello. Big Sleep e CodeMender, da questo punto di vista, offrono oggi segnali più leggibili del solo annuncio di un modello molto potente ma poco osservabile dall’esterno. - Qual è il modello di governance?
Accesso ristretto, trusted access, monitoraggio, revisione umana e controlli account-level non sono dettagli. Sono parte del prodotto, soprattutto quando si parla di capacità cyber avanzate. - L’automazione riduce davvero il rischio o lo sposta?
Una patch sbagliata, un falso positivo rumoroso o una remediation non contestualizzata possono creare nuovo debito. Per questo i vendor che oggi appaiono più convincenti insistono su validazione, test, monitoraggio e review. - Quanto è coerente con il secure by design?
È il criterio più importante. Se la soluzione aiuta a progettare software meno esposto, accelera il fix e riduce la dipendenza dall’intervento post-incidente, allora ha un valore strutturale. Se invece resta un assistente utile ma separato dal ciclo di vita del software, il guadagno è più limitato.
LLM e cybersecurity: dalla promessa al sistema di difesa
Il confronto tra Glasswing, Big Sleep, CodeMender e Daybreak ci dice questo: la cybersecurity basata su LLM non si sta muovendo verso un unico prodotto dominante, ma verso una filiera in cui modelli, agenti, controlli di accesso e workflow di verifica tendono a comporsi.
La posta in gioco non è solo migliorare la produttività degli analisti o degli sviluppatori, ma ridefinire il modo in cui si scoprono, si correggono e si prevengono vulnerabilità nel software critico.
L’automazione dei processi di attacco e difesa rende praticamente impossibile mantenere online dispositivi e sistemi con software non aggiornato, mettendo al centro non solo le tecnologie ma i processi di manutenzione di tutti i dispositivi connessi, processi che possono in parte essere automatizzati ma che comunque richiedono una supervisione e un coordinamento da parte della governance delle organizzazioni.
Ha collaborato Antonio Cisternino, università di Pisa
