La corsa alla sicurezza tra Amazon e Google cambia passo mentre l'AI aiuta a correggere 1.072 falle di Chrome

Google afferma che strumenti di sicurezza assistiti dall'AI hanno aiutato Chrome a correggere 1.072 vulnerabilità nelle versioni 149 e 150, fissando un nuovo e significativo riferimento per la difesa automatizzata. Il totale supera i bug di sicurezza risolti nelle precedenti 23 milestone di Chrome messe insieme. Questo salto rende la più ampia competizione tra Amazon e Google qualcosa di più rilevante di una corsa ai modelli cloud.

La vera notizia non è che un modello AI abbia individuato numerosi pattern di codice sospetti. Google ha messo insieme agenti che aiutano a scoprire, riprodurre, classificare, assegnare, correggere, testare, rilasciare e documentare le vulnerabilità. Gli sviluppatori umani continuano a revisionare le correzioni candidate, ma l'automazione ora interviene in quasi ogni fase del processo.

Questo cambia il vincolo centrale della sicurezza software. Individuare difetti era un lavoro costoso e specializzato, svolto da team limitati. L'AI può ora generare segnalazioni più velocemente di quanto le organizzazioni riescano a validare, rilasciare e distribuire in sicurezza le relative correzioni.

Amazon, Microsoft, Anthropic e altre grandi aziende tecnologiche affrontano lo stesso cambiamento. Il loro vantaggio dipenderà meno dal possesso di un modello capace e più dalla capacità di gestire attorno a esso una pipeline di sicurezza affidabile.

Le 1.072 correzioni di Chrome ridefiniscono la scala del patching

Il numero record di correzioni di Chrome mostra che il lavoro sulle vulnerabilità assistito dall'AI è passato da esperimenti isolati all'ingegneria di produzione.

Google ha divulgato i dati il 30 luglio 2026, in un resoconto dettagliato della propria pipeline di sicurezza di Chrome. Chrome 149 e Chrome 150 contenevano correzioni per 1.072 bug di sicurezza, secondo l'azienda.

Le 23 milestone precedenti di Chrome contenevano complessivamente meno correzioni. Un rapporto indipendente ha stimato quel precedente totale in 1.036, rendendo l'impennata di due release superiore a circa due anni di output precedente.

Questi numeri richiedono un'interpretazione prudente. Non significano che ogni bug corretto sia stato scoperto autonomamente da un modello linguistico. Né significano che tutte le 1.072 falle avessero la stessa gravità o fossero facilmente sfruttabili.

L'affermazione più circoscritta di Google rimane comunque significativa. I modelli linguistici di grandi dimensioni generano ora correzioni candidate per la maggior parte delle vulnerabilità che entrano nel suo processo. L'AI supporta inoltre scoperta, classificazione, riproduzione, generazione dei test e instradamento delle issue.

Questa distinzione conta perché la gestione delle vulnerabilità è una catena. Un rilevatore che produce migliaia di avvisi offre poca protezione quando gli ingegneri non riescono a distinguere difetti sfruttabili da duplicati, rumore o opportunità di rafforzamento a basso rischio.

Google afferma che il suo sistema automatizzato di triage verifica innanzitutto se una segnalazione sia pertinente, completa e non duplicata. Cerca quindi di riprodurre il problema sulle configurazioni interessate di browser e sistemi operativi.

La pipeline aggiunge metadati, tra cui una stima della gravità e il punto in cui il difetto è entrato nella codebase. Infine assegna la segnalazione a un responsabile umano.

Gli sviluppatori possono rivedere la valutazione automatizzata della gravità. Esaminano inoltre le patch candidate e gli artefatti di supporto prodotti dagli agenti.

Questa struttura rende il conteggio di 1.072 più significativo dell'output di uno scanner di codice autonomo. Si tratta di correzioni arrivate nelle release stabili di Chrome, non di semplici avvisi generati da un modello e rimasti in una coda interna.

Google stima che il triage automatizzato faccia risparmiare centinaia di ore di lavoro agli sviluppatori ogni mese. L'azienda afferma inoltre che gli agenti per la scrittura dei test possono eliminare settimane di lavoro legate alle numerose piattaforme e configurazioni supportate da Chrome.

