Chrome: oltre 200 bug interni in 3 mesi, AI sposta l'equilibrio

Chrome: oltre 200 bug interni in 3 mesi, AI sposta l'equilibrio

Google ha segnalato oltre 200 vulnerabilità interne nelle release di Chrome tra marzo e maggio 2026, con un'accelerazione verticale da aprile in poi: 16 bug il 15 aprile, 21 il 28 aprile, 100 il 5 maggio, oltre 70 nelle due release successive. L'impennata quantitativa coincide con la dichiarata adozione di strumenti AI e automazione per la ricerca di flaw, anche se l'azienda non ha confermato esplicitamente che queste specifiche vulnerabilità siano state trovate tramite intelligenza artificiale. La novità solleva un interrogativo concreto: se l'AI rende la scoperta interna più efficiente, la ricerca indipendente rischia di essere marginalizzata.

La curva esponenziale dei bug "made in Google"

Le Chrome security advisories raccontano una storia numerica netta. A fine marzo e inizio aprile 2026, le vulnerabilità segnalate internamente da Google erano poche, nella norma storica del browser. Il 15 aprile il contatore è saltato a 16. Il 28 aprile a 21. Il 5 maggio ha segnato un record: 100 vulnerabilità in un singolo advisory, tutte attribuite alla ricerca interna. Nelle due release immediatemente successive, il flusso si è mantenuto sopra le 70 unità.

Il totale supera le 200 segnalazioni interne in meno di tre mesi. Per contesto, non è noto se questo volume rappresenti un multiplo rispetto al trimestre precedente — le fonti disponibili non forniscono dati comparabili — ma la concentrazione temporale è inequivocabile. Quel che cambia non è solo la quantità: è la provenienza. Questi non sono bug segnalati da ricercatori esterni attraverso il Vulnerability Reward Program. Sono tutti "reported by Google".

AI e automazione: cosa Google dice, e cosa tace

L'azienda ha reso pubblica una linea di posizione coerente. In materia di bug bounty, Google ha dichiarato che "AI and automation have been helping its teams move at an unprecedented rate – remediating risks more effectively than ever before". Più specificamente, ha riconosciuto che i progressi in AI rendono "significantly easier to take a test case and explain the root cause, propose a suitable fix, and to find variants of known problems".

Le due citazioni — riportate da SecurityWeek — descrivono un cambiamento di metodo, non solo di volume. L'AI viene impiegata per accelerare la comprensione del problema, generare la patch e mappare varianti dello stesso pattern. È un workflow di vulnerability research automatizzato, non solo fuzzing casuale. Tuttavia, Google non ha risposto alle domande specifiche di SecurityWeek: quante di queste 200+ vulnerabilità sono state scoperte da AI, e quale modello o tool è stato utilizzato.

Questo silenzio operativo è significativo. Senza la distinzione tra scoperta umana e scoperta automatizzata, il dato "reported by Google" diventa una scatola nera: sappiamo che il throughput è cresciuto, non sappiamo la composizione del fattore di crescita.

"The latest advancements in AI from Google and the broader industry have made it significantly easier to take a test case and explain the root cause, propose a suitable fix, and to find variants of known problems" — Google, citato da SecurityWeek

Il taglio dei bounty e la ridefinizione del mercato

La decisione di Google di ridurre i bug bounty non è isolata dall'accelerazione interna. L'azienda ha esplicitamente collegato i due fenomeni: l'efficienza AI giustifica una riallocazione delle risorse, con meno premio per le scoperte esterne. Il ragionamento è lineare — se troviamo e correggiamo più velocemente da soli, perché pagare premium a terzi — ma le conseguenze di mercato sono meno intuitive.

