La spinta alla sicurezza di Amazon e Google si scontra con la realtà dei bug dell’IA

I partner di sicurezza di Amazon e Google si sono uniti a una corsa alla difesa basata sull’IA, costruita attorno a un avvertimento netto; eppure solo l’1,3 percento delle vulnerabilità studiate è arrivato allo sfruttamento nel mondo reale.

Quel dato proviene dall’analisi di VulnCheck su 1.061 scoperte attribuite pubblicamente all’assistenza dell’IA. I ricercatori hanno confrontato tali risultati con prove di attacchi osservati al di fuori di ambienti controllati.

Il risultato mette in discussione un’assunzione centrale della campagna sulla sicurezza di Amazon e Google attorno a Project Glasswing di Anthropic. L’IA può individuare difetti rapidamente, ma una scoperta non genera automaticamente un attacco efficace.

Anthropic presenta comunque solide ragioni di urgenza. Il suo sistema Claude Mythos Preview ha identificato 23.019 potenziali vulnerabilità durante la scansione di progetti open source. L’azienda ha stimato che 6.202 meritassero valutazioni di gravità alta o critica.

Questi numeri enormi hanno alimentato previsioni su un’imminente ondata di exploit generati dall’IA. Tuttavia, la documentazione pubblica descrive al momento una transizione diversa.

L’IA sta moltiplicando le possibili segnalazioni di sicurezza più rapidamente di quanto gli esseri umani possano convalidarle, divulgarle, correggerle e definirne le priorità. Gli attaccanti devono ancora affrontare il lavoro più difficile: trasformare una debolezza tecnica in un’operazione affidabile.

Questa distinzione cambia il punto su cui i difensori dovrebbero concentrarsi. Il problema immediato non è semplicemente che l’IA trova più bug. È che i team di sicurezza devono distinguere le esposizioni rilevanti da volumi in crescita di evidenze generate dalle macchine.

I dati sullo sfruttamento cambiano la narrazione

La scoperta assistita dall’IA ha aumentato il volume delle vulnerabilità senza aumentare il tasso di sfruttamento osservato.

VulnCheck ha esaminato 1.061 vulnerabilità attribuite a Project Glasswing e alla Berkeley Vulnerability Research Initiative. Le ha poi confrontate con il proprio database Known Exploited Vulnerabilities.

L’azienda ha individuato 14 vulnerabilità con sfruttamento confermato nel mondo reale. Ciò equivale all’1,3 percento del gruppo esaminato, secondo l’analisi sullo sfruttamento pubblicata.

VulnCheck ha affermato che tale tasso era quasi identico a quello del suo più ampio set di dati sulle vulnerabilità. I difetti trovati dall’IA non sembravano quindi più inclini allo sfruttamento rispetto a quelli scoperti con metodi convenzionali.

Il confronto è importante perché la scoperta di vulnerabilità e lo sfruttamento misurano capacità diverse. Uno scanner identifica un comportamento del codice che potrebbe violare un confine di sicurezza previsto.

Un exploit funzionante deve attivare quel comportamento in condizioni pratiche. Spesso deve aggirare mitigazioni, raggiungere un sistema di valore e operare in modo affidabile tra le configurazioni dei bersagli.

Gli attaccanti reali valutano anche l’economia dell’operazione. Considerano accesso, tempo di sviluppo, rischio di esposizione, bersagli disponibili e il valore di eventuali dati o controllo che potrebbero ottenere.

Molti difetti non superano questo test. Alcuni richiedono accesso locale, configurazioni insolite o privilegi di cui un attaccante ha già bisogno. Altri provocano arresti anomali senza consentire un controllo utile.

Una vulnerabilità può restare tecnicamente valida offrendo al contempo scarso valore operativo. I punteggi di gravità da soli non possono spiegare se i criminali investiranno nella sua trasformazione in un’arma.

Project Glasswing rende questa distinzione particolarmente importante. Anthropic ha dichiarato che Mythos Preview ha prodotto 23.019 candidati in oltre 1.000 progetti open source.

Solo 126 risultati di Project Glasswing erano diventati record Common Vulnerabilities and Exposures pubblicati nei dati pubblici esaminati da VulnCheck. Solo uno aveva uno sfruttamento confermato in natura.

