In breve
Google ha congelato il suo bug bounty open source perché i report di vulnerabilità generati dall'IA rendevano il programma troppo costoso da gestire, non perché il codice sia diventato più sicuro. Dal 1° ottobre 2026 l'OSS VRP non accetta più nuove segnalazioni di vulnerabilità di prodotto per i progetti mantenuti da Google, come Go, Angular, Bazel e Protocol Buffers. Google promette un aggiornamento nel primo trimestre 2027.
Per i team che costruiscono su queste librerie, una rete di sicurezza esterna si è appena assottigliata. Per chi gestisce una propria casella per le segnalazioni, è un avvertimento: la stessa ondata arriverà anche da voi. È il momento giusto per verificare che i vostri penetration test e audit di sicurezza non dipendano dalla speranza che qualcuno all'esterno trovi i bug per primo.
Che cosa ha annunciato Google?
Il team vulnerability rewards di Google ha annunciato che l'OSS VRP ha smesso di accettare nuove segnalazioni. Nella nota, Google spiega che la sospensione «è dovuta a un aumento significativo delle segnalazioni automatiche, la grande maggioranza delle quali non è valida». TechCrunch, che per primo ha dato la notizia il 4 ottobre, descrive ingegneri di Google e maintainer open source sopraffatti da report non validi, alcuni con dettagli allucinati.
Dal 2022 il programma ricompensava ricercatori esterni per le falle nel codice open source mantenuto da Google: il linguaggio Go e la sua toolchain, Angular, Bazel, Protocol Buffers, Fuchsia e le relative impostazioni di repository e supply chain. Google non chiude tutte le porte. I fix di sicurezza possono ancora valere fino a 15.000 dollari tramite il Patch Rewards Program, le falle nei repository open source di Google Cloud che toccano i prodotti Cloud possono ancora passare dal Cloud VRP, e i report inviati prima del 1° ottobre saranno gestiti come prima.
Perché i bug bounty cedono sotto i report dell'IA?
Gli LLM e gli script automatici di bug hunting hanno portato quasi a zero il costo di scrivere un report di vulnerabilità plausibile, mentre il costo di verificarlo non è cambiato. Ogni report richiede ancora un ingegnere che conosca il codice per leggerlo, provare a riprodurlo e spiegare perché è o non è un bug. Quando la maggior parte dei report è sbagliata, quel lavoro finisce nel rumore e le scoperte reali aspettano di più.
Google non è il primo a smettere di pagare il volume. Il progetto curl ha chiuso il suo bug bounty su HackerOne a gennaio 2026 dopo un'ondata di report generati dall'IA e, secondo BleepingComputer, a settembre Intel ha eliminato le ricompense economiche dal suo programma su Intigriti. Lo schema è costante: i programmi che pagano per ogni scoperta valida ma accettano segnalazioni illimitate sono i primi a cedere.
Cosa significa per i team software in Italia
Primo, le vostre dipendenze perdono una fonte di controllo esterno. Molti servizi back-end sono scritti in Go, molti front-end usano Angular e Protocol Buffers è presente nella maggior parte degli stack gRPC. Google continua a correggere questi progetti, ma per mesi meno ricercatori esterni retribuiti li esamineranno. Trattate gli advisory di sicurezza di queste librerie come qualcosa da monitorare e applicare, non come qualcosa che qualcun altro ha già trovato.
Secondo, la vostra casella per le segnalazioni è la prossima. Se gestite un programma di vulnerability disclosure o un indirizzo security@ pubblico, gli stessi strumenti che hanno travolto Google possono sommergere un team di sicurezza di tre persone molto più in fretta. Una coda piena di report sicuri di sé ma sbagliati non fa solo perdere tempo: è così che un report reale e sfruttabile si perde.
Terzo, nell'UE un report ignorato può diventare un problema di conformità. Il Cyber Resilience Act chiede ai produttori di software una politica di divulgazione coordinata delle vulnerabilità e la gestione delle segnalazioni ricevute; i suoi obblighi di notifica per le falle attivamente sfruttate si applicano dall'11 settembre 2026. «Eravamo sommersi dallo spam dell'IA» non giustificherà una segnalazione persa. La capacità di triage va pianificata insieme alla capacità di patching.
Cosa fare adesso?
- Mappate la vostra esposizione. Elencate, partendo dalla SBOM o dai manifest delle dipendenze, i servizi che includono moduli Go, Angular, artefatti compilati con Bazel o Protocol Buffers, con le versioni esatte.
- Seguite gli advisory, non i bounty. Iscrivetevi al database delle vulnerabilità di Go, ai GitHub Security Advisories e ai feed OSV per queste dipendenze, e collegateli agli alert che il vostro team di reperibilità già legge.
- Alzate l'asticella per le segnalazioni. Richiedete una versione interessata precisa, i passaggi per riprodurre il problema e un proof of concept. Un modulo strutturato filtra molto più rumore di un indirizzo e-mail libero.
- Fate uno screening automatico. Verificate con un primo passaggio che file, funzioni e versioni citati esistano davvero prima che un ingegnere ci dedichi tempo. I percorsi di codice allucinati sono il segnale più comune.
- Proteggete il segnale. Mantenete una corsia preferenziale per ricercatori e clienti noti, pubblicate perimetro e contatti in security.txt e misurate la quota di report validi per accorgervi quando la coda inizia a traboccare.
Domande frequenti
Che cosa ha sospeso Google?
Google ha sospeso le nuove segnalazioni al suo Open Source Software Vulnerability Rewards Program (OSS VRP), il bug bounty dei progetti open source mantenuti da Google come Go, Angular, Bazel, Protocol Buffers e Fuchsia. La sospensione è in vigore dal 1° ottobre 2026. Google la attribuisce a un aumento significativo delle segnalazioni automatiche, la grande maggioranza delle quali non era valida.
Quanto durerà la sospensione dell'OSS VRP?
Non c'è una data di fine. Google sta rivedendo il programma e prevede un aggiornamento nel primo trimestre 2027. I report inviati prima del 1° ottobre 2026 non sono interessati, secondo BleepingComputer e Help Net Security.
I ricercatori possono ancora segnalare bug nei progetti open source di Google?
Sì, attraverso altri canali. Il Patch Rewards Program paga ancora fino a 15.000 dollari per fix di sicurezza ad alto impatto, e le falle nei repository open source di Google Cloud che toccano i prodotti Cloud possono passare dal Cloud VRP. Le vulnerabilità si possono ancora segnalare ai maintainer; è sospeso solo il percorso retribuito per le falle di prodotto.
Go, Angular o Protocol Buffers diventano meno sicuri?
Non direttamente. Google continua a mantenere e correggere questi progetti e i suoi team di sicurezza ci lavorano ancora. In pratica viene meno un incentivo economico per i ricercatori esterni: i team che usano queste librerie dovrebbero affidarsi alla propria scansione delle dipendenze e al monitoraggio degli advisory, invece di contare sui bug hunter per trovare i problemi per primi.
Come proteggere il nostro programma di disclosure dallo spam dell'IA?
Chiedete un proof of concept riproducibile su una versione indicata, usate un modulo strutturato, pubblicate un perimetro chiaro in security.txt e nella vostra policy, e fate uno screening automatico dei report privi di passaggi di riproduzione o con percorsi di codice allucinati prima che li legga un ingegnere. Mantenete una corsia preferenziale per chi ha uno storico affidabile e misurate quanti report risultano validi.
Fonti
Google Bug Hunters — Open Source Software Vulnerability Reward Program rules
TechCrunch — Google froze its open source bug bounty program due to a ‘significant rise’ in AI submissions (Oct 4, 2026)
BleepingComputer — Google halts open-source bug bounty program amid AI spam surge
Help Net Security — AI slop submissions force Google to freeze its open-source bug bounty