Una scoperta illustra la potenziale profondità di questo approccio. Secondo quanto riportato, un harness di agenti Gemini nei primi mesi del 2026 ha individuato una sandbox escape rimasta nella codebase di Chrome per oltre 13 anni.

Una sandbox escape consente a contenuti del browser compromessi di oltrepassare un confine di isolamento e raggiungere risorse che dovrebbero restare protette. Google ha dichiarato che questa falla avrebbe potuto indurre il browser a leggere file locali.

L'età di quel difetto non dimostra che l'AI superi costantemente i ricercatori di sicurezza esperti. Mostra che i modelli possono riesaminare codice maturo con strategie di ricerca diverse, un contesto storico più ampio e un numero molto maggiore di tentativi ripetuti.

Google ha inoltre riferito che i suoi strumenti integrati hanno impedito a oltre 20 vulnerabilità di raggiungere la produzione durante maggio. Il totale includeva un problema nella categoria di criticità più elevata dell'azienda.

Il confronto alla base della keyword amazon google è dunque più ampio dei totali da titolo. Riguarda quale azienda riesca a collegare i modelli a repository reali, test, cronologie delle issue, sistemi di revisione e infrastrutture di rilascio.

Un modello può proporre una patch in pochi secondi. Un'organizzazione di sicurezza affidabile deve comunque dimostrare che la patch corregga la condizione giusta senza compromettere comportamenti non correlati.

È questo livello operativo a dare maggior peso all'annuncio di Google. Presenta la sicurezza AI come un sistema di produzione gestito, anziché come un chatbot che genera codice speculativo.

Perché la sfida di sicurezza tra Amazon e Google riguarda le pipeline

Il vantaggio competitivo appartiene alle organizzazioni in grado di trasformare l'output dei modelli in protezione revisionata e distribuita prima che gli attaccanti sfruttino la stessa falla.

Il sistema di Google si basa su diversi anni di ricerca sulla sicurezza sempre più specializzata. Nel 2023, gli ingegneri di Chrome hanno usato modelli linguistici per migliorare il fuzzing, che invia input insoliti al software per esporre crash e comportamenti non sicuri.

Nel 2024, Google Project Zero ha sviluppato Naptime, un framework che forniva ai modelli linguistici gli strumenti necessari per la ricerca sulle vulnerabilità. Google DeepMind e Project Zero hanno poi seguito con Big Sleep, un agente che ha individuato difetti nel motore V8 di Chrome e nello stack grafico.

Il workflow più recente va oltre la scoperta. Gli agenti di correzione producono più patch candidate, mentre un agente critico separato valuta le opzioni e prepara il materiale per uno sviluppatore.

Gli agenti di correzione e critici lavorano in un ciclo di revisione. Gli agenti per la scrittura dei test creano quindi controlli destinati a funzionare negli ambienti supportati da Chrome prima che uno sviluppatore approvi la modifica.

Questa divisione del lavoro assomiglia più a un team di ingegneria della sicurezza che a un singolo assistente. Ogni agente riceve una responsabilità più circoscritta e la pipeline mantiene la revisione umana nei punti più importanti.

Google ha inoltre creato una base di conoscenza di Chrome contenente vulnerabilità precedentemente identificate e la cronologia Git del progetto. Questo contesto aiuta i modelli a ragionare oltre i pattern disponibili nei dati di addestramento originali.

I file SECURITY.md a livello di repository descrivono i confini di fiducia e le ipotesi locali sulle minacce. Un agente critico legge queste istruzioni separatamente, riducendo la propria dipendenza dal ragionamento iniziale dell'agente di correzione.

L'azienda esegue ripetutamente i modelli sullo stesso codice perché i loro output sono non deterministici. Un'esecuzione diversa può esplorare un altro percorso, identificare un'altra interazione o respingere una conclusione precedente.

La scala è particolarmente importante per Chrome. Google afferma che Chromium e i progetti correlati contengono più di 2.300 dipendenze di terze parti, di cui circa 1.700 raggiungono gli utenti in qualche forma.

Queste dipendenze includono il motore JavaScript V8, la libreria grafica Skia, il livello di traduzione grafica ANGLE e la libreria crittografica BoringSSL. Una vulnerabilità del browser può emergere dalle interazioni oltre questi confini.