Questo confronto più ristretto non dimostra che i candidati rimanenti siano innocui. La divulgazione coordinata mantiene intenzionalmente riservati alcuni dettagli finché i manutentori del software non possono distribuire patch.

Mostra però che i totali dei candidati non possono sostituire gli esiti verificati delle vulnerabilità. Tanto meno possono misurare quanti risultati siano diventati strumenti offensivi affidabili.

Il ricercatore di VulnCheck Patrick Garrity ha descritto l’impatto attuale come reale ma modesto. Ha sostenuto che le vulnerabilità scoperte dall’IA non sono intrinsecamente più sfruttabili di quelle individuate con metodi tradizionali.

I risultati evidenziano anche un importante problema di denominatore. Il totale dei candidati di Project Glasswing include problemi di gravità media e bassa insieme ai risultati valutati più severamente.

I conteggi CVE pubblici rappresentano una fase successiva. Tali record richiedono generalmente convalida, coordinamento e sufficiente chiarezza tecnica per descrivere un prodotto interessato e la relativa debolezza.

Lo sfruttamento noto impone una soglia ancora più elevata. Richiede prove credibili che qualcuno abbia effettivamente usato la vulnerabilità contro un bersaglio reale.

Confrontare queste fasi senza precisazioni porta a conclusioni fuorvianti. Un ampio bacino di candidati può coesistere con un numero molto ridotto di casi di sfruttamento, perché ogni fase filtra evidenze diverse.

Il tasso dell’1,3 percento offre quindi un controllo di realtà, non un segnale di cessato allarme. Indica che l’IA ha trasformato l’offerta di risultati prima di trasformarne il valore operativo medio.

I partner di sicurezza di Amazon e Google hanno comunque ragioni per muoversi rapidamente

Il basso sfruttamento osservato non elimina il pericolo per i team di sicurezza di Amazon e Google e per gli altri partner di Project Glasswing.

Anthropic ha introdotto Project Glasswing per offrire a difensori selezionati accesso anticipato a Claude Mythos Preview. Tra i partecipanti iniziali figuravano Amazon Web Services, Google, Apple, Microsoft, Cisco, Nvidia e altri fornitori di infrastrutture.

Il progetto è iniziato con circa 50 partner. Anthropic ha poi dichiarato di stare ampliando l’accesso a circa 150 organizzazioni aggiuntive in oltre 15 Paesi.

I partecipanti usano Mythos Preview per esaminare codice interno e open source prima che capacità comparabili diventino ampiamente disponibili. Anthropic definisce questo un vantaggio difensivo asimmetrico.

La preoccupazione dell’azienda è semplice. I sistemi di IA possono esaminare un numero molto maggiore di percorsi di codice di quanti un team di ricerca umano possa ispezionare manualmente.

Un futuro attaccante potrebbe applicare la stessa scala senza seguire le regole della divulgazione coordinata. Potrebbe anche concentrare la scansione su software esposto a Internet con bersagli commerciali chiari.

L’attuale tasso di sfruttamento descrive prove pubbliche, non ogni attività privata. I gruppi criminali non annunciano in modo affidabile operazioni zero-day riuscite né pubblicano i loro metodi tecnici.

I conteggi di sfruttamento confermato sottostimeranno quindi parte dell’attività. L’incertezza aumenta quando i risultati restano riservati durante la correzione.

Eventi recenti mostrano che il lavoro offensivo assistito dall’IA non è più confinato ai benchmark. Google ha riferito di aver interrotto criminali che apparentemente usavano un modello di IA mentre identificavano una vulnerabilità software sconosciuta.

L’operazione non ha causato danni segnalati perché i difensori sono intervenuti. Tuttavia, il caso ha fornito prove che attori criminali stavano sperimentando l’IA in un flusso di lavoro reale sulle vulnerabilità.

Il divario tra esperimenti e sfruttamento scalabile resta significativo. Una singola operazione rilevata non dimostra che gli attaccanti possano automatizzare l’intero processo.

Tuttavia, i difensori non possono aspettare che le statistiche sullo sfruttamento aumentino prima di prepararsi. La conferma pubblica arriva di solito dopo un’intrusione, un’indagine forense o una divulgazione del fornitore.

