La caccia ai bug assistita dall'IA di Chrome batte un record di patch durato due anni

Google ha corretto 1.072 bug di sicurezza di Chrome in due release, superando le precedenti 23 versioni messe insieme dopo che l'IA ha trasformato il suo flusso di lavoro per le vulnerabilità.

Chrome 149 e Chrome 150 hanno risolto più problemi di sicurezza segnalati di quanti Google ne avesse affrontati in circa due anni di release precedenti. Il confronto fa apparire questa notizia di Google News come una vittoria netta per la sicurezza automatizzata. Ma pone anche una domanda meno rassicurante: cosa succede quando individuare bug diventa molto più rapido della capacità umana di valutarli e correggerli?

L'impennata non è arrivata da un singolo sistema autonomo che riscrive silenziosamente Chrome. Google ha combinato individuazione assistita dall'IA, test deterministici, triage automatizzato e revisione da parte degli sviluppatori. Un'indagine assistita dall'IA ha inoltre portato alla luce una falla ad alta gravità collegata a codice che, secondo quanto riferito, era sopravvissuto per 13 anni.

Questa distinzione è importante. La vera sfida non è tra Google e un altro produttore di browser. È tra l'individuazione alla velocità dell'IA e la pipeline di correzione controllata dagli esseri umani, che deve convalidare ogni segnalazione, valutarne la gravità, testare la patch e distribuirla in sicurezza.

Google News si concentra su 1.072 correzioni di sicurezza di Chrome

Il numero straordinario è reale, ma descrive una pulizia della sicurezza più ampia, non 1.072 exploit indipendentemente sfruttabili.

Google afferma che Chrome 149 e Chrome 150 hanno risolto complessivamente 1.072 bug di sicurezza. Le precedenti 23 milestone di Chrome ne avevano corretti 1.036. Due release hanno quindi superato il totale di quasi due anni di versioni precedenti.

Chrome 150 offre una prospettiva utile sulla portata del fenomeno. Un conteggio iniziale attribuiva 382 correzioni a quella milestone, comprese 15 vulnerabilità critiche e 67 ad alta gravità. Google ha poi aggiornato il totale della release a 433, secondo il conteggio pubblicato di Chrome 150.

Le debolezze segnalate includevano errori use-after-free, accessi alla memoria out-of-bounds, type confusion, uso di dati non inizializzati e convalida insufficiente degli input. Queste categorie possono avere conseguenze gravi, inclusa l'esecuzione di codice all'interno di un renderer compromesso.

Alcune vulnerabilità possono inoltre aiutare un attaccante a superare il confine della sandbox di Chrome. Una sandbox isola i contenuti web dal resto del sistema operativo, limitando ciò che una pagina dannosa può raggiungere. Superarla può trasformare la compromissione di un browser in una compromissione più ampia del dispositivo.

Tuttavia, un conteggio grezzo dei bug non equivale a un conteggio di zero-day sfruttabili. Le release includevano problemi con diversi livelli di gravità, componenti, configurazioni e fasi di sviluppo. Alcune segnalazioni potrebbero riguardare codice protetto da feature flag disabilitati o percorsi che richiedono condizioni insolite.

La documentazione di Google stessa riconosce che le segnalazioni generate dall'IA variano in qualità. Alcune ricevono classificazioni di gravità errate, non dispongono di una proof of concept completa, duplicano segnalazioni esistenti o descrivono comportamenti che gli ingegneri non considerano una violazione di un confine di sicurezza.

Questo rende significativa la cifra di 1.072 in termini di capacità operativa, ma incompleta come misura della riduzione del rischio. Mostra che Google ha elaborato e corretto un volume molto maggiore di segnalazioni di sicurezza. Non dimostra che Chrome avesse improvvisamente accumulato 1.072 vulnerabilità ugualmente pericolose.

I dati della release rivelano anche quanto del lavoro sia arrivato dall'interno di Google. Delle 382 vulnerabilità inizialmente segnalate per Chrome 150, 358 sono state scoperte internamente. I ricercatori esterni sono rimasti importanti, soprattutto per le segnalazioni ad alto impatto, ma gli strumenti interni hanno generato la maggior parte del volume.