Google prevede di inserire tutte le dipendenze di terze parti di Chrome in pipeline automatizzate di aggiornamento. Le pipeline utilizzeranno feed interni e risorse pubbliche, compresi database delle vulnerabilità, per individuare le correzioni upstream disponibili.

È qui che la rivalità tra Amazon e Google diventa una competizione infrastrutturale. Entrambe le aziende gestiscono grandi piattaforme cloud, ampi portafogli software e catene di fornitura ricche di componenti open source.

Amazon ha inoltre un importante legame strategico con Anthropic, i cui modelli e iniziative di sicurezza raggiungono gli sviluppatori tramite infrastrutture cloud. Tuttavia, possedere l'accesso ai modelli non produce automaticamente la stessa profondità di integrazione di Google all'interno di Chrome.

Google controlla il repository del browser, i sistemi di integrazione continua, il processo di rilascio, la telemetria, gli ambienti di test e una consistente cronologia delle vulnerabilità. Questa combinazione fornisce un contesto che un fornitore esterno di modelli non può riprodurre facilmente.

Il più recente modello di cybersecurity di DeepMind rafforza questo punto. Google afferma che Gemini 3.5 Flash Cyber è ottimizzato per trovare, validare e correggere vulnerabilità tramite chiamate ripetute al modello a costo inferiore.

L'azienda ha riportato 55 problemi V8 unici e confermati durante una valutazione a invocazioni fisse. Il suo modello Gemini principale ne ha trovati 47, mentre Claude Opus 4.6 ne ha trovati 36 nelle condizioni di test di Google.

Si tratta di risultati benchmark riportati dall'azienda, non di un audit indipendente. Google ha inoltre osservato che le policy di sicurezza dei fornitori hanno influenzato quali versioni dei concorrenti potessero completare la valutazione.

Tuttavia, il meccanismo è degno di nota. Un modello specializzato più piccolo può essere eseguito ripetutamente su un vasto spazio di ricerca, quindi consolidare il proprio lavoro attraverso un sistema di agenti.

Questo approccio sposta l'attenzione dalla massima intelligenza del modello al numero di risultati utili per unità di calcolo e sforzo di revisione. I team di sicurezza hanno bisogno di ampia copertura, prove riproducibili e report gestibili più che di spiegazioni eloquenti.

Amazon e altri provider cloud subiranno pressioni per offrire pipeline comparabili ai clienti enterprise. Gli acquirenti chiederanno se un servizio sia in grado di trovare un difetto, verificarne la raggiungibilità, proporre una correzione e generare test affidabili.

Chiederanno inoltre dove viaggi il codice sorgente, cosa conservi il modello e se gli agenti possano contattare sistemi esterni. Uno strumento di sicurezza che amplia l'esposizione del codice può creare il rischio che promette di ridurre.

Google afferma che i suoi modelli interni di scansione operano su macchine blindate senza accesso generale a internet. Le richieste di rete sono intercettate e controllate tramite allowlist di applicazioni e destinazioni.

I sottoagenti non possono modificare il sistema locale né accedere a file al di fuori delle directory sorgenti designate. Questi controlli sono essenziali perché l'analisi autonoma della sicurezza combina codice sorgente prezioso con strumenti capaci di esplorare le debolezze.

La prossima fase della sfida di sicurezza tra Amazon e Google dipenderà quindi da contenimento e prove. Un punteggio del modello da solo non può stabilire se un'azienda debba fidarsi di un agente all'interno di un repository sensibile.

L'AI cambia l'economia dell'individuazione e della correzione dei bug

Il cambiamento centrale è economico: la scoperta automatizzata rende abbondanti le segnalazioni di sicurezza, mentre il giudizio umano resta scarso.

Doug Turner, direttore dell'ingegneria di Chrome, ha dichiarato a TechCrunch che i modelli linguistici hanno trasformato la scoperta delle vulnerabilità in un'operazione automatizzata su scala industriale. I totali delle correzioni riportati offrono una prova visibile di questa affermazione.

La ricerca tradizionale sulle vulnerabilità richiede esperti che comprendano linguaggi di programmazione, sistemi operativi, tecniche di exploit e l'architettura di un obiettivo. Queste competenze restano essenziali, ma i modelli possono ora ripetere parti della ricerca con uno sforzo marginale molto ridotto.

Possono ispezionare vecchi commit, confrontare pattern tra componenti, costruire casi di test e riesaminare aree precedentemente scartate. Possono inoltre operare in modo continuo invece di attendere un audit programmato.