Amazon affronta lo stesso problema da un’altra prospettiva operativa. Il suo sistema RuleForge converte informazioni sulle vulnerabilità e codice proof-of-concept in regole di rilevamento.

Amazon afferma che il sistema ha migliorato la produttività nella generazione di regole del 336 percento. Un valutatore separato ha ridotto i falsi positivi del 67 percento, preservando al contempo i rilevamenti dei veri positivi.

Queste affermazioni provengono dai risultati di RuleForge di Amazon, non da un benchmark indipendente. Ciononostante, l’architettura illustra come i difensori possano usare l’IA oltre la scoperta.

RuleForge divide il lavoro tra agenti specializzati nell’acquisizione, generazione, valutazione e convalida. I revisori umani mantengono la responsabilità di approvare le regole prima della distribuzione.

Questo flusso di lavoro affronta l’anello mancante tra una vulnerabilità divulgata e una difesa operativa. Trovare un bug non produce automaticamente telemetria, rilevamenti, patch o indicazioni per la distribuzione.

Google sta perseguendo una scoperta e una correzione più rapide attraverso CodeMender e Gemini 3.5 Flash Cyber. Il modello specializzato è progettato per trovare, convalidare e correggere vulnerabilità in grandi codebase.

Google afferma che il modello ha individuato 55 problemi unici confermati nella sua valutazione di V8. Gemini principale ne ha trovati 47, mentre Claude Opus 4.6 ne ha trovati 36 nella configurazione riportata.

I benchmark dei fornitori richiedono cautela perché configurazioni dei modelli e politiche di sicurezza differiscono. Google osserva inoltre che alcuni risultati dei concorrenti erano auto-riportati.

Anche così, la direzione è chiara. Le principali aziende tecnologiche stanno costruendo sistemi che collegano scansione, convalida e riparazione.

Il tasso di sfruttamento dell’1,3 percento non invalida questi investimenti. Ne sposta la giustificazione dal conteggio dei bug alla riduzione del tempo tra evidenze credibili e una difesa distribuita.

La scoperta è economica, ma lo sfruttamento resta una catena

Il cambiamento centrale è che l’IA ha indebolito il collo di bottiglia della scoperta senza eliminare quello dello sfruttamento.

Le codebase moderne contengono milioni di righe, dipendenze esterne, interfacce datate e assunzioni non documentate. Gli agenti di IA possono suddividere questo spazio di ricerca e testare molte ipotesi in parallelo.

Anthropic ha riferito che società di sicurezza indipendenti hanno valutato 1.752 candidati ad alta o critica gravità dalle sue scansioni open source. Di questi, 1.587 erano veri positivi validi.

Quel tasso di convalida del 90,6 percento suggerisce che il sistema abbia prodotto più che rumore casuale nel sottoinsieme esaminato. I revisori hanno confermato 1.094 casi come di gravità alta o critica.

Questi risultati supportano le affermazioni di Anthropic sulla scoperta. Non stabiliscono che ogni candidato rimanente e non esaminato supererà l’analisi degli esperti allo stesso tasso.

Non mostrano nemmeno che i difetti confermati siano ugualmente utili agli attaccanti. Lo sfruttamento dipende da una catena più lunga e meno prevedibile.

Innanzitutto, l’attaccante deve comprendere il componente vulnerabile e stabilire se i bersagli raggiungibili lo usino. Un difetto in una libreria ha scarso valore quando i percorsi di codice interessati restano disabilitati.

In secondo luogo, l’attaccante deve controllare l’input richiesto. Alcuni bug diventano raggiungibili tramite una richiesta pubblica, mentre altri richiedono autenticazione o esecuzione locale.

In terzo luogo, lo sfruttamento deve produrre un effetto di valore. Far arrestare un servizio differisce nettamente dall’eseguire codice, rubare credenziali o attraversare un confine di fiducia.

In quarto luogo, l’exploit deve tollerare le differenze tra versioni software e impostazioni di distribuzione. Una tecnica instabile può esporre un attaccante prima di fornire un accesso utile.

Infine, l’attaccante deve integrare l’exploit in un’operazione. Ciò richiede infrastruttura, selezione dei bersagli, persistenza, escalation dei privilegi e metodi per rimuovere le prove.