Il cambiamento è quindi più ampio di un singolo ciclo di patch particolarmente intenso. Google ha costruito una pipeline per le vulnerabilità in grado di generare, riprodurre, classificare, instradare e contribuire a correggere le segnalazioni a un ritmo che il suo processo precedente non aveva mai raggiunto.

Per gli utenti di Chrome, la risposta immediata resta ordinaria ma importante. Gli aggiornamenti automatici riducono l'esposizione solo dopo che il browser viene riavviato nella build corretta. Le organizzazioni gestite devono inoltre verificare che le loro policy di distribuzione non lascino gli endpoint indietro di diverse versioni.

Il record va interpretato soprattutto come una milestone produttiva per l'ingegneria della sicurezza assistita dall'IA. È la prova che la capacità di individuazione si è espansa. Che questa capacità produca software costantemente più sicuro dipende da tutto ciò che accade dopo che un modello segnala codice sospetto.

Una falla di 13 anni mostra cosa può trovare l'IA

L'argomento più forte a favore della sicurezza IA di Google Chrome non è il volume totale. È la capacità di riesaminare vecchi percorsi di codice che i test convenzionali non hanno rilevato.

CVE-2026-3545 illustra questo valore. Google ha classificato la vulnerabilità Chrome Navigation come ad alta gravità e l'ha corretta in Chrome 145.0.7632.159 e 145.0.7632.160, a seconda del sistema operativo.

La falla riguardava una convalida insufficiente dei dati. Un attaccante remoto avrebbe potuto potenzialmente usare HTML appositamente predisposto per uscire dalla sandbox del renderer, secondo il registro federale delle vulnerabilità.

Le notizie sull'indagine interna di Google affermano che il codice vulnerabile esisteva da circa 13 anni. Un harness di agenti IA che utilizzava Gemini avrebbe contribuito a identificare il percorso difettoso. I registri pubblici delle vulnerabilità confermano la falla, il suo impatto e la sua correzione, sebbene non documentino indipendentemente ogni dettaglio del processo di scoperta interno di Google.

Quell'età è più rivelatrice dell'etichetta di gravità. Il software maturo contiene assunzioni create con architetture, modelli di minaccia e pratiche di sviluppo più datati. I test scritti quando il codice è stato inizialmente distribuito potrebbero non esercitare mai combinazioni che in seguito diventano pericolose.

I ricercatori umani di sicurezza possono esaminare tali percorsi, ma il tempo impone dei limiti. Chrome comprende una vasta base di codice e circa 1.700 dipendenze di terze parti sulle piattaforme supportate. Gli ingegneri devono dare priorità allo sviluppo attivo, alle segnalazioni in arrivo, alle regressioni, agli aggiornamenti delle dipendenze e agli incidenti che stanno già colpendo gli utenti.

Gli agenti IA cambiano l'economia del riesame del vecchio codice. Possono ispezionare molti percorsi di esecuzione, formulare ipotesi su transizioni di stato non sicure e combinare il ragionamento con il fuzzing. Il fuzzing introduce input inattesi nel software per provocare crash o altri comportamenti anomali.

Questa combinazione aiuta a spiegare come l'IA di Google trovi bug che i vecchi scanner automatizzati non rilevavano. Uno strumento deterministico individua pattern specificati o fallimenti nei test. Un modello di ragionamento può dedurre che una sequenza di operazioni valide produca un risultato non sicuro, quindi chiedere a un altro sistema di riprodurlo.

Google afferma che Big Sleep, un agente sviluppato da Google DeepMind e Project Zero, opera ora come pipeline completamente automatizzata per mettere in sicurezza il motore JavaScript V8 di Chrome. V8 è un obiettivo particolarmente importante perché elabora il codice fornito dai siti web.

L'azienda ha anche descritto CodeMender, un agente sperimentale basato su Gemini pensato per creare correzioni per vulnerabilità critiche nel codice. Scoperta e riparazione sono compiti diversi, ma collegarli può ridurre il tempo tra una segnalazione confermata e una patch candidata.

