La sicurezza informatica continua a mutare le sue fondamenta e, in buona parte dei casi, lo fa perché i modelli linguistici di grandi dimensioni hanno aperto possibilità fino a poco tempo fa impensabili nella scoperta di vulnerabilità, superando ormai i limiti tradizionali della sola competenza umana.
Google, attraverso il team di sicurezza di Chrome, ha deciso di cavalcare questa onda impiegando l’IA su larga scala per individuare e correggere centinaia di falle nei software, con l’obiettivo dichiarato di rendere il browser più resiliente e la copertura dei bug più completa. Per farlo, ha condiviso un lungo approfondimento sul proprio blog, da cui abbiamo deciso di trarre i passaggi principali.
Segui TuttoAndroid su Google Discover
Il ciclo di vita di un bug
Per prima cosa, ricordiamo che non tutti i difetti di un software sono uguali. Un bug puramente funzionale può causare al massimo un blocco irritante dell’interfaccia, mentre una falla di sicurezza può diventare la base per un vero e proprio attacco informatico, permettendo a un malintenzionato di leggere dati privati o di prendere il controllo di un dispositivo senza che l’utente se ne accorga.
Ogni vulnerabilità, una volta entrata nel codice, segue un percorso preciso: viene individuata, viene classificata, viene corretta, la correzione viene distribuita agli utenti tramite un aggiornamento e infine il browser va riavviato perché la patch diventi effettiva. Per quanto intuibile, la società di Mountain View segnala che il team di Chrome lavora per comprimere al massimo i tempi di ciascuna di queste fasi.
Segui Google su Telegram, ricevi news e offerte per primo
La caccia alle vulnerabilità diventa automatica
L’uso dell’intelligenza artificiale da parte del team di sicurezza di Chrome non è, evidentemente, una novità dell’ultima ora. Già nel 2023 erano stati sviluppati sistemi per potenziare il fuzzing, la tecnica che genera input casuali per stanare i bug. Nel 2024 è arrivata la collaborazione con Project Zero sul progetto Naptime, pensato per dotare i modelli linguistici di strumenti specifici per la ricerca di vulnerabilità. Nel 2025 è stata la volta di Big Sleep, sviluppato insieme a DeepMind e Project Zero, un agente IA che ha scovato falle reali nel motore JavaScript V8 e nello stack grafico di Chrome.
Nei primi mesi del 2026 il team ha fatto un passo avanti costruendo un’infrastruttura basata su Gemini capace di setacciare l’intero codice sorgente di Chrome con maggiore efficienza e meno falsi allarmi. Tra le scoperte più significative c’è già stato un bug che consentiva a un renderer compromesso di ingannare il browser inducendolo a leggere file locali. Un bug che, incredibilmente, si nascondeva nel codice da oltre tredici anni. Per molti nel team questo episodio ha rappresentato la prova definitiva del potenziale di questi strumenti.
Da quel momento il sistema è stato affinato in più direzioni. Ad esempio, è stata introdotta l’interoperabilità tra modelli proprietari e a peso aperto, per sfruttare i punti di forza di ciascuno. È inoltre stata costruita una base di conoscenza che include tutte le vulnerabilità già catalogate e l’intera cronologia Git del progetto, in modo da estendere il ragionamento dei modelli oltre i confini dei loro dati di addestramento.
Ancora, è stato chiesto agli sviluppatori di documentare i limiti della fiducia del codice tramite appositi file descrittivi, così che i modelli possano farsi un’idea più precisa delle minacce. È stato aggiunto un agente “critico”, con un contesto separato, incaricato di leggere proprio questi file e, infine, per tenere conto della natura non deterministica dei modelli e dei loro continui miglioramenti, le scansioni sono state ripetute più volte nel tempo.
Naturalmente, tutto questo è stato costruito ponendo grande attenzione alla sicurezza del processo stesso. I modelli analizzano il codice sorgente esclusivamente in stato di quiete, su macchine isolate e prive di accesso generale a Internet. Le richieste di rete vengono intercettate da un sistema dedicato che applica liste di autorizzazione rigide in base all’applicazione di origine e alla destinazione, bloccando ogni comportamento sospetto. I modelli non vengono mai fatti girare in modalità libera e non possono modificare il sistema locale né accedere a file al di fuori delle cartelle di codice designate.
Classificare i bug più in fretta
Una volta scoperte, le vulnerabilità devono essere validate e assegnate a chi se ne occuperà. In passato questo lavoro di triage richiedeva da cinque a trenta minuti o più per ogni singola segnalazione, ed era affidato quasi interamente al giudizio umano. Oggi il processo si è spostato verso un sistema ibrido che combina regole automatiche e intelligenza artificiale, suddiviso in quattro fasi.
Prima di tutto, il sistema filtra il rumore di fondo, verificando che una segnalazione non sia spam, che non sia un duplicato e che descriva effettivamente una vulnerabilità di sicurezza di Chrome. Successivamente cerca di riprodurre il bug, testandolo sulle versioni di sistema operativo e browser coinvolte e allegando dettagli tecnici, come le tracce di stack, utili a orientare la correzione.
In una terza fase il sistema arricchisce la segnalazione con metadati come la data di introduzione del difetto e il livello di gravità, calcolato grazie a linee guida rese più chiare proprio per facilitarne l’applicazione automatica; gli sviluppatori restano comunque liberi di correggere la valutazione se la ritengono sbagliata. Infine il sistema assegna automaticamente il problema al componente e alla persona giusti. Sebbene sia difficile misurarlo con precisione, il team stima che questo nuovo flusso di lavoro faccia risparmiare centinaia di ore di lavoro degli sviluppatori ogni mese.
Correggere più vulnerabilità, più in fretta
La responsabilità di correggere le falle è condivisa tra gli sviluppatori dei vari team e la squadra di sicurezza centrale, ma per stare al passo con il ritmo delle scoperte serve un processo di correzione altrettanto scalabile. Per questo Chrome si affida a flussi di lavoro basati su più agenti che collaborano tra loro.
Dopo una fase iniziale che raccoglie il contesto specifico di un problema, un agente propone diverse possibili correzioni; un secondo agente, con funzione critica, valuta quale sia la più adatta e produce materiale utile agli sviluppatori umani per la revisione; i due agenti lavorano poi in un ciclo che imita una tipica revisione del codice, assicurandosi che la soluzione funzioni e rispetti le convenzioni di stile del progetto; infine agenti dedicati alla scrittura dei test verificano che le correzioni funzionino su tutte le piattaforme supportate da Chrome, prima ancora che uno sviluppatore le esamini, risparmiando potenzialmente settimane di lavoro.
Il risultato è stato un’impennata nel numero di correzioni di sicurezza rilasciate. Nelle ultime due versioni principali di Chrome, la 149 e la 150, sono stati corretti 1.072 bug di sicurezza, un numero superiore alla somma di quelli sistemati nelle ventitré versioni precedenti messe insieme. La collaborazione pluriennale con Google DeepMind e Project Zero, che comprende progetti come Big Sleep e CodeMender, è ormai aggiunta direttamente nei sistemi di integrazione continua di Chrome, con controlli automatici ogni ventiquattro ore su tutte le modifiche proposte.
La corsa contro il tempo per la distribuzione delle patch
Una volta che una correzione è visibile nel codice open source pubblico, gli aggressori possono iniziare ad analizzarla per sfruttare la falla prima ancora che l’aggiornamento raggiunga i dispositivi degli utenti con i cosiddetti attacchi N-day. Poiché normalmente passano settimane prima che una modifica passi dal ramo di sviluppo principale al canale stabile usato dalla maggioranza degli utenti, ridurre questo divario è una priorità.
A seconda della gravità, le correzioni vengono ora integrate direttamente nel ramo stabile in uso, che viene monitorato costantemente per evitare nuovi problemi. Chrome sta passando a un ciclo di rilascio delle versioni principali ogni due settimane, con aggiornamenti di sicurezza settimanali, ma di fronte alla velocità degli attacchi basati sull’IA il team sta sperimentando addirittura due rilasci di sicurezza a settimana.
Nonostante questa accelerazione, la trasparenza resta un principio fermo e ogni bug di sicurezza che raggiunge il canale stabile, sia esso scoperto internamente o segnalato dall’esterno, viene documentato e reso pubblico. È in corso anche un lavoro per automatizzare la generazione delle note di rilascio e delle descrizioni ufficiali delle vulnerabilità, così da eliminare colli di bottiglia manuali.
Convincere gli utenti a riavviare il browser
Chrome fu tra i primi, nel 2008, a introdurre gli aggiornamenti automatici in background, applicati al riavvio successivo del browser. Ma se l’intero processo di scoperta, correzione, test e rilascio richiede oggi appena uno o due giorni, il tempo che un utente impiega prima di riavviare effettivamente Chrome resta uno dei fattori di rischio più rilevanti per l’esposizione ad attacchi N-day.
Rimandare un riavvio è un comportamento comprensibile, visto e considerato che interrompe il lavoro, richiede di trovare un momento adatto e raramente è la priorità del momento. Per questo il team sta cercando di togliere questo peso dalle spalle degli utenti attraverso diverse strade. Una è la cosiddetta patch dinamica, che punta a eliminare la necessità di un riavvio completo nella maggior parte dei casi, sostituendo progressivamente, grazie all’architettura multiprocesso di Chrome, i processi secondari come quelli dedicati alla grafica con versioni aggiornate, senza interrompere la sessione.
Un’altra riguarda il salvataggio più esteso dello stato locale, per garantire un ripristino della sessione impeccabile anche in situazioni complesse. Una terza strada consiste nell’individuare i momenti più opportuni per un riavvio automatico: su macOS, ad esempio, dove le applicazioni continuano spesso a girare in background anche quando tutte le finestre sono chiuse, Chrome 150 ha introdotto un riavvio automatico quando il browser si trova proprio in questo stato “senza finestre” e ha un aggiornamento in sospeso.
Prevenire è meglio che correggere
Oltre a intervenire sui singoli bug, Chrome sta investendo per eliminare intere categorie di vulnerabilità alla radice, prima ancora che possano manifestarsi. I progressi dell’IA applicata alla scrittura del codice stanno rendendo possibili interventi che in passato avrebbero richiesto anni, o che semplicemente non sarebbero mai stati avviati.
La strategia sulla sicurezza della memoria si muove ad esempio su due binari paralleli: da un lato rafforzare l’ambiente di esecuzione per neutralizzare le vulnerabilità legate al linguaggio C++ ancora presente nella stragrande maggioranza del codice, dall’altro migrare progressivamente verso linguaggi intrinsecamente più sicuri come Rust. Sul fronte C++, il lavoro si concentra su tre direttrici:
- l’espansione della tecnologia MiraclePtr, già responsabile di una forte riduzione dei bug di tipo “use-after-free”, verso nuove librerie grafiche e strutture dati, con l’obiettivo di neutralizzare fino al 90% di queste vulnerabilità nel thread principale della GPU;
- la cosiddetta “spanification”, cioè la sostituzione sistematica dei vecchi costrutti basati su puntatori e dimensioni con tipi verificati dal compilatore, un lavoro che oggi copre già il 97% del codice proprietario di Chrome e che si sta estendendo anche a librerie di base come quelle grafiche;
- un irrigidimento strutturale che comprende controlli matematici per prevenire overflow numerici e una segmentazione più rigorosa della memoria heap per rendere più difficile sfruttare i bug residui.
Pur riconoscendo l’utilità immediata di queste protezioni, il team è consapevole che i controlli a runtime, più costosi in termini di prestazioni rispetto alle garanzie verificate in fase di compilazione, avranno presto rendimenti decrescenti. Per questo la soluzione di lungo periodo passa dalla migrazione verso Rust, attraverso tre pilastri:
- la costruzione di un kit di sviluppo centralizzato che renda Rust una scelta naturale e poco fastidiosa per i nuovi componenti;
- la sostituzione mirata del codice storicamente più soggetto a bug, come i parser di dati complessi, i codec di immagine e i motori dei font;
- la possibilità di scrivere componenti modulari ad alto privilegio direttamente in Rust, eseguibili in sicurezza anche all’interno di processi delicati come quello del browser stesso, senza le penalità prestazionali imposte dal tradizionale isolamento in sandbox.
Il team sta inoltre valutando di riscrivere l’interfaccia utente di alto livello del browser utilizzando HTML, CSS e TypeScript, riducendo ulteriormente la dipendenza dal C++ tradizionale.
Fermare i bug prima che entrino nel codice
Data la velocità di sviluppo di Chrome, una scansione periodica dell’intero codice non basta più. Per questo motivo sistemi di intelligenza artificiale sono stati integrati direttamente nei processi di integrazione continua e nella coda di commit, analizzando ogni modifica proposta nel momento stesso in cui viene sottoposta, suggerendo correzioni di spanification, segnalando puntatori pericolosi e imponendo controlli di sicurezza numerica.
Un problema particolarmente insidioso in progetti software di grandi dimensioni è ad esempio quello delle vulnerabilità latenti. Ovvero, un codice che appare sicuro se considerato isolatamente, ma che una modifica apparentemente marginale e non collegata, effettuata altrove nel progetto, può trasformare in una falla critica.
Grazie a un’analisi semantica continua basata su modelli linguistici all’interno della coda di commit, Chrome riesce oggi a intercettare questi rischi composti prima che vengano integrati nel codice, cogliendo interazioni sottili che l’analisi statica tradizionale non sarebbe in grado di individuare.