L’IA può assistere in ogni fase, ma l’assistenza non equivale all’autonomia. Un modello può generare codice plausibile che fallisce quando cambiano i dettagli dell’ambiente.

I modelli faticano anche a calibrare la fiducia. Amazon ha rilevato che il suo modello di generazione delle regole valutava favorevolmente quasi ogni candidato finché un giudice separato non ne esaminava l’output.

La stessa tendenza influisce sulla ricerca sulle vulnerabilità. Un modello può descrivere un percorso allarmante trascurando una condizione che rende quel percorso impossibile in produzione.

Anthropic ha cercato di affrontare questa debolezza attraverso una validazione indipendente. Il tasso di veri positivi riportato indica che strumenti progettati con cura e revisione da parte di esperti possono contenere un rumore considerevole.

Tuttavia, questa revisione crea un nuovo limite di capacità. Ogni segnalazione seria richiede riproduzione, analisi dell'impatto, comunicazione con i manutentori, una correzione e test di distribuzione.

Anthropic ha affermato che, in media, una segnalazione Mythos di gravità alta o critica richiede due settimane per essere corretta. Alcuni manutentori hanno chiesto all'azienda di rallentare le divulgazioni perché non disponevano di sufficiente capacità di revisione.

È qui che si sposta l'onere della sicurezza. La scoperta automatizzata aumenta la coda, ma sono ancora le istituzioni umane a determinare quanto rapidamente quella coda si trasformi in software più sicuro.

I progetti open source affrontano il divario più netto. Pacchetti ampiamente utilizzati dipendono spesso da piccoli team che non possono elaborare centinaia di segnalazioni private complesse.

I team aziendali hanno un controllo migliore sui propri repository. Anthropic ha affermato che gli utenti di Claude Security hanno corretto più di 2.100 vulnerabilità nelle prime tre settimane del prodotto.

Questa affermazione suggerisce che la titolarità e l'accesso alla distribuzione possano abbreviare la correzione. Non mostra quanto fossero gravi tali segnalazioni né quante delle patch proposte abbiano richiesto revisioni.

Il meccanismo favorisce quindi le organizzazioni con processi ingegneristici maturi. L'AI può accelerare il lavoro quando i team conoscono già le proprie risorse, i responsabili, le dipendenze e i percorsi di distribuzione.

Le organizzazioni con inventari deboli riceveranno più segnalazioni senza sapere quali sistemi siano importanti. Il risultato può essere un arretrato più ampio e azioni più lente contro minacce reali.

Il vero rischio è un deficit di triage e correzione

La scoperta di vulnerabilità tramite AI diventa pericolosa quando il volume delle segnalazioni cresce più rapidamente della capacità di validazione e correzione.

I programmi di sicurezza gestiscono già migliaia di risultati degli scanner, avvisi sulle dipendenze, avvertimenti di configurazione e segnalazioni da test di penetrazione. L'AI aggiunge un'altra fonte, con una scala maggiore e una calibrazione incerta.

Un team che tratta come urgente ogni segnalazione generata automaticamente esaurirà i propri revisori. Un team che liquida l'output dell'AI come rumoroso può trascurare un percorso raro ma ad alto impatto.

Questo crea un problema di precisione. I difensori devono identificare il piccolo insieme che combina gravità tecnica, risorse raggiungibili, interesse degli attaccanti e prove credibili di sfruttamento.

La tradizionale valutazione della gravità affronta solo una parte di questa decisione. Un difetto critico in un sistema di test isolato può rappresentare un pericolo meno immediato di un difetto con valutazione inferiore su un gateway esposto.

La threat intelligence aggiunge prove relative a scansioni attive, codice exploit pubblico, discussioni criminali e attacchi osservati. Il contesto delle risorse mostra se il componente vulnerabile sia presente all'interno di un servizio di valore.

Il flusso di lavoro più efficace combina questi segnali. Elimina le segnalazioni sovrapposte, verifica la raggiungibilità e assegna la responsabilità prima di inviare il lavoro agli ingegneri.

Il blueprint per la gestione delle vulnerabilità basato sul rischio di Google raccomanda di combinare gravità della vulnerabilità, importanza della risorsa e prove delle minacce correnti.

