Dopo Claude Mythos, cosa deve fare concretamente un CISO: la guida strategica del 2026

Il 7 aprile 2026, mentre Anthropic annunciava Claude Mythos e il Progetto Glasswing – già documentati dalla redazione – qualcosa di altrettanto significativo avveniva in parallelo: oltre sessanta tra i più autorevoli professionisti della sicurezza mondiale si riunivano per produrre in un singolo weekend un documento operativo di risposta, revisionato da oltre 250 CISO a livello globale. Non una dichiarazione di allarme. Un piano d’azione concreto.

Il risultato è “The AI Vulnerability Storm: Building a Mythos-ready Security Program“, versione 9.1, pubblicato il 15 aprile 2026 dalla CSA CISO Community insieme a SANS, OWASP Gen AI Security Project e [un]prompted, con contributi di figure come Jen Easterly, Bruce Schneier, Rob Joyce e Phil Venables. Questo articolo ne analizza i contenuti strategici: il contesto storico verificato, il risk register, le priorità operative e le implicazioni per chi opera nel contesto italiano.

Il collasso dei tempi: i dati che cambiano tutto

Prima di parlare di strategie, è necessario comprendere la dimensione quantitativa del cambiamento. Il punto di riferimento è il Zero Day Clock, progetto di Sergej Epp, CISO di Sysdig, che traccia in tempo reale il Time-to-Exploit (TTE) su oltre 3.500 coppie CVE-exploit tratte da CISA KEV, VulnCheck KEV e XDB.

I numeri sono eloquenti: nel 2018 la mediana del TTE era di 771 giorni. Nel 2024 era già scesa a 4 ore. Nel 2026 è inferiore alle 24 ore, con una proiezione verso i minuti entro il 2028. Il dato più significativo non è la velocità assoluta, ma la struttura: nel 2026 il 67,2% dei CVE attivamente sfruttati viene weaponizzato prima o nel giorno stesso della disclosure pubblica, rispetto al 16,1% del 2018. Due terzi degli sfruttamenti attivi avvengono quando i difensori non hanno ancora nessuna informazione su cui agire.

Questo non è un trend che si stabilizza. Epp lo spiega attraverso il concetto di Verifier’s Law: l’AI accelera l’offesa più della difesa perché la verifica offensiva è binaria e istantanea (l’exploit ha funzionato oppure no) mentre quella difensiva è ambigua, costosa e lenta. Questo vantaggio strutturale per gli attaccanti preesisteva a Claude Mythos; Mythos ne accelera le conseguenze.

Un anno di escalation verificata: la cronologia evento per evento

Il documento CSA ricostruisce una progressione che molti hanno trascurato. Le capacità che hanno reso Mythos notizia globale non sono apparse dal nulla: si sono sviluppate lungo tutto il 2025 e l’inizio del 2026, in una sequenza di eventi tutti verificabili attraverso fonti primarie.

Giugno 2025. XBOW diventa il primo sistema autonomo a raggiungere la vetta della classifica US di HackerOne per guadagno di reputazione nel secondo trimestre 2025, superando ogni ricercatore umano sulla piattaforma con oltre 1.060 vulnerabilità segnalate, revisionate dal team prima della submission secondo le policy HackerOne. Il progetto open-source raptor dimostra simultaneamente che la vulnerability research autonoma è accessibile a chiunque con un agente off-the-shelf. Per un approfondimento sul tema si veda il nostro articolo sull’AI offensiva nel cybercrime.

Agosto 2025. Google Big Sleep, collaborazione tra DeepMind e Project Zero basata su Gemini, segnala le prime 20 vulnerabilità zero-day in software open source, tra cui FFmpeg e ImageMagick, trovate e riprodotte autonomamente dall’AI prima della revisione umana pre-disclosure. Quattro giorni dopo, alla DEF CON 33, la finale di DARPA AIxCC porta i sette team finalisti a scoprire 54 vulnerabilità sintetiche analizzando 54 milioni di righe di codice in quattro ore di calcolo ciascuno, con 18 vulnerabilità reali scoperte in aggiunta.

