Google sospende il bug bounty open source: l'AI ha inondato il…

Il primo ottobre 2026 Google ha bloccato le segnalazioni di vulnerabilità di prodotto per il suo Open Source Software Vulnerability Reward Program (OSS VRP). La

{"main_topic":"cybersecurity","topics":["cybersecurity","bigtech","ai","opensource","vulnerabilita"]}

Il primo ottobre 2026 Google ha bloccato le segnalazioni di vulnerabilità di prodotto per il suo Open Source Software Vulnerability Reward Program (OSS VRP). La causa: un afflusso di submission automatizzate generate da intelligenza artificiale, la stragrande maggioranza delle quali non valida. Il programma — uno dei principali canali di disclosure per ricercatori indipendenti su progetti open source — rimane parzialmente operativo solo per report supply chain, mentre le segnalazioni di prodotto attendono una ristrutturazione architetturale il cui aggiornamento è promesso per il primo trimestre 2027.

Punti chiave

Google ha sospeso le submission di vulnerabilità di prodotto per l'OSS VRP dal 1° ottobre 2026, su annuncio ufficiale pubblicato su X.
La motivazione dichiarata è "un significativo aumento di segnalazioni automatizzate, la stragrande maggioranza delle quali non valide".
Le segnalazioni supply chain rimangono aperte; i ricercatori possono reindirizzare verso il Google Cloud VRP o il Patch Rewards Program.
Il fenomeno non è isolato: i maintainer Linux avevano già segnalato di essere "completamente sommersi" da circa 2.000 CVE falsi per release, e Intel ha recentemente congelato il proprio bug bounty.

"Why is this happening? This pause is due to a significant rise in automated submissions, the vast majority of which are not valid. We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027." — Google, via post su X (come riportato da Times of India)

La struttura del blocco: cosa resta aperto e cosa no

La sospensione non è totale. Google ha esplicitato tre eccezioni operative. Le segnalazioni supply chain — quelle che riguardano la catena di distribuzione delle dipendenze software — continuano a essere accettate nel contesto OSS VRP. Le vulnerabilità di prodotto già loggate prima del primo ottobre 2026 mantengono il loro iter di triage. Inoltre, certe tipologie di vulnerabilità su repository Google Cloud possono ancora transitare attraverso il Google Cloud VRP, programma distinto e non interessato dalla pausa.

La fonte non specifica i criteri di selezione per le repository idonee al Cloud VRP né la percentuale di ricercatori che potranno effettivamente migrare i propri flussi. Google ha comunque indicato il Patch Rewards Program come rotta alternativa, senza dettagliare le differenze di ambito o payout rispetto all'OSS VRP originale.

Il meccanismo del collasso: costo marginale zero contro capacità finita

Il nucleo tecnico dell'episodio è economico più che puramente informatico. I large language model hanno abbattuto a zero il costo marginale di generazione di report di vulnerabilità plausibili formalmente: linguaggio tecnico corretto, riferimenti a componenti reali, struttura di disclosure coerente con gli standard del settore. La barriera d'ingresso per un attore malevolo o per un operatore di spam non è più la competenza in reverse engineering, ma la capacità di prompt engineering e di automazione API.

Il triage umano non scala linearmente. Un programma di bug bounty tipico impiega ore-di-lavoro per verificare ogni submission: reproduzione dell'exploit, analisi dell'impatto, valutazione della severità, comunicazione al maintainer. Quando il rapporto tra report validi e invalidi si sposta drasticamente — la fonte riporta la caratterizzazione di Google, "la stragrande magioranza" non valida — il sistema di verifica diventa il collo di bottiglia strutturale. La sospensione è quindi una misura di emergenza per preservare la funzionalità residua del programma, non una risposta a una minaccia di sicurezza nel senso classico.

Il dossier non specifica se Google abbia rilevato pattern ricorrenti nelle submission automatizzate: modelli LLM particolari, strutture di prompt comuni, o metadati di rete ricorrenti. Senza questi dati, resta aperto il quesito se il fenomeno sia organizzato da attori specifici o diffuso come comportamento aggregato di singoli operatori.