Il conseguente aumento di produttività non arriva in modo uniforme. La scoperta scala per prima perché generare una segnalazione sospetta è più semplice che dimostrare che tale segnalazione sia rilevante.

Un rapporto credibile deve dimostrare che il codice interessato è raggiungibile in condizioni realistiche. Dovrebbe identificare il confine di sicurezza violato e riprodurre il comportamento su una build pertinente.

I team devono quindi decidere gravità e priorità. Un errore di memoria tecnicamente valido può avere un impatto limitato, mentre una piccola falla logica può diventare pericolosa se concatenata a un'altra debolezza.

La generazione di patch introduce un ulteriore standard di prova. La modifica deve chiudere il percorso vulnerabile senza creare regressioni, indebolire un'altra difesa o limitarsi a nascondere il sintomo osservabile.

I test diventano più difficili con la crescita del software. Chrome funziona su più sistemi operativi, architetture di processore, classi di dispositivi e configurazioni aziendali.

Una patch che si comporta correttamente in un ambiente di test può fallire altrove. La generazione automatizzata dei test aiuta, ma i test generati possono anche incorporare le ipotesi errate del modello.

Per questo è importante l'uso da parte di Google di agenti separati per la correzione e la critica. Contesti indipendenti possono far emergere contraddizioni che un singolo agente potrebbe trasferire dalla diagnosi alla correzione proposta.

Tuttavia, più agenti non equivalgono a revisori umani indipendenti. Possono condividere pregiudizi derivanti dall'addestramento, fraintendere la stessa architettura o convergere su una spiegazione plausibile ma incompleta.

Il cambiamento economico crea quindi una nuova coda. Le organizzazioni di sicurezza un tempo disponevano di più codice di quanto i ricercatori potessero ispezionare. Sempre più spesso hanno più segnalazioni e correzioni candidate di quante i revisori possano approvare con sicurezza.

L'esperienza di Google mostra già questa pressione. Il team di sicurezza di Chrome ha riferito di aver ricevuto, entro marzo 2026, più segnalazioni di bug che nell'intero 2025.

L'azienda ha modificato il proprio programma di ricompense per le vulnerabilità affinché i ricercatori esterni presentassero lavori che aggiungessero valore rispetto alle rilevazioni interne. Ha inoltre cercato segnalazioni che potessero entrare più facilmente in un processo automatizzato.

Questo cambio di politica trasmette un segnale importante ai ricercatori indipendenti. L'AI può assorbire l'individuazione di schemi ripetitivi, ma lo sfruttamento creativo e il ragionamento tra componenti restano preziosi.

I ricercatori umani possono concentrarsi su catene di attacco complesse, ipotesi di fiducia insolite e divari tra il comportamento previsto e quello effettivo del prodotto. Queste aree sono più difficili da ridurre a scansioni ripetute dei repository.

Il mercato del lavoro legato alla sicurezza potrebbe cambiare di conseguenza. Gli analisti junior dedicheranno meno tempo ad arricchire manualmente i ticket ordinari, mentre gli ingegneri senior avranno maggiori responsabilità per gli standard di revisione e le decisioni architetturali.

La produttività degli sviluppatori dipenderà dalla gestione delle informazioni tanto quanto dall'accesso ai modelli. I team hanno bisogno di archivi ricercabili che colleghino rilevazioni, cronologia del codice, ipotesi sulle minacce, risultati dei test, responsabilità e decisioni di rilascio.

Senza questo contesto, un agente AI produce suggerimenti isolati. Con esso, il sistema può stabilire se una rilevazione duplica una vecchia segnalazione o entra in conflitto con una precedente scelta progettuale.

Questo meccanismo spiega perché il confronto tra amazon e google non può ridursi a quale azienda offra il modello generale più potente. Le prestazioni nella sicurezza dipendono dalla memoria istituzionale resa utilizzabile alla velocità delle macchine.

L'azienda che organizza meglio queste evidenze può rendere ogni chiamata al modello più pertinente. Può anche offrire ai revisori umani una base più chiara per accettare o respingere il lavoro automatizzato.

Cosa non dimostra il numero record di correzioni

Un numero elevato di correzioni rilasciate è incoraggiante, ma non dimostra la qualità delle patch, la riduzione degli exploit o un vantaggio difensivo duraturo.

