Google ha messo in pausa una parte del suo programma di bug bounty open source, e il motivo racconta bene uno dei limiti più concreti dell’AI applicata alla sicurezza: produrre segnalazioni è diventato molto più veloce, ma capire quali siano realmente utili continua a richiedere tempo umano.
Dal 1 ottobre 2026 l’Open Source Software Vulnerability Reward Program di Google, noto come OSS VRP, non accetta temporaneamente nuove segnalazioni relative alle vulnerabilità di prodotto. Restano invece aperti i report sulla supply chain e continuano a essere gestite le segnalazioni già inviate. Google ha indicato il primo trimestre del 2027 come finestra per un nuovo aggiornamento sul programma.
Perché Google ha fermato una parte dell’OSS VRP
La decisione non arriva all’improvviso. Già a marzo Google aveva spiegato sul blog ufficiale di Google Bug Hunters di aver registrato un forte aumento di segnalazioni di bassa qualità e non valide. Tra queste comparivano anche report generati con strumenti di intelligenza artificiale che contenevano informazioni scorrette o ipotesi non confermate.
Il problema non è usare l’AI come supporto alla ricerca. Google stessa riconosce che questi strumenti possono aiutare ad analizzare grandi quantità di codice. Il punto critico nasce quando un risultato automatico viene inviato senza un controllo adeguato, trasferendo il lavoro di verifica ai maintainer.
Cosa è stato sospeso dal 1 ottobre
Secondo l’annuncio di Google riportato il 3 ottobre da Tom’s Hardware, la pausa riguarda le nuove segnalazioni di vulnerabilità di prodotto nell’OSS VRP.
- Nuove segnalazioni di vulnerabilità di prodotto: temporaneamente sospese.
- Report già inviati: continuano a essere gestiti.
- Segnalazioni supply chain: restano aperte.
- Altri programmi Google VRP: restano disponibili quando il caso rientra nel loro perimetro.
- Prossimo aggiornamento: previsto entro il primo trimestre del 2027.
Non si tratta quindi della chiusura completa della bug bounty open source di Google. È una sospensione mirata mentre l’azienda riorganizza il flusso di ingresso di una categoria di report.
L’AI crea un nuovo problema di scala
I falsi positivi non sono una novità nella sicurezza informatica. La differenza è la scala. Un sistema automatico può esaminare molti progetti in poco tempo e produrre numerose segnalazioni apparentemente credibili. Se però una parte rilevante di quei risultati non è stata validata, il risparmio ottenuto a monte diventa lavoro aggiuntivo a valle.
Ogni segnalazione deve infatti essere letta, confrontata con il comportamento reale del software e classificata. Quando il volume cresce più rapidamente della capacità di verifica, anche un buon programma può diventare difficile da gestire.
È un tema vicino a quello che abbiamo affrontato parlando di agenti AI e repository GitHub: più autonomia e più contesto possono aumentare la produttività, ma richiedono anche controlli più forti sul modo in cui vengono interpretati i risultati.
Google aveva già irrigidito le regole
Nel corso del 2026 Google aveva già aumentato i requisiti per alcune classi di segnalazioni. L’obiettivo dichiarato era ridurre il rumore e concentrare il tempo dei team di sicurezza sui problemi con un impatto concreto e dimostrabile.
Nel suo aggiornamento di marzo, Google sottolineava che l’AI può velocizzare la ricerca, ma che i risultati devono essere validati prima dell’invio. L’azienda citava esplicitamente report con informazioni errate e casi in cui veniva segnalato un problema nel codice senza dimostrare una conseguenza di sicurezza reale.
Non è una bocciatura dell’AI nella cybersecurity
La sospensione non significa che l’intelligenza artificiale non sia utile nella sicurezza. Può aiutare a orientarsi in progetti complessi, evidenziare anomalie, riassumere grandi quantità di codice e accelerare molte attività di analisi.
Il problema è confondere un’ipotesi con un risultato verificato. In un programma di bug bounty il valore non sta nel numero di segnalazioni prodotte, ma nella loro qualità. Una sola segnalazione chiara, riproducibile e ben documentata vale più di decine di report automatici che richiedono ore di controllo.
Il costo nascosto dell’automazione
La storia dell’OSS VRP mostra un paradosso: l’automazione riduce il costo di generare un possibile risultato, ma non riduce automaticamente il costo di verificarlo. Se il primo processo cresce molto più velocemente del secondo, il sistema finisce per saturarsi.
È una dinamica che riguarda anche gli agenti AI più avanzati. NVIDIA, per esempio, sta lavorando su strumenti di isolamento e controllo come quelli raccontati nel nostro approfondimento su OpenShell e Sentry: più un sistema è autonomo, più diventano importanti le barriere che filtrano errori e comportamenti indesiderati.
Cosa cambia per i ricercatori
Per chi usa l’AI nella ricerca di sicurezza il messaggio è chiaro: il modello può aiutare a trovare piste interessanti, ma il controllo finale deve arrivare prima dell’invio. Un report utile deve spiegare in modo preciso il contesto, indicare cosa è stato osservato e separare i fatti dalle interpretazioni automatiche.
La qualità del filtro diventa quindi importante quanto la capacità di analisi. Se gli strumenti continueranno a rendere più economica la produzione di possibili segnalazioni, i programmi di bug bounty dovranno probabilmente alzare ancora l’asticella in ingresso.
Il vero limite dell’AI, oggi, è la verifica
Per anni l’obiettivo della sicurezza automatizzata è stato trovare più problemi in meno tempo. Il caso Google mostra che esiste anche il problema opposto: trovare troppo senza riuscire a distinguere rapidamente il segnale dal rumore.
La pausa dell’OSS VRP non dice che l’AI non sappia aiutare a trovare bug. Dice qualcosa di più interessante: finché la verifica resta un’attività costosa, aumentare la velocità di generazione dei report senza aumentare la qualità può peggiorare il lavoro di chi deve rendere il software più sicuro.



Entra nella conversazione
Condividi il tuo punto di vista: non serve creare un account. I contributi restano soggetti alla moderazione editoriale.