Ciò non significa che l'IA abbia notato qualcosa che nessun essere umano potesse comprendere. Una volta identificata, la falla necessitava comunque di una spiegazione riproducibile, di una valutazione della gravità, di una modifica al codice, di test di regressione e di una release controllata.

Il suo contributo è stato la ricerca su vasta scala. Un agente poteva continuare a esaminare codice poco visibile senza sostenere lo stesso costo opportunità di uno specialista umano. Questo rende i percorsi vecchi e trascurati più accessibili dal punto di vista economico ai difensori.

La cronologia di 13 anni mette inoltre in discussione un'assunzione comune sui prodotti maturi. L'età non garantisce che un componente sensibile alla sicurezza sia stato esplorato completamente. Può invece significare che i bug più facili siano stati eliminati, mentre interazioni rare restano nascoste.

Il risultato di Google suggerisce che l'IA possa raggiungere quello strato residuo. Significa anche che gli attaccanti che usano modelli comparabili possono cercarvi a loro volta.

La scoperta non è più la parte più lenta

Il nuovo vantaggio di Google crea un nuovo collo di bottiglia: ogni segnalazione generata da una macchina compete ancora per una quantità finita di attenzione ingegneristica.

Ad aprile 2026, il team di sicurezza di Chrome ha avvertito gli ingegneri che i modelli IA stavano producendo un afflusso di bug di sicurezza generati internamente ed esternamente. Le sue linee guida sui bug IA pubblicate invitano i team a dare priorità ai problemi più gravi, trattando al contempo le segnalazioni IA con la stessa cautela nella divulgazione riservata alle segnalazioni umane.

Le linee guida stabiliscono aspettative impegnative per la correzione. I bug S0 più urgenti dovrebbero essere affrontati entro una settimana, mentre i problemi S1 dovrebbero essere risolti entro quattro settimane. Rispettare questi obiettivi diventa più difficile quando il volume delle segnalazioni cresce più rapidamente dell'organico.

Questa è la tensione centrale dietro il record. Trovare 1.072 bug è utile solo se l'organizzazione sa distinguere vulnerabilità reali da duplicati, assunzioni non valide, codice irraggiungibile e classificazioni di gravità errate.

Google sta automatizzando questo livello intermedio. Il suo aggiornamento trimestrale sulla sicurezza descrive un'infrastruttura isolata che riproduce le segnalazioni, le arricchisce, ne analizza la gravità e le instrada agli sviluppatori appropriati.

V8 ha inoltre aggiunto modalità di test che aiutano a distinguere i fallimenti nel codice sperimentale dai problemi di produzione. Google afferma che questi strumenti consentono agli agenti interni di convalidare le scoperte prima di segnalarle.

È così che l'IA di Google trova bug senza limitarsi a inondare gli ingegneri di sospetti generati dai modelli. Il modello formula o dà priorità a un'ipotesi, mentre i sistemi deterministici stabiliscono se il comportamento osservato possa essere riprodotto in condizioni controllate.

Neppure questa architettura può eliminare il giudizio umano. I confini di sicurezza sono in parte tecnici e in parte intenzionali. Un agente può identificare un movimento di dati che sembra non sicuro senza comprendere che un componente lo consente esplicitamente.

Le FAQ di Google incoraggiano i team ad aggiungere file SECURITY.md che descrivano i propri confini di sicurezza. Gli agenti possono leggere questi file e filtrare le segnalazioni in conflitto con il design previsto di un componente.

Questa pratica trasforma la conoscenza istituzionale in contesto leggibile dalle macchine. Rivela anche un limite: le prestazioni dell'IA dipendono dalla qualità delle regole, della documentazione, dei test e degli esempi che circondano il codice.

Un confine non documentato può produrre falsi positivi. Una relazione di fiducia definita male può generare vulnerabilità non rilevate. L'automazione amplifica la qualità dell'ambiente ingegneristico che riceve.