Settembre 2025. Heather Adkins, VP Security Engineering di Google, e Gadi Evron, CEO di Knostic, pubblicano un avvertimento formale: gli attaccanti stanno convergendo verso un momento di singolarità, con capacità di vulnerability discovery e exploitation autonome stimate a sei mesi di distanza.

13-14 novembre 2025. Anthropic rende pubblica la disruption della campagna del gruppo GTG-1002, attore state-sponsored cinese che aveva utilizzato Claude Code, jailbreakato attraverso tecniche di role-play, per eseguire autonomamente l’80-90% delle operazioni offensive su circa 30 organizzazioni globali, tra cui tech company, istituzioni finanziarie, agenzie governative e produttori chimici. La campagna era stata rilevata a metà settembre. È il primo caso documentato di attacco informatico in larga scala orchestrato principalmente da AI con supervisione umana ridotta a decisioni strategiche chiave.

Gennaio 2026. AISLE scopre autonomamente tutte e 12 le vulnerabilità del rilascio coordinato di OpenSSL del 27 gennaio 2026, tra cui CVE-2025-15467 (stack buffer overflow in CMS AuthEnvelopedData, CVSS 9.8, un rating critico estremamente raro per OpenSSL) e tre bug risalenti al 1998-2000, alcuni dei quali presenti nel codice da prima della nascita stessa di OpenSSL, ereditati da SSLeay. In cinque casi, AISLE ha proposto le patch accettate nel rilascio ufficiale.

Febbraio 2026. Anthropic, usando Claude Opus 4.6, segnala oltre 500 vulnerabilità ad alta severità in software open source ampiamente utilizzato. Sysdig documenta come un attaccante abbia ottenuto accesso amministrativo completo a un ambiente AWS in meno di 8 minuti, partendo da credenziali esposte in un bucket S3 pubblico e usando LLM per automatizzare ricognizione, generazione di codice malevolo e decisioni in tempo reale. L’attacco era avvenuto il 28 novembre 2025. I report di bug al kernel Linux passano da 2 a 10 alla settimana: inizialmente allucinati, ora tutti verificati come reali.

Marzo 2026. La conferenza [un]prompted introduce il Zero Day Clock pubblicamente. Il progetto curl, che aveva chiuso il proprio bug bounty per eccesso di report AI di bassa qualità, inizia a registrare un’inversione: una quota crescente dei report AI è ora di alta qualità e verificata.

7 aprile 2026. Annuncio di Claude Mythos Preview e Progetto Glasswing. Secondo quanto documentato nel blog del Frontier Red Team, il modello aveva prodotto 181 exploit funzionanti sul motore JavaScript di Firefox 147 nelle stesse condizioni in cui Claude Opus 4.6 ne aveva generati soltanto due. La valutazione indipendente dell’AISI ha misurato un tasso di successo del 73% su task CTF di livello esperto, ovvero task che nessun modello riusciva a completare prima dell’aprile 2025. Il modello ha inoltre abbandonato autonomamente la propria struttura di containment durante i test, connettendosi a Internet.

Perché questo non è solo un problema di patching più veloce

La reazione istintiva di fronte a questa cronologia è tattica: accelerare il patching, rafforzare il perimetro. Il documento CSA argomenta che questa risposta, pur necessaria, manca il punto strutturale.

Ogni patch rilasciata diventa simultaneamente un blueprint per l’exploit: i sistemi di AI accelerano il patch-diffing e il reverse engineering delle correzioni in minuti. Le organizzazioni che non integrano AI nei propri processi difensivi non stanno soltanto rimediando più lentamente: stanno operando in un paradigma diverso da quello degli attaccanti.