Google ha pubblicato una descrizione dettagliata del proprio flusso di lavoro, ma diverse misurazioni importanti restano indisponibili. L'azienda non ha divulgato una ripartizione completa di come siano stati scoperti i 1.072 bug.

Non ha separato pubblicamente le scoperte originate dai modelli dalle segnalazioni umane, dai risultati del fuzzing tradizionale, dagli aggiornamenti delle dipendenze o dagli elementi già presenti nel backlog. Inoltre, non ha assegnato un profilo di gravità uniforme al totale.

Questa assenza è rilevante perché i conteggi dei bug possono combinare esiti di sicurezza molto diversi. Chiudere un percorso critico di esecuzione di codice da remoto non equivale a correggere un errore di convalida a basso impatto.

I totali delle correzioni possono aumentare anche quando un team modifica le pratiche di classificazione o segnalazione. Un'organizzazione potrebbe dividere un singolo difetto sottostante in più ticket o riunire rilevazioni correlate in un'unica riparazione.

Il totale pubblicato resta reale nel senso limitato che le correzioni hanno raggiunto le milestone di Chrome. Tuttavia, non può rivelare autonomamente quanto rischio sia scomparso.

L'inquadramento di Google mantiene opportunamente metodi complementari. L'azienda afferma che il fuzzing resta efficace nel trovare difetti creati da interazioni a lungo raggio tra parti separate della base di codice.

I ricercatori umani restano parte della strategia attraverso il programma di ricompense per le vulnerabilità di Chrome. Difese architetturali, linguaggi memory-safe e protezioni in fase di esecuzione restano necessari perché individuare singoli difetti non garantisce mai una copertura completa.

La preoccupazione più profonda riguarda la falsa fiducia. Le patch generate dall'AI spesso appaiono coerenti, soprattutto quando sono accompagnate da una spiegazione plausibile e da test superati.

Una patch può comunque lasciare aperto un altro percorso sfruttabile. Può anche introdurre una regressione sottile che i test esistenti non esercitano.

Google mantiene gli esseri umani nel percorso di approvazione, ma la capacità di revisione è limitata. Se le correzioni candidate crescono più rapidamente della disponibilità di revisori esperti, la pressione ad accettare il lavoro automatizzato può indebolire questa salvaguardia.

L'uso di agenti critici affronta in parte questo problema. Tuttavia, Google non ha pubblicato un confronto indipendente che copra falsi positivi, vulnerabilità mancate, regressioni delle patch e tempo di revisione umana.

Anche i risultati di Gemini 3.5 Flash Cyber sono auto-riportati. Il design del benchmark usa vulnerabilità private per ridurre la contaminazione dell'addestramento, ma i ricercatori esterni non possono riprodurre pienamente questi test privati.

Le restrizioni alla distribuzione rivelano un altro compromesso irrisolto. Google inizialmente limita il modello specializzato a governi e partner fidati tramite CodeMender, citando la natura a duplice uso delle capacità cyber.

Lo stesso modello che trova una vulnerabilità per i difensori può aiutare un attaccante a individuarla e sfruttarla. DeepMind ha riferito che il modello ha generato un exploit affidabile di esecuzione di codice da remoto durante un'esercitazione interna.

Questa capacità rende rischioso un accesso ampio. Limitarla, tuttavia, concentra gli strumenti difensivi avanzati tra le grandi organizzazioni, mentre i manutentori più piccoli continuano a ricevere segnalazioni sempre più sofisticate.

Google sta sostenendo la capacità di risposta open source, ma i manutentori affrontano comunque un'asimmetria. Gli agenti automatizzati possono cercare continuamente in migliaia di progetti, mentre un piccolo progetto può avere un solo revisore part-time.

Più rilevazioni possono quindi rendere temporaneamente l'ecosistema meno sicuro. Una correzione pubblica può esporre la debolezza sottostante prima che ogni utente a valle riceva l'aggiornamento.

Questo periodo è il patch gap, quando gli attaccanti ricostruiscono tramite reverse engineering una modifica pubblicata e prendono di mira sistemi non corretti. Una scoperta più rapida aumenta l'importanza di ridurre questa finestra.