La gestione dei duplicati presenta un'altra sfida. I problemi di sicurezza restano spesso privati finché gli utenti non ricevono una correzione, quindi i normali responsabili dei componenti non possono vedere tutte le segnalazioni correlate. Un agente può riscoprire in modo indipendente una vulnerabilità già oggetto di indagine altrove.

Il team di Chrome invita gli sviluppatori a non effettuare ricerche ampie di duplicati, a meno che non dispongano dell'appropriato accesso alla sicurezza. Il triage centrale deve riconciliare tali segnalazioni senza esporre prematuramente dettagli sensibili.

Le prove di concetto creano una pressione analoga. Google afferma che oggi la maggior parte dei problemi generati dall’AI ne riceve una in seguito, ma alcune segnalazioni possono arrivare senza una dimostrazione completa. Gli ingegneri devono comunque trattare la segnalazione iniziale come una questione di sicurezza a tutti gli effetti.

Questa politica prudente protegge gli utenti, ma assorbe attenzione. Se la qualità delle segnalazioni diminuisce mentre il volume continua a crescere, i team potrebbero dedicare sempre più tempo a confutare le affermazioni dei modelli.

Il collo di bottiglia cambiato riguarda quindi più di Google. Le organizzazioni software che adottano strumenti AI per le vulnerabilità avranno bisogno di ambienti di riproduzione sicuri, confini espliciti tra i componenti, accesso controllato alle segnalazioni private e test di regressione affidabili.

Acquistare o distribuire un modello è la parte facile. Costruire il sistema attorno ad esso determina se la scoperta assistita dall’AI riduce il rischio o crea una costosa coda di lavoro.

Una difesa più rapida offre agli attaccanti strumenti più rapidi

Le stesse capacità di ragionamento che aiutano Google a ispezionare Chrome possono aiutare gli avversari a individuare e sfruttare debolezze in altro software.

Il lavoro di sicurezza di Google non avviene in un vuoto difensivo. I suoi ricercatori di threat intelligence affermano di aver identificato un attore criminale che utilizzava un exploit zero-day che ritengono sia stato sviluppato con l’AI. Secondo quanto riportato, il gruppo stava pianificando una campagna di sfruttamento più ampia prima che Google la interrompesse.

Le conclusioni della threat intelligence dell’azienda descrivono inoltre il crescente interesse di gruppi legati a Stati nella scoperta di vulnerabilità assistita dall’AI. Gli attaccanti usano i modelli per ricerca, sviluppo di exploit, modifica di malware e supporto operativo.

Questo crea una corsa misurata in base alle finestre di patch. Una finestra di patch è il periodo tra il momento in cui una vulnerabilità viene compresa e quello in cui ogni sistema interessato riceve protezione. L’AI può comprimere il lato della scoperta di questa cronologia sia per i difensori sia per gli attaccanti.

Per la sicurezza AI di Google Chrome, l’accesso interno crea diversi vantaggi difensivi. Google può esaminare il codice sorgente, eseguire test estesi, usare telemetria privata, consultare i responsabili dei componenti e preparare una patch prima della divulgazione pubblica.

Gli attaccanti non hanno bisogno degli stessi vantaggi. Chromium è open source e gli aggiornamenti del browser possono rivelare quali parti del codice sono cambiate. Un sistema capace può confrontare le versioni, identificare modifiche rilevanti per la sicurezza e contribuire a costruire un exploit contro gli utenti che non hanno effettuato l’aggiornamento.

Questo è uno dei motivi per cui Google limita l’accesso ai dettagli dei bug finché una larga parte degli utenti non ha ricevuto una correzione. La politica riduce le informazioni disponibili agli attaccanti durante la fase più pericolosa della distribuzione.

Rilasci più frequenti possono ridurre l’esposizione. Chrome distribuisce attualmente aggiornamenti di sicurezza settimanali insieme al suo calendario di milestone. A partire da Chrome 153, a settembre 2026, Google prevede di passare dalle milestone stabili a intervalli di quattro settimane a intervalli di due settimane.

Google afferma che la cadenza di due settimane produrrà rilasci più piccoli e semplificherà il debugging. Milestone più rapide possono distribuire prima il codice corretto, ma aumentano anche le esigenze di test per gli amministratori aziendali e le applicazioni dipendenti dal browser.