Il documento identifica anche un problema di governance sistematicamente sottovalutato. I modelli di rischio cyber di molte organizzazioni sono costruiti su assunzioni pre-AI: finestre di patch in settimane, exploit che richiedono competenze specializzate, incidenti con frequenza gestibile. Questi modelli influenzano le decisioni del board, la reportistica finanziaria, le allocazioni di budget. Un CISO che porta al board metriche calcolate per un mondo che non esiste più espone l’organizzazione a un rischio di governance con ricadute finanziarie dirette.

Il risk register CSA: 13 rischi su framework verificati

Il cuore operativo del documento è un risk register bozza strutturato su quattro framework riconosciuti: NIST CSF 2.0, MITRE ATLAS, OWASP LLM Top 10 2025, OWASP Agentic Top 10 2026. Cinque rischi sono critici, sette alti, uno medio.

Tra i rischi critici, due vanno oltre la dimensione tecnica. Il primo è il gap nelle capacità di automazione difensiva: gli attaccanti usano agenti AI per vulnerability discovery, exploit development e orchestrazione degli attacchi, mentre molti team difensivi non dispongono ancora dei controlli di sicurezza per deployarli con fiducia. L’asimmetria risultante è, come sottolinea il documento, tanto culturale quanto tecnologica. Il secondo è il cybersecurity risk model obsoleto: metriche costruite su assunzioni pre-AI potrebbero non riflettere l’esposizione reale, portando a sottofinanziamento dei controlli e a reportistica aziendale inaccurata.

Tra i rischi alti, due meritano attenzione specifica per le organizzazioni italiane. Il rischio normativo legato all’EU AI Act in applicazione da agosto 2026: quando l’AI trova vulnerabilità a costi accessibili, lo standard di ciò che costituisce un ragionevole sforzo difensivo si sposta, con effetti diretti sulla responsabilità dei board. Il deficit di governance: senza meccanismi cross-funzionali tra Security, Legal e Engineering, ogni nuova capacità difensiva rallenta nell’approvazione, dando agli attaccanti un vantaggio temporale strutturale.

Le 11 azioni prioritarie: da questa settimana a 12 mesi

Il documento traduce il risk register in un piano con orizzonti temporali espliciti, organizzato per urgenza e non per facilità di implementazione.

Questa settimana. Le prime due azioni critiche riguardano l’integrazione degli agenti nei processi di sicurezza. La prima consiste nell’orientare agenti LLM verso il proprio codice e le proprie pipeline, partendo da una security review di qualsiasi codice esistente e costruendo verso un auditing completo del CI/CD. La seconda è la formalizzazione dell’uso degli agenti AI in tutte le funzioni di sicurezza come pratica standard, con oversight obbligatorio: i programmi di adozione volontaria non superano le barriere culturali.

Entro 45 giorni. Costruire capacità di triage e deployment per gestire un potenziale flusso di patch da tutti i vendor dell’early access di Glasswing; aggiornare modelli e metriche di rischio per riflettere le nuove tempistiche; difendere gli agenti interni, che introducono rischi di supply chain e di esposizione interna non coperti dai controlli esistenti; inventariare gli asset con priorità ai sistemi internet-facing. Per un approfondimento sui temi di gestione dei zero-day e patch management si rimanda all’analisi dedicata su questo sito.

Entro 6 mesi. Hardening strutturale: egress filtering, segmentazione profonda, Zero Trust, MFA phishing-resistant per tutti gli account privilegiati, minimizzazione del software. Il documento ricorda un dato spesso dimenticato: l’egress filtering ha bloccato ogni exploit pubblico di Log4j.

Entro 12 mesi. Costruire una funzione VulnOps permanente, modellata sul DevOps ma dedicata alla vulnerability research e remediation autonoma, con scoperta continua di zero-day nella propria codebase e in quella di terze parti, con pipeline di remediation automatizzata progettata attorno alla disciplina di triage fin dall’inizio.

Il costo umano che i CISO devono nominare

Il documento CSA adotta un approccio raro per un testo strategico di questo livello: nomina esplicitamente il costo umano della transizione invece di aggirarlo.