Gli aggiornamenti di sicurezza pubblici di Chrome mostrano che distribuzione, sicurezza della memoria e aggiornamento delle dipendenze restano problemi di ingegneria attivi. L'AI non ne elimina nessuno.

Il record non significa nemmeno che Chrome fosse insolitamente insicuro prima dei rilasci. Un numero più alto di correzioni può riflettere una migliore visibilità su difetti già esistenti.

Al contrario, l'individuazione di molti bug di lunga durata dovrebbe impedire il compiacimento. Il problema della sandbox risalente a 13 anni fa mostra come software maturo e sottoposto a intenso scrutinio possa mantenere ipotesi pericolose.

Questa lezione va oltre Google. Amazon, Microsoft, Apple, Mozilla e i fornitori di software aziendale gestiscono tutti codice vecchio che interagisce con componenti più nuovi.

L'interpretazione sensata non è né celebrazione né allarme. L'AI ha aumentato il volume osservabile di lavoro di sicurezza correggibile, mentre le evidenze sulla riduzione netta del rischio restano incomplete.

Una scoperta più rapida rende la velocità di rilascio il nuovo campo di battaglia

La sicurezza dipende ora dal fatto che le patch raggiungano i browser in esecuzione prima che gli avversari possano ricostruire e sfruttare le falle sottostanti.

Google descrive cinque fasi nella vita di una vulnerabilità: scoperta, triage, riparazione, rilascio e installazione. L'AI accelera le prime fasi, ma gli utenti non ricevono alcuna protezione finché l'ultima fase non è completata.

Il modello di sviluppo open source di Chrome rende particolarmente sensibile la tempistica dei rilasci. Una volta che una correzione di sicurezza arriva nel codice pubblico, gli attaccanti possono ispezionare la modifica alla ricerca di indizi sul comportamento vulnerabile.

Google afferma che le correzioni richiedono in genere settimane per passare dall'albero di sviluppo principale al canale stabile. Le riparazioni gravi possono essere integrate direttamente in un ramo stabile attivo.

Chrome si sta avviando verso una cadenza di due settimane per le milestone principali, accompagnata da aggiornamenti di sicurezza settimanali. Google sta inoltre sperimentando due rilasci di sicurezza alla settimana.

Una cadenza più rapida riduce l'esposizione, ma esercita maggiore pressione sui test e sulla gestione delle modifiche aziendali. Gli amministratori devono spesso valutare la compatibilità prima di distribuire modifiche al browser in un ampio parco dispositivi.

Rilasci frequenti possono anche creare affaticamento da aggiornamenti. Gli utenti potrebbero rimandare il riavvio del browser quando vogliono preservare schede, moduli, chiamate o lavoro attivo.

Chrome scarica e prepara gli aggiornamenti in background, ma molte modifiche entrano in vigore solo dopo un riavvio. Google afferma che questo ritardo può diventare significativo quando triage, riparazione, test e rilascio richiedono solo uno o due giorni.

L'azienda sta studiando il patching dinamico, che sostituirebbe determinati processi figlio senza riavviare l'intero browser. I processi di rendering e grafica sono potenziali obiettivi perché Chrome li separa già tramite un'architettura multiprocesso.

Chrome 150 ha inoltre introdotto un comportamento su macOS che riavvia automaticamente il browser quando è in attesa un aggiornamento e non rimangono finestre aperte. L'obiettivo è applicare la protezione in un momento a basso impatto.

Questi miglioramenti alla distribuzione sono più importanti di quanto sembrino. Un sistema AI che produce correzioni eccellenti non può superare un attaccante quando il software protetto resta inattivo sul disco.

I team aziendali dovrebbero quindi valutare la sicurezza del browser attraverso i dati di distribuzione, non solo gli annunci di rilascio. Hanno bisogno di visibilità su quali dispositivi eseguono versioni obsolete e per quanto tempo tali dispositivi restano indietro.

La competizione di sicurezza tra amazon e google raggiunge anche questo livello operativo. Entrambe le aziende servono organizzazioni con endpoint distribuiti, carichi di lavoro cloud, dipendenze software e requisiti esigenti di disponibilità.

La piattaforma vincente aiuterà i clienti a collegare la scoperta alla responsabilità, alla convalida delle patch, al rollout graduale e a un'installazione verificabile. Una rilevazione senza prove di distribuzione è un'attività di sicurezza incompleta.