Il volume record di patch mette questo compromesso maggiormente a fuoco. Una finestra di patch più ridotta aiuta solo quando utenti, dispositivi gestiti e prodotti basati su Chromium adottano rapidamente l’aggiornamento.

Chrome non rappresenta l’intero mercato Chromium. Microsoft Edge, Brave, Opera, Vivaldi, browser incorporati e framework applicativi integrano Chromium secondo i propri calendari. Una correzione che entra nell’albero di Google non protegge istantaneamente ogni prodotto downstream.

Le aziende spesso aggiungono un ulteriore ritardo. Possono trattenere gli aggiornamenti del browser per controlli di compatibilità, utilizzare un canale Extended Stable o mantenere dispositivi che non vengono riavviati regolarmente. Queste pratiche possono lasciare in attesa una patch validata mentre lo sviluppo degli exploit avanza.

Le patch generate dall’AI introducono una loro incertezza. Una correzione candidata può eliminare il comportamento segnalato, ma creare una regressione, indebolire un altro confine o affrontare soltanto una manifestazione di un problema di progettazione più profondo.

Google non ha affermato che i modelli approvino e distribuiscano autonomamente tutte queste modifiche. Il suo flusso di lavoro documentato utilizza ancora una validazione deterministica e indirizza i problemi agli sviluppatori. Questa struttura controllata da esseri umani è una salvaguardia, non una fase obsoleta.

Il totale di 1.072 bug non dovrebbe quindi diventare un argomento per eliminare i revisori. Sostiene invece gli investimenti nell’automazione attorno ai revisori, inclusi riproduzione, classificazione, test, tracciamento delle dipendenze e gestione dei rilasci.

C’è un altro rischio nel celebrare soltanto il volume. I team di sicurezza potrebbero ottimizzare per il numero di problemi individuati perché è facile da comunicare. Gli attaccanti ottimizzano per sfruttabilità, portata, persistenza e accesso a sistemi di valore.

Una sottile evasione della sandbox può contare più di centinaia di difetti a basso impatto. Un programma di sicurezza AI maturo deve quindi dare priorità alle catene di attacco e ai percorsi di produzione esposti, non limitarsi a massimizzare il tasso di segnalazioni.

L’esperienza di Google offre prove incoraggianti del fatto che l’AI può migliorare la difesa. Il suo stesso lavoro di intelligence mostra anche perché qualsiasi vantaggio resterà conteso.

Cosa dovrebbero osservare ora gli utenti di Chrome e i team di sicurezza

Il prossimo test sarà stabilire se Google riuscirà a sostenere questo ritmo di scoperta preservando al contempo la qualità del triage, la stabilità delle patch e una rapida adozione.

Il primo segnale è la composizione delle future release di Chrome. Un altro totale elevato confermerebbe che l’impennata di giugno faceva parte di una pipeline duratura, anziché di una pulizia una tantum.

La distribuzione della gravità conta più del numero in prima pagina. I lettori dovrebbero osservare quanti problemi sono critici o ad alta gravità, quanti interessano codice distribuito e quanti ricevono identificatori CVE.

Le segnalazioni esterne continueranno a essere importanti. I ricercatori indipendenti possono verificare ipotesi che gli agenti interni ereditano dalla documentazione, dalla struttura del codice e dagli esempi di addestramento di Google. Un programma sano dovrebbe preservare questa pressione esterna anche mentre la scoperta interna si espande.

Google ha già adeguato il suo Vulnerability Reward Program per riflettere il crescente volume di segnalazioni assistite dall’AI. Afferma che i sistemi automatizzati ora aiutano a riprodurre e valutare le segnalazioni, mentre quelle non conformi vengono respinte più frequentemente.

Il cambiamento è comprensibile, ma richiede un attento monitoraggio. Un filtraggio rigoroso può controllare il volume di bassa qualità. Può anche scoraggiare segnalazioni non convenzionali che non rientrano in un modello automatizzato, ma identificano una reale violazione di un confine di sicurezza.