Questo modello affronta la debolezza centrale dei conteggi grezzi di scoperte. Chiede quale segnalazione meriti di essere affrontata per prima, anziché premiare gli strumenti che producono l'elenco più lungo.

I dati di VulnCheck rafforzano questo approccio. Nella prima metà del 2026, l'azienda ha identificato 495 vulnerabilità note come sfruttate nell'intero mercato software.

I sistemi di gestione dei contenuti rappresentavano circa un terzo di questi casi. Anche i dispositivi al perimetro della rete sono rimasti bersagli comuni.

Questi prodotti attirano gli attaccanti perché sono raggiungibili, ampiamente distribuiti e preziosi per l'accesso iniziale. La loro economia di sfruttamento spesso supera quella di componenti interni poco conosciuti.

I responsabili della sicurezza non dovrebbero interpretare i risultati dell'AI come un permesso per ritardare le correzioni. Dovrebbero invece distinguere tre code separate.

La prima coda riguarda lo sfruttamento attivo confermato. Questi difetti richiedono contenimento, rilevamento e correzione immediati perché la minaccia esiste già.

La seconda riguarda vulnerabilità validate e raggiungibili con percorsi di sfruttamento credibili. I team dovrebbero correggerle rapidamente anche in assenza di attacchi osservati.

La terza riguarda candidati non validati o segnalazioni su risorse non raggiungibili. Anche queste richiedono revisione, ma non dovrebbero sostituire minacce sostenute da prove.

Questa struttura impedisce che l'ondata di scoperte appiattisca ogni problema in un'unica categoria di gravità. Offre inoltre ai manutentori una base difendibile per negoziare le tempistiche di divulgazione.

C'è un altro rischio dietro la bassa percentuale di sfruttamento. Il conteggio assoluto può aumentare sostanzialmente anche se la percentuale rimane stabile.

Se l'AI produce dieci volte più vulnerabilità valide, un tasso di sfruttamento costante genera comunque dieci volte più casi sfruttati. Le percentuali possono nascondere questo effetto di scala.

I dati esaminati riflettono inoltre una fase iniziale. Gli attaccanti hanno bisogno di tempo per adottare nuovi strumenti, creare harness affidabili e integrarli con sistemi di ricognizione.

L'accesso pubblico al modello cyber più capace di Anthropic rimane limitato. Questa restrizione riduce ciò che gli attuali dati sullo sfruttamento possono rivelare riguardo all'abuso diffuso.

Anthropic riconosce di non aver creato misure di protezione abbastanza forti per un accesso generale a Mythos. L'azienda sta limitando la distribuzione mentre amplia programmi difensivi controllati.

Questo approccio riduce l'esposizione immediata, ma crea una sfida di misurazione. Un modello con accesso limitato non può rivelare come si comporterebbero normali gruppi criminali con capacità equivalenti.

La conclusione scettica deve quindi rimanere circoscritta. Le prove attuali non mostrano che le vulnerabilità scoperte dall'AI siano intrinsecamente più inclini a essere sfruttate.

Non dimostrano che i sistemi futuri manterranno lo stesso rapporto. Né possono garantire che ogni sfruttamento esistente sia stato scoperto o attribuito pubblicamente.

La risposta politica più solida non è né il panico né la compiacenza. È costruire sistemi di verifica e correzione in grado di scalare prima che l'accesso a modelli cyber avanzati si espanda.

Il modello specializzato di Google alza il tetto delle capacità

L'ultimo modello cyber di Google mostra perché l'attuale rassicurante tasso di sfruttamento non può valere come previsione permanente.

Gemini 3.5 Flash Cyber è un modello leggero ottimizzato per la scoperta, la validazione e la generazione di patch per vulnerabilità. Google prevede un accesso limitato tramite CodeMender per governi e partner fidati.

Il design del modello privilegia esplorazioni ripetute e a minor costo, anziché fare affidamento su una singola chiamata a un modello generale più grande. Più agenti ispezionano i percorsi del codice prima di combinare i loro risultati.

Google afferma che questo approccio è adatto a repository complessi, in cui lo spazio di ricerca supera ciò che può coprire una singola analisi. Supporta inoltre scansioni frequenti durante commit e rilasci.