Per le imprese che usano Chrome in deployment enterprise, il trade-off appare favorevole: più patch, più rapide, meno dipendenza da ricercatori indipendenti che possano vendere informazioni sul mercato grigio. Per la community di security research, invece, il segnale è di contrazione. Il bug bounty non è solo compensazione: è un meccanismo di allineamento degli incentivi che lega la scoperta di vulnerabilità alla divulgazione responsabile. Riducendolo, Google scommette che la sua pipeline interna possa sostituire quella esterna senza perdere coverage.

Non è noto se questa scommessa sarà vincente. L'evidence disponibile non dice se l'AI scopra classi di bug diverse da quelle tipiche della ricerca umana, né se esistano vulnerabilità che i tool interni non vedono e che un ricercatore indipendente troverebbe. È un cambiamento di paradigma con evidenza incompleta.

Cosa fare adesso

1. Monitorare le Chrome release note con attenzione alla provenienza: distinguere "reported by Google" da "reported by [esterno]" aiuta a valutare la diversità del pipeline di scoperta e il rischio di coverage ridotta.
2. Rivedere le policy di patching enterprise: con volumi così elevati, la frequenza degli update Chrome diventa critica; verificare che gli strumenti di gestione endpoint supportino il ciclo stabile di Chrome.
3. Valutare la resilienza del proprio programma bug bounty: se le big tech contraggono i reward, le aziende con programmi propri devono calibrare le offerte per non perdere visibilità nella community indipendente.
4. Esigere trasparenza sui tool AI per la security: richiedere ai vendor di codice — browser, cloud, OS — disclosure sulle tecniche di analisi automatizzata usate in fase di sviluppo, per valutare qualità e bias del testing.

Il dilemma che l'ondata Chrome non risolve

La storia tecnica è chiara: più bug trovati, più bug patchati, più velocemente. La storia politica è più complessa. Google sta trasferendo un'attività — la vulnerability research — da un ecosistema distribuito a una competenza centralizzata, AI-augmented. Non è la prima big tech a farlo, ma i numeri di Chrome rendono il fenomeno visibile a scala.

Il rischio sistemico non è nell'efficienza, ma nella verificabilità. Quando una vulnerabilità è trovata da un ricercatore indipendente, esiste un percorso pubblico: segnalazione, bounty, advisory, CVE. Quando è trovata internamente da un tool proprietario, quel percorso si accorcia o scompare. Non sappiamo quali classi di bug l'AI privilegi, quali trascuri, se i suoi pattern di scoperta siano replicabili o verificabili da terzi. La security del codice dipendente da modelli closed-source e training data opachi introduce una forma di debito tecnico nuova: la fiducia non si fonda più sulla trasparenza del processo, ma sulla reputazione del vendor.

Per il settore, la domanda non è se l'AI trovi più bug dell'uomo. È se un ecosistema di security trasparente e distribuito sia preferibile a uno efficiente ma opaco — anche quando l'opacità veste i colori di Google.

FAQ

Google ha confermato che le 200+ vulnerabilità sono state trovate con AI?

No. Google ha collegato pubblicamente AI e automazione all'accelerazione generale della remediation, ma non ha risposto alle richieste di SecurityWeek sul numero esatto di vulnerabilità scoperte da AI né sul tool o modello specifico utilizzato per queste segnalazioni. La correlazione è inferenziale.

Perché la provenienza "reported by Google" è rilevante rispetto a una segnalazione esterna?

Le segnalazioni esterne attraversano un processo di verifica pubblico — bug bounty, CVE, advisory dettagliata — che rende la vulnerabilità tracciabile e il metodo di scoperta valutabile dalla community. Le segnalazioni interne mancano di questo passaggio, riducendo la verificabilità indipendente anche quando il volume aumenta.

I tagli ai bug bounty di Google sono già effettivi?

Google ha annunciato la riduzione dei bounty citando l'efficienza di AI e automazione. L'articolo non specifica se i nuovi importi siano già attivi o in fase di transizione, né fornisce i valori esatti delle revisioni.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.securityweek.com/googles-surge-in-chrome-vulnerability-discoveries-likely-driven-by-ai/