News

Google sospende il bug bounty open source dopo l’ondata di report IA

Google ha messo in pausa le nuove segnalazioni di vulnerabilità di prodotto all’interno dell’Open Source Software Vulnerability Rewards Program, il programma che premia chi individua falle nei progetti open source dell’azienda. La decisione è entrata in vigore il 1° ottobre e nasce dall’aumento dei report automatici, in larga parte non validi, inviati con l’aiuto dell’intelligenza artificiale.

di Giuliano Iervolino 4 minuti di lettura
La pagina ufficiale del programma Google Open Source Software Vulnerability Rewards Program

Google ha messo in pausa le nuove segnalazioni di vulnerabilità di prodotto all’interno dell’Open Source Software Vulnerability Rewards Program, il programma che premia chi individua falle nei progetti open source dell’azienda. La decisione è entrata in vigore il 1° ottobre e nasce dall’aumento dei report automatici, in larga parte non validi, inviati con l’aiuto dell’intelligenza artificiale.

Non si tratta della chiusura completa del bug bounty. Restano attivi i canali dedicati alla supply chain e gli altri programmi di ricompensa di Google; inoltre, le segnalazioni già inviate continueranno a essere esaminate. L’azienda prevede di comunicare un aggiornamento entro il primo trimestre del 2027.

Una pausa mirata, non la fine del programma

Lo stop riguarda le nuove segnalazioni di vulnerabilità di prodotto nell’OSS VRP. Google continua invece ad accettare i report relativi a compromissioni della catena di fornitura software, una delle aree più delicate per repository, pipeline di build e credenziali di pubblicazione.

Le vulnerabilità già trasmesse prima del 1° ottobre restano in lavorazione. Per alcuni repository che incidono direttamente sui prodotti Google Cloud, i ricercatori possono inoltre valutare il canale separato Cloud VRP, seguendo le regole e l’ambito indicati sul portale Bug Hunters.

Il problema sono i report automatici non verificati

Secondo la spiegazione ripresa dalla comunicazione ufficiale, il volume delle segnalazioni generate automaticamente è cresciuto in modo significativo e la maggior parte dei nuovi invii non risulta valida. Il costo per produrre un rapporto plausibile è sceso, ma quello necessario a controllarlo resta umano.

Un testo tecnicamente convincente può descrivere una funzione inesistente, un percorso di esecuzione irraggiungibile oppure un impatto che non può verificarsi nel modello di sicurezza reale del progetto. Ogni falso positivo sottrae quindi tempo agli ingegneri e ai manutentori che devono riprodurre il caso prima di poterlo scartare.

Google aveva già irrigidito le regole in primavera

La sospensione arriva dopo un primo intervento annunciato da Google Bug Hunters a marzo 2026. Per alcune classi di progetto, l’azienda aveva introdotto prove più rigorose, come una riproduzione tramite OSS-Fuzz oppure una correzione già integrata, con l’obiettivo di concentrare il triage sui problemi realmente sfruttabili.

L’aggiornamento aveva inoltre ridotto o eliminato le ricompense per le vulnerabilità di prodotto nei livelli open source meno critici, mantenendo alta la priorità per compromissioni della supply chain e credenziali sensibili. Il nuovo stop indica che quei filtri non sono bastati a riportare il rapporto tra segnale e rumore a un livello sostenibile.

L’IA può trovare bug, ma deve anche dimostrarli

La vicenda non dimostra che gli strumenti di intelligenza artificiale siano inutili per la sicurezza. Possono accelerare la lettura del codice, suggerire superfici di attacco e aiutare a preparare test. Il punto decisivo è la verifica: un’ipotesi prodotta da un modello non equivale a una vulnerabilità.

Per essere utile, un report deve includere versione interessata, condizioni necessarie, passaggi riproducibili, impatto concreto e materiale sufficiente per confermare il problema. Senza questi elementi, l’automazione trasferisce semplicemente il lavoro dal ricercatore al team che riceve la segnalazione.

Cosa cambia per chi fa ricerca sulla sicurezza

Durante la pausa, chi individua un problema deve controllare con attenzione l’ambito degli altri Vulnerability Reward Program di Google. Le vulnerabilità nei prodotti online, in Chrome, Android o Cloud seguono canali distinti; una segnalazione open source non può essere spostata automaticamente soltanto per aggirare lo stop.

Per i progetti coperti dall’OSS VRP rimane particolarmente importante documentare i problemi di supply chain, ancora accettati. Google invita comunque i ricercatori a consultare le regole aggiornate prima di iniziare un’attività, perché repository, tipologie di vulnerabilità e requisiti di prova possono cambiare.

Il vero collo di bottiglia resta il triage

L’episodio mostra un limite pratico della sicurezza assistita dall’IA: aumentare il numero delle ipotesi non aumenta automaticamente il numero dei bug utili. Se la validazione non cresce allo stesso ritmo, le segnalazioni corrette rischiano di perdersi in mezzo a rapporti incompleti o inventati.

La risposta di Google sarà interessante anche per gli altri programmi di bug bounty. Filtri reputazionali, prove obbligatorie e ambienti di riproduzione standardizzati possono ridurre il rumore, ma devono evitare di escludere ricercatori indipendenti capaci di produrre risultati solidi.

Leave A Reply