L'azienda ha riportato un test interno più eclatante. Gemini 3.5 Flash Cyber ha esaminato sistemi Google Cloud e trovato difetti di esecuzione remota del codice in API pubbliche entro due ore.

Google afferma che il modello ha anche individuato un problema di corruzione della memoria in un servizio di produzione sensibile. Ha poi generato un exploit pienamente affidabile nelle condizioni testate.

Secondo i risultati del modello cyber di Google, quell'exploit ha aggirato le protezioni Address Space Layout Randomization e Write XOR Execute.

Address Space Layout Randomization modifica le posizioni di memoria per ostacolare gli attacchi. Write XOR Execute impedisce che la memoria sia scrivibile ed eseguibile contemporaneamente.

Aggirare entrambi i controlli richiede più che riconoscere codice sorgente sospetto. Avvicina il sistema alle difficili fasi di validazione e sviluppo di exploit.

Il risultato rimane una dimostrazione riportata dall'azienda all'interno di un programma difensivo controllato. Google non ha divulgato i sistemi interessati né dettagli sufficienti per una riproduzione esterna.

Ciononostante, indebolisce qualsiasi rassicurante affermazione secondo cui lo sfruttamento rimanga al di là delle capacità dei modelli attuali. La conclusione migliore è che la capacità di sfruttamento esiste in modo disomogeneo e in condizioni vincolate.

Google dispone inoltre di vantaggi insoliti. I suoi team di sicurezza possono accedere a codice interno, contesto di produzione, risultati storici di fuzzing e database dettagliati sulle vulnerabilità.

Queste informazioni offrono agli agenti una base migliore di quella che un attaccante esterno riceverebbe. Aiutano inoltre l'azienda a verificare gli output del modello rispetto a sistemi reali.

Gli attaccanti hanno vantaggi diversi. Possono concentrarsi su prodotti esposti, riutilizzare codice sorgente trapelato, ispezionare le patch e accettare tassi di fallimento più alti.

Una campagna offensiva non deve comprendere ogni segnalazione. Le serve un percorso affidabile contro un numero sufficiente di bersagli di valore.

Questa asimmetria spiega perché l'iniziativa di sicurezza Amazon Google rimane rilevante nonostante i risultati di VulnCheck. Il settore si sta preparando alla diffusione delle capacità, non limitandosi a misurare gli attacchi attuali.

Project Glasswing offre a organizzazioni selezionate il tempo di rafforzare software critico prima che sistemi di livello Mythos diventino generalmente accessibili. Google sta adottando un approccio simile di rilascio limitato.

Tuttavia, l'accesso controllato non può diventare l'intera strategia. Modelli aperti, strumenti specializzati e framework agentici migliorati continueranno a ridurre il divario di capacità.

I difensori hanno quindi bisogno di sistemi che riducano l'esposizione in modo continuo. La scansione prima del rilascio offre più valore dell'aggiunta di un altro avviso dopo che il codice vulnerabile raggiunge la produzione.

Le proposte automatiche di patch possono abbreviare la correzione, ma gli esseri umani devono rivedere le modifiche che riguardano autenticazione, gestione della memoria, crittografia e confini di fiducia.

L'architettura difensiva vincente collega la scoperta del modello a prove riproducibili. Collega poi le prove a patch testate, responsabilità della distribuzione e telemetria degli attacchi.

Questo è uno standard più impegnativo del conteggio delle vulnerabilità. È anche lo standard più strettamente legato a risultati di sicurezza misurabili.

Tre segnali mostreranno se l'equilibrio sta cambiando

La prossima fase sarà misurata attraverso prove di sfruttamento, capacità di correzione e accesso a modelli cyber specializzati.

Il primo segnale è la proporzione di vulnerabilità attribuite all'AI che entrano nei cataloghi di sfruttamento noto. L'attuale risultato dell'1,3 percento di VulnCheck stabilisce un'utile base di riferimento iniziale.

Un aumento sostenuto al di sopra del tasso generale delle vulnerabilità rafforzerebbe l'idea che l'AI produca bersagli insolitamente attraenti. Un tasso stabile sosterrebbe l'interpretazione basata sul volume delle scoperte.