Il contesto industriale: Linux e Intel come segnali di sistema

La decisione Google si inserisce in un pattern più ampio documentato dalle stesse fonti. I maintainer del kernel Linux avevano già pubblicamente dichiarato di essere "completamente sommersi" da segnalazioni CVE fraudolente, con cacciatori di vulnerabilità basati su AI che spingevano il conteggio a circa 2.000 CVE per release — un ordine di grandezza che eccede la capacità di verifica di qualsiasi team di sicurezza open source.

Intel, per parte sua, ha recentemente congelato il proprio bug bounty, che prevedeva payout fino a 100.000 dollari per singola vulnerabilità. Le fonti editoriali collegano questa sospensione agli stessi colli di bottiglia da spam AI, ma con una cautela necessaria: Intel non ha ufficialmente confermato questa motivazione. La correlazione temporale e settoriale è solida; la causalità documentata non lo è.

La convergenza di tre casi in ecosistemi distinti — Google OSS, Linux kernel, Intel hardware — suggerisce che il problema sia sistemico per l'infrastruttura di disclosure, non circoscritto a una singola organizzazione o a un modello di programma. I programmi di bug bounty sono stati progettati nell'era pre-LLM, con assunti di segnalazione umana e costi di opportunità naturali che filtravano il rumore. La rimozione di questi filtri richiede una rinegoziazione architetturale.

Cosa fare adesso

I ricercatori con segnalazioni di prodotto già pronte devono verificare la data di log: solo le submission ante 1° ottobre 2026 mantengono iter attivo nell'OSS VRP.
Chi lavora su vulnerabilità in repository Google Cloud deve confermare l'idoneità al Cloud VRP prima di procedere, dato che non tutte le repository rientrano nell'eccezione.
Per progetti open source non-Google, valutare il Patch Rewards Program come alternativa, con attenzione alle differenze di ambito e criteri di eleggibilità rispetto all'OSS VRP originale.
I maintainer di progetti open source terzi devono monitorare il proprio flusso di disclosure: la verifica manuale di CVE sospette genera debito tecnico di sicurezza che ritarda patch reali.

La riformattura promessa e i limiti del dossier

Google si è impegnata a fornire un aggiornamento nel primo trimestre 2027, senza pre-commettere la natura della riforma. Il dossier non documenta se l'azienda stia valutando: requisiti di autenticazione per i ricercatori, strumenti di rilevamento contenuto generato da AI, quote di submission, o modelli di payout modificati per disincentivare il volume. Restano unknown anche l'entità finanziaria del danno — ore di triage sprecate, opportunità perse per ricercatori legittimi — e l'impatto sui maintainer dei progetti open source coperti dall'OSS VRP, che perdono temporaneamente un canale di disclosure strutturato.

La fonte non specifica inoltre se altri programmi Google — il Chrome VRP, l'Android VRP — siano esposti a dinamiche analoghe, o se le difese architetturali in corso di sviluppo per l'OSS VRP saranno estensibili.

La lettura: verso un nuovo modello di verifica

L'episodio evidenzia una contraddizione strutturale della sicurezza contemporanea. I programmi di bug bounty hanno democratizzato la ricerca di vulnerabilità abbassando il costo di segnalazione per ricercatori legittimi; l'AI generativa ha abbassato lo stesso costo per operatori di spam, annullando il vantaggio selettivo. Il risultato è una tragedia degli anticomuni informativa: quando la risorsa scarsa è la capacità di triage, il sovraccarico da parte di un attore libero-accesso penalizza l'intera comunità.

La soluzione non risiede probabilmente in una tecnologia di filtro singola, ma in una riprogettazione economica del programma: meccanismi che ricostituiscano costi di opportunità differenziati, rendendo conveniente la segnalazione di qualità e onerosa quella di massa. Il primo trimestre 2027 sarà il test per capire se Google — e l'industria — abbiano trovato questa leva.

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

Fonti

Fonti e riferimenti

Ricevi DeafLetter