Google sospende il bug bounty open source per i report IA

📌 Sviluppi successivi: Chrome: catena da 250.000 dollari scritta con l’IA in sei giorni (14 ottobre 2026) · Chrome VRP: Google rialza i compensi, ma solo in parte (13 ottobre 2026)

Google ha sospeso fino al 2027 una parte del suo programma di ricompense per le vulnerabilità nei progetti open source, l’Open Source Vulnerability Rewards Program (OSS VRP). Il motivo, nelle parole dell’azienda, è un forte aumento delle segnalazioni automatiche, in grandissima parte non valide.

Non ci sono CVE da correggere né prodotti da aggiornare. La notizia interessa però chiunque gestisca vulnerabilità: l’intelligenza artificiale rende economico produrre report convincenti, mentre verificarli richiede ancora il tempo di un tecnico.

Cosa è successo

Secondo Infosecurity Magazine, l’annuncio è arrivato il 1° ottobre 2026 con un messaggio di Google sui social. The Hacker News e CSO Online precisano che lo stop riguarda le segnalazioni di vulnerabilità di prodotto dell’OSS VRP: Infosecurity Magazine parla più in generale di sospensione del programma, ma conferma che restano esclusi due casi:

• le segnalazioni sulla catena di fornitura (supply chain) dell’OSS VRP continuano a essere accettate;
• i report già inviati non sono toccati dalla sospensione.

Google intende riorganizzare il programma e prevede di dare aggiornamenti nel primo trimestre del 2027. Nel frattempo invita i ricercatori a cercare vulnerabilità negli altri suoi programmi di ricompensa oppure a partecipare al Patch Rewards Program.

Il programma OSS VRP

L’OSS VRP è nato ad agosto 2022 e premia chi trova vulnerabilità nei progetti open source di Google. Copre le ultime versioni del software ospitato nei repository pubblici di Google su GitHub e in alcuni repository su altre piattaforme, compresa la loro configurazione: workflow di GitHub Actions, regole di accesso, configurazioni delle applicazioni GitHub. Le ricompense vanno da 100 a 31.337 dollari, secondo la gravità e l’importanza del progetto.

Le vulnerabilità nei progetti legati a Google Cloud o ai prodotti di IA passano invece per programmi dedicati, il Cloud VRP e l’AI VRP.

I segnali dei mesi precedenti

Secondo CSO Online, la sospensione arriva dopo altri tentativi di arginare il problema. A marzo Google aveva già irrigidito le regole dell’OSS VRP dopo un forte aumento dei report generati con l’IA: alcuni descrivevano in modo errato come si attiva la vulnerabilità, altri segnalavano difetti di codice con un impatto sulla sicurezza minimo. Per alcune classi di vulnerabilità Google aveva iniziato a chiedere prove più solide, come risultati riproducibili o patch accettate, e in seguito aveva smesso di premiare alcune segnalazioni di prodotto di livello più basso.

Il quadro tecnico: il collo di bottiglia è la verifica

Le fonti non descrivono attacchi, malware o indicatori: non c’è una catena di attacco da mappare su MITRE ATT&CK. Il punto tecnico è un altro: chi riceve un report deve stabilire se il codice citato esiste, se il percorso d’attacco è raggiungibile e se l’impatto è reale. Un report credibile si genera in pochi minuti; controllarlo può richiedere a un ingegnere di seguire il codice e riprodurre le condizioni dichiarate.

Un grande volume di segnalazioni non significa per forza scarsa qualità. CSO Online cita due esempi:

• Vercel ha ricevuto 1.285 report in due settimane durante una sfida di sicurezza sul suo ambiente Sandbox, ha automatizzato parte del triage e alla fine ne ha convalidati alcune decine;
• una vulnerabilità critica in Rejetto HTTP File Server, trovata con l’aiuto di un modello di IA, è stata poi oggetto di tentativi di sfruttamento.

Gli esperti sentiti da CSO Online segnalano due rischi per chi difende:

1. il triage come bersaglio: un canale di segnalazione senza filtri potrebbe permettere a un attaccante di consumare le risorse del team di sicurezza senza violare alcun sistema, per esempio inviando varianti dello stesso report a più servizi. Le fonti precisano che non ci sono elementi per dire che Google sia stata oggetto di una campagna del genere;
2. la prompt injection nei report: se il triage è affidato a un agente di IA, un report malevolo può contenere istruzioni pensate per manipolarne la valutazione o fargli compiere azioni attraverso gli strumenti collegati.

Impatto per le aziende europee e italiane

La sospensione riguarda il programma di Google, ma lo stesso squilibrio tra scoperta e verifica può presentarsi in azienda: nei report che arrivano dall’esterno e nei risultati degli strumenti di analisi assistiti dall’IA usati internamente. Una segnalazione che arriva a chi gestisce un’applicazione prima di essere valutata può far perdere ore di lavoro anche quando la versione colpita non è installata o il codice vulnerabile non è raggiungibile.

Per i soggetti NIS2 la gestione e la divulgazione delle vulnerabilità fanno parte delle misure di gestione del rischio richieste dalla direttiva: un processo di triage che regge solo con volumi bassi è un punto debole da considerare.

Cosa fare subito

1. Chiedi prove riproducibili a chi segnala una vulnerabilità tramite i tuoi canali, accorpa i report duplicati e limita gli invii quando emergono schemi di abuso.
2. Verifica prima la presenza e la raggiungibilità: la versione colpita è installata? Il servizio è esposto? Solo dopo la segnalazione diventa una priorità.
3. Tratta ogni risultato di uno scanner come un’ipotesi, non come la prova di una vulnerabilità sfruttabile.
4. Dai priorità al contesto: un sistema esposto e critico o una vulnerabilità già sfruttata contano più del solo punteggio di gravità.
5. Considera testo e codice dei report come input non affidabile: se usi l’IA per il triage, tieni le prove lontane dai sistemi di produzione e fai verificare da una persona le azioni importanti.
6. Misura lo sforzo di verifica e l’età delle vulnerabilità ad alto rischio confermate, non il numero di rilievi prodotti dagli strumenti. Se il team passa sempre più tempo a scartare report deboli mentre i problemi confermati restano aperti, il processo va rivisto.

Come aiuta ARXDOME

ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, con la loro età e quelle già sfruttate dagli attaccanti in evidenza: aiuta a capire subito se un software segnalato è davvero installato nei tuoi sistemi. ARX Expose aggiunge la vista da fuori, con le vulnerabilità note sui servizi pubblici, per distinguere ciò che è esposto da ciò che non lo è.

Ultimo aggiornamento: 6 ottobre 2026