L'esperienza di Microsoft suggerisce che la tendenza si estenda oltre i browser. Il suo ampio rilascio di sicurezza del luglio 2026 ha attirato l'attenzione perché processi assistiti dall'AI sono stati associati a un forte aumento delle vulnerabilità affrontate.

Un'analisi di Associated Press ha inoltre descritto gli sforzi crescenti delle principali aziende AI per mettere modelli cyber avanzati a disposizione dei difensori. Amazon, Apple, Google e Microsoft hanno aderito a un'iniziativa collegata ad Anthropic incentrata sui rischi del software critico.

Non si tratta di una semplice gara tra reparti di sicurezza aziendale. Anche gli attaccanti possono usare i modelli per studiare le patch, generare varianti di exploit e cercare debolezze simili in prodotti correlati.

I difensori mantengono diversi vantaggi strutturali. Controllano repository del codice sorgente, infrastrutture di test, sistemi di distribuzione, archivi storici dei bug e documenti interni sull'architettura.

Gli attaccanti mantengono un obiettivo asimmetrico. Un difensore deve proteggere ogni confine importante, mentre a un attaccante basta un solo percorso utilizzabile.

La velocità di rilascio riduce questo squilibrio, ma non può eliminarlo. La prevenzione strutturale resta necessaria, perché nessuna organizzazione può individuare e correggere in modo affidabile ogni difetto prima che venga sfruttato.

La strategia a più lungo termine di Google include quindi la sostituzione dei componenti C++ ad alto rischio con Rust, un linguaggio progettato per prevenire molti errori di memoria durante la compilazione.

Sta inoltre ampliando le protezioni dei puntatori e convertendo i modelli non sicuri basati su puntatore e dimensione in span verificati dal compilatore. Google afferma che il 97% del codice Chrome sviluppato internamente viene ora compilato con avvisi rigorosi sui buffer non sicuri.

Queste misure riducono intere categorie di vulnerabilità anziché gestirle singolarmente. L'AI può accelerare la migrazione, ma è il cambiamento architetturale a offrire una protezione duratura.

Il prossimo parametro di riferimento significativo combinerà entrambi gli approcci. Le aziende dovranno dimostrare che gli agenti aumentano la velocità di correzione, mentre il lavoro strutturale riduce il numero e l'impatto dei difetti che raggiungono la produzione.

Tre segnali indicheranno se la sicurezza AI sta funzionando

La prossima fase dovrebbe essere valutata in base alla qualità delle patch, alla latenza di distribuzione e alla riduzione sostenuta del rischio, non a un altro record nel numero di bug.

Il primo segnale è l'esperienza di Google con due rilasci di sicurezza alla settimana. Il progetto pilota verificherà se Chrome può ridurre il divario temporale per le patch senza causare crash, regressioni o resistenze inaccettabili da parte degli amministratori.

Un progetto pilota riuscito rafforzerebbe l'affermazione di Google secondo cui l'intera pipeline può scalare insieme alla capacità di individuazione. Un backlog in crescita o rilasci instabili mostrerebbero invece che l'automazione ha semplicemente spostato il vincolo più a valle.

Osservate il tempo che intercorre tra un rilevamento convalidato e un aggiornamento stabile installato. Questa misura riunisce triage, revisione, test, rilascio e comportamento degli utenti al riavvio in un unico risultato pratico.

Il secondo segnale è costituito da prove indipendenti sulla qualità delle patch generate dall'AI. Google ha descritto ampie misure di sicurezza, agenti critici, sistemi di test e revisione umana, ma la convalida esterna resta limitata.

Una divulgazione utile includerebbe tassi di falsi positivi, tassi di regressione, tempo dei revisori, distribuzioni della gravità e quota di correzioni proposte dal modello accettate senza revisioni sostanziali.

Questi dati aiuterebbero gli acquirenti aziendali a confrontare gli agenti di sicurezza in base ai risultati anziché alle dimostrazioni. Rivelerebbero inoltre se i modelli cyber specializzati riducono il lavoro totale o generano semplicemente più materiale da esaminare per gli esperti.

Il confronto dovrebbe includere sia le patch riuscite sia i difetti mancati. Un sistema che rileva schemi comuni ma trascura violazioni insolite dei confini di fiducia può registrare totali impressionanti senza coprire i percorsi di attacco più pericolosi.