La qualità dell'attribuzione è importante in questo caso. I ricercatori devono distinguere le vulnerabilità trovate dall'AI dagli exploit sviluppati con l'AI dopo che un umano o uno scanner convenzionale ha individuato la debolezza.

Si tratta di capacità diverse, con implicazioni politiche diverse. Un'etichettatura scadente può far apparire più forte una delle due posizioni di quanto consentano le prove.

Il secondo segnale è il registro pubblico delle correzioni di Project Glasswing. I lettori dovrebbero osservare quanti candidati diventano avvisi validati, patch, CVE o falsi positivi chiusi.

L'aggiornamento Glasswing di Anthropic ha riportato solidi risultati di validazione per un sottoinsieme esaminato. Tuttavia, l'arretrato più ampio di candidati è rimasto molto più grande del suo conteggio pubblico di CVE.

Un tasso di patch più rapido mostrerebbe che i sistemi di divulgazione e correzione stanno recuperando terreno rispetto alla scoperta. Un arretrato in aumento confermerebbe che la capacità umana è diventata il principale vincolo di sicurezza.

La qualità delle patch conta quanto la quantità. Correzioni affrettate possono introdurre regressioni, lasciare aperti percorsi di attacco alternativi o divulgare informazioni sufficienti agli attaccanti per ricostruire un exploit.

I ricercatori dovrebbero quindi monitorare la distribuzione e la verifica, non soltanto la pubblicazione delle patch. Una correzione protegge gli utenti solo dopo che i manutentori la rilasciano e gli operatori la installano.

Il terzo segnale è un accesso più ampio a Mythos, Gemini Flash Cyber o modelli specializzati comparabili. Anthropic e Google limitano attualmente le loro capacità più sensibili.

Una disponibilità estesa creerebbe il primo test significativo di come gli agenti cyber avanzati si comportano su una popolazione più ampia. Aumenterebbe inoltre la pressione sulle misure di sicurezza e sulla verifica dell’identità.

Se l’accesso si estende senza un aumento degli sfruttamenti confermati, l’attuale verifica della realtà acquista maggiore forza. Se invece lo sfruttamento cresce rapidamente, l’attuale tasso basso apparirà come un ritardo nell’adozione.

Amazon, Google e i loro partner dovrebbero inoltre pubblicare più misurazioni basate sui risultati. Metriche utili includono vulnerabilità verificate, tempo necessario per applicare le patch, correzioni distribuite e attacchi prevenuti.

I totali dei candidati restano utili per valutare la copertura della ricerca. Non sono sufficienti per misurare se un programma di sicurezza abbia ridotto il rischio concreto.

Per gli sviluppatori, la lezione è pretendere prove riproducibili dagli strumenti di sicurezza AI. Una segnalazione dovrebbe includere il codice interessato, le condizioni raggiungibili, l’impatto e una correzione verificabile.

Per gli acquirenti aziendali, la priorità è l’integrazione con asset e flussi di lavoro esistenti. Uno strumento che produce più avvisi senza assegnazione di responsabilità o contesto può aumentare il rischio operativo.

Per i manutentori open source, meritano maggiore attenzione la tempistica delle divulgazioni e la capacità di revisione finanziata. I sistemi AI possono ora generare lavoro molto più rapidamente di quanto le comunità di volontari possano assorbirlo.

La coalizione per la sicurezza tra Amazon e Google sta rispondendo a una minaccia futura credibile. Tuttavia, le evidenze attuali indicano che la crisi immediata è una pipeline difensiva sovraccarica, non lo sfruttamento automatico su larga scala.

Questa distinzione dovrebbe orientare spesa, progettazione dei prodotti e politiche. I team hanno bisogno di meno avvisi non classificati e di più percorsi verificati, dalla scoperta alla correzione.

Nei prossimi mesi, osservate il rapporto di sfruttamento, l’arretrato delle patch e l’accesso ai modelli specializzati. Insieme, questi segnali mostreranno se l’AI cambia l’economia degli attacchi o modifica principalmente il volume delle scoperte.

La domanda pratica per ogni team di sicurezza è semplice: la vostra organizzazione è in grado di convalidare e correggere le vulnerabilità più rilevanti prima che una coda più ampia le nasconda?