Il secondo segnale è la latenza di remediation. Gli obiettivi pubblicati da Google per i bug gravi forniscono un parametro di riferimento, ma le prestazioni aggregate mostreranno se la pipeline di revisione tiene il passo.

Un crescente arretrato privato indebolirebbe l’interpretazione ottimistica di questo evento di Google News. L’AI esporrebbe il rischio più rapidamente senza ridurre il tempo in cui gli utenti restano vulnerabili.

Un arretrato stabile o in diminuzione la rafforzerebbe. Questo risultato indicherebbe che riproduzione, classificazione e instradamento automatizzati scalano insieme alla scoperta.

La qualità dei rilasci fornisce una misura indiretta. Occorre osservare rollback d’emergenza, regressioni del browser, policy aziendali non funzionanti o patch successive che correggono soluzioni incomplete. Grandi volumi hanno valore solo se le modifiche resistono all’uso in produzione.

Il passaggio a un calendario di milestone di due settimane aumenterà la posta in gioco. Rilasci più piccoli possono rendere i difetti più facili da isolare, ma le aziende e i fornitori downstream di Chromium devono adattare i propri processi di test e distribuzione.

Il terzo segnale è la prova dell’uso da parte degli avversari. Google ha già riportato quello che ritiene sia stato uno sviluppo zero-day assistito dall’AI da parte di un attore criminale. Altri casi documentati confermerebbero che la corsa alla scoperta è passata dalle dimostrazioni di ricerca alle operazioni di routine.

Ciò aumenterebbe la pressione su tutti i principali fornitori di software, non solo sui produttori di browser. I fornitori dovrebbero presumere che gli attaccanti possano riesaminare vecchio codice con agenti economici e persistenti.

Gli sviluppatori dovrebbero rispondere migliorando l’ambiente attorno al proprio codice. Confini di sicurezza chiari, build riproducibili, test solidi, componenti memory-safe e aggiornamenti tempestivi delle dipendenze rendono più efficace sia la revisione umana sia quella AI.

I responsabili della sicurezza dovrebbero inoltre separare le metriche di scoperta da quelle di risultato. Le misure utili includono il tempo di convalida, il tempo di remediation, l’adozione delle patch, i problemi riaperti, le regressioni sfuggite e le vulnerabilità individuate durante lo sfruttamento attivo.

Per i singoli utenti, la lezione è meno complicata. Mantenete aggiornato Chrome o un altro browser basato su Chromium, riavviatelo quando un aggiornamento è pronto e verificate la versione installata dopo importanti avvisi di sicurezza.

Gli aggiornamenti automatici sono un meccanismo di distribuzione, non la prova che una patch sia attiva. Un browser in attesa di riavvio può rimanere su codice vulnerabile.

Le organizzazioni dovrebbero inventariare le applicazioni che integrano Chromium anziché presumere che la distribuzione desktop di Chrome copra ogni istanza. Runtime incorporati e browser secondari possono seguire canali di aggiornamento diversi.

Il significato più ampio va oltre i browser. L’AI può ora analizzare software maturi abbastanza in profondità da far emergere sia grandi gruppi di difetti ordinari sia rari problemi nascosti per oltre un decennio.

Questa capacità favorisce i difensori quando è collegata a un’ingegneria disciplinata e a una distribuzione rapida. Favorisce gli attaccanti quando le organizzazioni lasciano il vecchio codice non documentato, non testato o lento da aggiornare.

La domanda decisiva non è più se l’AI possa trovare vulnerabilità significative. I risultati di Google forniscono prove sostanziali che può farlo.

La domanda è se le organizzazioni di sicurezza possano trasformare la scoperta alla velocità delle macchine in correzioni affidabili per gli esseri umani prima che gli avversari usino la stessa capacità. Osservate le prossime release di Chrome, la qualità della loro remediation e l’effettiva adozione degli aggiornamenti. Questi segnali riveleranno se questa milestone di Google News segna un vantaggio di sicurezza duraturo o l’inizio di una corsa molto più rapida.