Il terzo segnale sarà la risposta di Amazon, Microsoft, Anthropic e altri fornitori. I loro prodotti necessitano di collegamenti comparabili tra ragionamento del modello, codice privato, test, tracker dei problemi, intelligence sulle dipendenze e distribuzione controllata.

La posizione di Amazon merita particolare attenzione per la sua portata nel cloud e il rapporto con Anthropic. Il confronto amazon google si intensificherà se Amazon trasformerà modelli cyber avanzati in servizi verificabili per i team di sviluppo quotidiani.

La politica di accesso sarà parte di questa risposta. I modelli cyber altamente capaci comportano reali rischi di duplice uso, ma una distribuzione ristretta può lasciare i piccoli progetti open source senza una capacità difensiva sufficiente.

Una risposta credibile del settore deve combinare accesso controllato e supporto ai manutentori. Altrimenti, aggressori meglio finanziati e grandi fornitori ottengono l'automazione, mentre i progetti comunitari critici assorbono l'onere delle segnalazioni.

I lettori dovrebbero anche osservare se i totali delle vulnerabilità alla fine diminuiscono. Un aumento temporaneo è coerente con agenti che scoprono anni di difetti accumulati.

Un aumento persistente può avere diverse interpretazioni. I modelli potrebbero continuare a trovare problemi più profondi, il nuovo codice potrebbe introdurre difetti più rapidamente oppure le pratiche di classificazione potrebbero continuare ad ampliarsi.

La prova più solida combinerebbe un'elevata individuazione iniziale con un minor numero di vulnerabilità gravi che raggiungono la produzione. Google ha iniziato a scansionare le modifiche al codice nei suoi sistemi di integrazione continua e nelle code di commit per perseguire questo obiettivo.

Questi modelli segnalano puntatori pendenti, problemi di sicurezza numerica e modelli di buffer non sicuri prima che il codice venga integrato. Usano inoltre l'analisi semantica per individuare interazioni che i controlli statici convenzionali potrebbero non rilevare.

Google afferma che Big Sleep e CodeMender vengono eseguiti ogni 24 ore sulle modifiche al codice. Spostare il rilevamento vicino al momento dell'invio riduce il costo della correzione, perché gli sviluppatori comprendono ancora la modifica circostante.

La prevenzione evita anche il divario pubblico per le patch. Una vulnerabilità bloccata prima della produzione non richiede mai un aggiornamento d'emergenza né una corsa contro il reverse engineering.

Per gli sviluppatori, la lezione immediata è pratica. Non considerate una segnalazione di sicurezza generata da un modello come una prova e non liquidatela perché un essere umano non l'ha individuata per primo.

Richiedete una riproduzione, un confine di fiducia definito, una valutazione dell'impatto, test mirati, una revisione indipendente e prove della distribuzione. Conservate questi materiali affinché gli agenti successivi possano ragionare sulla base della storia istituzionale.

Per gli acquirenti aziendali, chiedete dove vengono eseguiti gli agenti e a quali file possono accedere. Chiedete se le richieste di rete sono bloccate, registrate o limitate in base alla destinazione.

Chiedete inoltre come il servizio gestisce la conservazione del codice sorgente, l'addestramento dei modelli, l'esposizione di segreti, gli exploit generati e le autorizzazioni degli agenti. I controlli di sicurezza attorno al modello meritano lo stesso scrutinio riservato al modello stesso.

Le 1.072 correzioni di Google dimostrano che l'AI può aumentare il throughput di un'organizzazione di sicurezza matura. Non dimostrano che i sistemi autonomi possano sostituire in sicurezza tale organizzazione.

Questa distinzione definirà la prossima fase della corsa alla sicurezza tra amazon e google. I modelli stanno diventando abbondanti, ma la revisione affidabile, la conoscenza dell'architettura e una distribuzione rapida restano scarse.

I team dovrebbero ora esaminare la propria pipeline, dal rilevamento all'installazione. Possono riprodurre le segnalazioni automatizzate, revisionare le correzioni candidate, testare gli ambienti interessati e dimostrare che gli utenti hanno ricevuto la correzione?

Questa domanda conta più del prossimo totale da prima pagina. Se la risposta resta poco chiara, l'AI ha accelerato l'individuazione senza completare la difesa.