Google afferma che un agente di intelligenza artificiale sviluppato internamente ha individuato oltre 500 vulnerabilità di cross-site scripting nelle applicazioni web proprietarie dell’azienda.
Il sistema, chiamato PageBreak, combina ipotesi di vulnerabilità generate dall’IA con validator separati, che tentano di eseguire payload sulle applicazioni in funzione. Google presenta questa fase di convalida come il meccanismo che impedisce di scambiare un risultato plausibile dell’IA per una vulnerabilità sfruttabile.
Il totale dichiarato è considerevole, ma va interpretato con cautela. Si riferisce ai risultati individuati, non agli utenti coinvolti, e le informazioni disponibili non dimostrano che tutte le vulnerabilità segnalate siano state corrette. Inoltre, non vengono forniti identificativi CVE, punteggi CVSS, prove di sfruttamento da parte di malintenzionati o conferme di impatti sui clienti di Google.
PageBreak è passato da progetto pilota a prodotto interno
PageBreak è stato sviluppato dal team Product Security di Google per analizzare le applicazioni web e le estensioni del browser dell’azienda. L’ingegnere della sicurezza informatica Michał Bentkowski ha dichiarato che il sistema ha individuato oltre 500 vulnerabilità XSS.
Secondo il resoconto che descrive PageBreak e i suoi risultati, il progetto è iniziato come sperimentazione lo scorso novembre ed è diventato un prodotto a gennaio. La fonte non specifica gli anni di queste due tappe. Google ha parlato del sistema in un post sul blog aziendale il mese scorso.
Questi riferimenti indicano le tappe dello sviluppo e della divulgazione, non le date in cui le singole vulnerabilità sono state introdotte, scoperte o corrette. Non c’è inoltre una data univoca dell’incidente, perché PageBreak è un sistema di test di sicurezza, non una violazione segnalata.
Tra gli esempi resi pubblici da Google figurano tre risultati distinti:
- Una vulnerabilità di cache poisoning che interessava
apis.google.com - Una vulnerabilità XSS in
admin.google.com - Handshake esterni non sicuri che coinvolgevano estensioni del browser
Secondo quanto riportato, nel post di accompagnamento Google ha dichiarato che quei tre problemi erano stati risolti. Questa affermazione non chiarisce lo stato delle correzioni per l’intera raccolta, comprese le oltre 500 vulnerabilità XSS attribuite a PageBreak.
Il resoconto non identifica organizzazioni esterne interessate dalle vulnerabilità. L’ambito dei test dichiarato comprende i servizi proprietari di Google e le estensioni del browser.
L’IA individua possibili vulnerabilità, ma la verifica è affidata a codice separato
L’architettura di PageBreak mira a superare un limite ricorrente dei test di sicurezza assistiti dall’IA: un modello può fornire una spiegazione tecnicamente convincente senza individuare una vulnerabilità realmente sfruttabile.
Secondo la procedura descritta da Bentkowski, l’agente esamina innanzitutto un’applicazione e formula un’ipotesi di vulnerabilità. La sottopone poi a un validator specializzato, che tenta di eseguire un payload reale sull’applicazione in un ambiente attivo. PageBreak segnala il problema solo dopo che il test ne ha dimostrato l’esistenza.
Secondo la descrizione, i validator non sono scritti dall’IA. La loro logica e le loro interfacce variano in base alla categoria di vulnerabilità e alla superficie dell’applicazione sottoposta a test.
Per esempio, XSS, SQL injection e remote code execution richiedono metodi di convalida diversi. Anche testare un’applicazione HTTP comporta un’interfaccia diversa rispetto all’analisi di un servizio gRPC. PageBreak non si affida quindi a un unico prompt o a una procedura di convalida universale per ogni obiettivo.
Questa distinzione è importante perché il componente di IA non ha l’ultima parola sui risultati. Genera possibili vulnerabilità, mentre un altro meccanismo deve produrre prove di esecuzione.
Google descrive il sistema come una combinazione di individuazione autonoma e convalida deterministica. Bentkowski ha definito il tasso di falsi positivi «quasi nullo». Si tratta però di una dichiarazione dell’azienda: il resoconto disponibile non include test indipendenti sull’accuratezza di PageBreak, sul suo tasso di falsi positivi o sulla copertura dei test.
I modelli Gemini guidano l’individuazione, non la verifica finale
PageBreak usa principalmente Gemini 3.1 Pro e Gemini 3.5 Flash, anche se Google afferma che il sistema può funzionare con altri modelli.
La distinzione tra modelli e validator è centrale per il progetto. Gemini viene impiegato nella fase di individuazione, in cui l’accesso al codice sorgente e agli strumenti di sicurezza può aiutare l’agente a elaborare possibili percorsi d’attacco. Il validator non basato sull’IA stabilisce poi se sia possibile dimostrare la vulnerabilità sul sistema in funzione.
Bentkowski ha affermato che l’IA può individuare vulnerabilità più rapidamente dei ricercatori umani. Ha anche riconosciuto il costo operativo del distinguere le debolezze reali dalle allucinazioni apparentemente credibili. Senza una convalida efficace, accelerare l’individuazione rischia semplicemente di trasferire il lavoro ai team di sicurezza dei prodotti e di ingegneria.
Le informazioni disponibili non riportano benchmark comparativi con ricercatori umani o altri scanner automatizzati. Inoltre, non forniscono prove indipendenti delle prestazioni dei due modelli Gemini citati in questo contesto.
Esperti esterni sostengono la distinzione tra individuazione e verifica
Rickard Carlsson, CEO di Detectify, ha descritto un problema più ampio che interessa i team di sicurezza: gli strumenti di IA possono generare più sospette vulnerabilità di quante le persone riescano realisticamente a esaminare.
Secondo Carlsson, un agente non dovrebbe verificare le proprie conclusioni. A suo parere, prima di accettare un risultato proposto, un validator separato dovrebbe eseguire un payload reale sull’applicazione in funzione. Questa posizione è in linea con la distinzione attribuita a PageBreak tra individuazione affidata all’IA e convalida non basata sull’IA.
Darin Fredde, senior director of technical marketing engineering di Ridge Security, ha inquadrato questo approccio nella transizione verso test offensivi continui, autonomi e basati su prove. Ha osservato che la sola individuazione non basta: il processo dovrebbe proseguire con la verifica della vulnerabilità, la correzione e il controllo che la soluzione funzioni.
Si tratta di valutazioni del settore, non di conferme indipendenti delle prestazioni di PageBreak. Nessuna delle due chiarisce quanto a fondo l’agente abbia esaminato le applicazioni di Google, quante vulnerabilità possa essersi lasciato sfuggire o se tutti i risultati convalidati siano stati poi corretti.
La correzione automatizzata è ancora un progetto futuro
Google intende integrare PageBreak con CodeMender, il sistema dell’azienda per la correzione automatizzata delle vulnerabilità. Nel flusso di lavoro previsto, PageBreak convaliderebbe una vulnerabilità e CodeMender genererebbe una possibile modifica al codice. Gli ingegneri di prodotto esaminerebbero poi la correzione proposta, la convaliderebbero e la applicherebbero.
L’integrazione è presentata come un progetto futuro, non come un processo di correzione già operativo. Di conseguenza, le oltre 500 vulnerabilità individuate non vanno interpretate come oltre 500 vulnerabilità corrette automaticamente.
Per i team di prodotto di Google, PageBreak potrebbe ridurre il tempo dedicato a riprodurre manualmente i risultati generati dall’IA. Un payload eseguito con successo offre agli ingegneri prove più solide del fatto che una sospetta vulnerabilità meriti attenzione. Da solo, però, non ne determina la gravità o l’impatto sugli utenti, né garantisce che un’eventuale correzione successiva sia valida.
Per gli utenti e gli amministratori esterni, il resoconto non fornisce istruzioni per applicare patch a prodotti specifici, indicatori di compromissione o soluzioni alternative. Non presenta nemmeno prove che gli aggressori abbiano sfruttato le vulnerabilità individuate. La responsabilità immediata di intervenire ricade quindi su Google e sui team che gestiscono i servizi e le estensioni testati.
Stando a quanto riferito da Google, PageBreak illustra un modello specifico di test interni: lasciare che un agente di IA cerchi su vasta scala, ma richiedere una prova eseguibile e indipendente prima di sottoporre un risultato agli ingegneri. Non è stato dimostrato in modo indipendente se questa architettura mantenga su larga scala il basso tasso di falsi positivi dichiarato dall’azienda.