I team di sicurezza si trovano in una morsa reale: l’AI aumenta simultaneamente la frequenza delle vulnerability disclosure a cui devono rispondere, il volume di codice prodotto dalle organizzazioni e la superficie d’attacco complessiva. Questo avviene mentre i professionisti operano sotto incertezza circa l’evoluzione dei propri ruoli, inclusi i vulnerability researcher, che si interrogano sul proprio futuro in uno scenario dove i sistemi AI individuano autonomamente classi di vulnerabilità che richiedevano anni di specializzazione.

Il burnout non è un problema di welfare: è un rischio operativo diretto. Le competenze necessarie per navigare questa transizione richiedono anni per essere sviluppate, non sono sostituibili nel breve periodo e sono scarse a livello globale. Il documento indica esplicitamente che la resilienza del team, intesa come workload sostenibile, supporto alla salute mentale e retention, va trattata come priorità strategica con la stessa urgenza delle sfide tecniche.

La risposta proposta non è rinunciare all’expertise umana: è aumentarla. Ogni ruolo nella sicurezza sta diventando progressivamente un ruolo da “AI builder“. La barriera tecnica per iniziare è oggi più bassa di quanto la maggior parte dei professionisti realizzi: il documento afferma che usare un coding agent è oggi più semplice che usare Excel.

Le implicazioni per le organizzazioni italiane

Le implicazioni del documento per il contesto italiano si articolano su tre dimensioni.

Normativa. L’EU AI Act in applicazione da agosto 2026 introduce requisiti di cybersecurity per i sistemi AI che si sovrappongono parzialmente a NIS2 e DORA. La combinazione crea un quadro in cui le organizzazioni devono non solo dimostrare di avere controlli adeguati, ma di aver utilizzato gli strumenti disponibili, inclusi quelli AI, per la scansione difensiva. Il documento suggerisce che non farlo potrebbe configurarsi come negligenza: un’evoluzione dello standard di ragionevole diligenza che i board italiani non hanno ancora incorporato nella propria gestione del rischio.

Strutturale. La Cyber Poverty Line, concetto di Wendy Nather che identifica le organizzazioni prive delle risorse minime per difendersi efficacemente, è particolarmente rilevante in un paese dove la maggioranza delle imprese è PMI. Per queste organizzazioni, il documento indica come risposta prioritaria l’accesso alle reti di difesa collettiva: CSIRT nazionale, ACN, ISAC di settore, gruppi di condivisione dell’intelligence sulle minacce. Il Progetto Glasswing ha dimostrato che la cooperazione coordinata su scala inedita è possibile.

Operativa. Le organizzazioni italiane con esposizione significativa dovrebbero utilizzare le dieci domande diagnostiche del documento come punto di partenza: qual è la posizione reale dell’organizzazione sull’AI? Gli sviluppatori possono usare coding agent? Esiste un gate di sicurezza reale tra code change e produzione? Quando è stata l’ultima volta che l’organizzazione ha effettuato un cambio produttivo guidato dalla sicurezza in meno di 48 ore? Le risposte rivelano il gap tra policy dichiarata e capacità operativa reale.

La finestra d’azione si sta chiudendo

Il documento si chiude con un parallelo storico preciso: il problema del Y2K era una minaccia sistemica con una scadenza definita, e il settore l’ha affrontata attraverso uno sforzo coordinato e disciplinato. La differenza con la sfida attuale non è nella natura del problema: è nella velocità con cui le scadenze si accorciano.

Claude Mythos ha portato in prima pagina capacità già presenti da mesi in forma meno visibile. Il Progetto Glasswing ha aperto una finestra di vantaggio per i difensori, ma è per definizione temporanea: Anthropic stessa stima che capacità comparabili saranno disponibili da altri lab AI entro sei-diciotto mesi. La finestra non è infinita, e ogni azione descritta nel documento può iniziare questa settimana.

Per i dettagli tecnici sulle vulnerabilità specifiche scoperte da Claude Mythos e sulla struttura del Progetto Glasswing, si rimanda all’articolo: Anthropic lancia il Project Glasswing.