Tecnologia: Google sospende il bug bounty 2026

La settimana scorsa, mentre revisionavo la coda di ticket di sicurezza per un cliente enterprise, mi sono imbattuto in un pattern inquietante: cinque segnalazioni di vulnerabilità, tutte plausibili, tutte con proof-of-concept eleganti, e tutte completamente inventate. Non erano errori umani. Erano output di un modello linguistico. Questo micro-incidente nel mio workflow quotidiano riflette esattamente ciò che sta accadendo su scala industriale. La tecnologia generativa ha abbattuto il costo di produzione di report di sicurezza, saturando i canali di triage con rumore di fondo. La notizia che Google ha sospeso l’accettazione di nuove segnalazioni nel suo OSS VRP non è un’anomalia: è il primo segnale strutturale che l’ecosistema della sicurezza open source sta raggiungendo il suo punto di rottura operativo.

La sospensione dell’OSS VRP: date e motivazioni ufficiali

Il 1° ottobre 2026, Google ha comunicato tramite il proprio sito e i canali ufficiali la sospensione temporanea dell’Open Source Software Vulnerability Reward Program. La decisione, apparentemente drastica, risponde a una necessità aritmetica: la “grande maggioranza” degli invii recenti non è valida. Il programma, nato nel 2022 per coprire repository critici come Bazel, Angular, Go e Fuchsia, è stato travolto da un’ondata di segnalazioni automatizzate. A differenza dei tradizionali bug hunter, che investono ore o giorni per validare una falla, gli strumenti di intelligenza artificiale generano centinaia di report plausibili in pochi secondi. Il problema non è la velocità, ma la qualità intrinseca: molti contengono “allucinazioni”, ovvero bug inesistenti descritti con tale accuratezza formale da ingannare i filtri automatici, oppure problemi reali ma con impatto di sicurezza nullo. La sospensione non chiude il programma, ma congela il flusso in entrata per proteggere la capacità di triage umano.

Il ruolo dell’IA: allucinazioni e report infondati saturano il triage

Il fenomeno che Google ha certificato ufficialmente non è isolato, ma rappresenta la punta dell’iceberg di una crisi sistemica nella tecnologia di sicurezza. L’IA ha creato un’asimmetria economica pericolosa: il costo di produzione di un report plausibile è crollato quasi a zero, mentre il costo di verifica rimane elevato, dipendente dall’esperienza umana e non scalabile. I ricercatori di sicurezza che hanno speso anni a costruire reputazione si trovano ora a competere con bot che non hanno né intenzione malevola né competenza reale, ma solo pattern linguistici. Questo “rumore di fondo” rende inefficaci i tradizionali canali di segnalazione, costringendo le aziende a rivedere i propri processi. Quando ogni segnalazione richiede un’analisi umana per essere scartata, il valore del bug bounty si erode fino a diventare insostenibile.

Cosa resta attivo: supply chain e canali alternativi

Nonostante la sospensione, l’infrastruttura di sicurezza non si ferma. Google ha mantenuto attivi i canali specifici per la supply chain, riconoscendo che le minacce a monte della distribuzione del software rimangono critiche e difficili da automatizzare. I report inviati prima del 1° ottobre 2026 continuano a essere processati, garantendo continuità per le segnalazioni già in pipeline. Inoltre, i ricercatori possono continuare a utilizzare altri programmi VRP, come il Cloud VRP, che probabilmente beneficiano di filtri di pre-screening più maturi. Questa biforcazione suggerisce una strategia di triage differenziato: non tutto il software open source ha lo stesso profilo di rischio o la stessa densità di rumore AI. La separazione tra segnalazioni di prodotto e segnalazioni di supply chain potrebbe diventare il nuovo standard operativo per distinguere il segnale utile dal rumore generativo.

Precedenti e contesto: Intel e il kernel Linux sotto pressione

La decisione di Google segue un trend che aveva già colpito altri giganti. All’inizio del 2026, anche Intel ha congelato il proprio bug bounty per motivi analoghi, mentre i manutentori del kernel Linux segnalano da mesi un aumento esponenziale di richieste di CVE infondate. Questo contesto conferma che non si tratta di un problema di gestione del singolo programma, ma di una sfida architetturale per l’intera industria. La tecnologia dell’IA generativa ha democratizzato la capacità di produrre artefatti di sicurezza, ma ha anche diluito il segnale reale. Quando i manutentori di progetti critici devono dedicare tempo prezioso a respingere bug inventati, il costo opportunità in termini di sviluppo e patching reale diventa insostenibile. L’ecosistema open source, che si fonda sulla fiducia e sulla collaborazione, sta scoprendo che la fiducia non può essere automatizzata in un ambiente dove la plausibilità linguistica non equivale a verità tecnica.

L’economia della sicurezza: costo di produzione vs costo di verifica

Il punto cruciale di questa crisi è economico, prima ancora che tecnico. Google ha versato oltre 81 milioni di dollari ai ricercatori in 15 anni, e ad agosto 2026 ha corretto oltre 300 falle nel browser Chrome: numeri che testimoniano l’efficacia storica del modello. Tuttavia, quel modello presupponeva un rapporto costo/beneficio sostenibile. Con l’IA, quel rapporto si è invertito. Tre principi emergono da questa dinamica:

• La plausibilità non è validazione: un report ben scritto non è un bug reale. I modelli linguistici ottimizzano per la coerenza formale, non per l’accuratezza fattuale.
• Il triage è il nuovo collo di bottiglia: la capacità di elaborare segnalazioni non scala con l’automazione della produzione. Ogni report AI richiede un’analisi umana per essere scartato.
• La reputazione richiede verifica: i canali aperti a tutti diventano prede di spam generativo. I modelli chiusi, basati su inviti o pre-qualifica, potrebbero tornare dominanti.

Questa inversione economica costringe a ripensare i premi. Nella primavera 2026, Google aveva già inasprito i requisiti per l’OSS VRP, richiedendo prove di riproducibilità più rigorose e riducendo i premi per le fasce meno critiche. Misure insufficienti di fronte alla scala dell’attacco generativo.

Prospettive future: riprogettazione prevista per il 2027

Google prevede un aggiornamento sulla riprogettazione del programma nel primo trimestre del 2027. Questa finestra temporale suggerisce che la soluzione non sarà un semplice filtro AI contro AI, ma una revisione strutturale del modello di bug bounty. Le opzioni possibili includono:

1. Pre-qualifica obbligatoria: accesso ai canali di segnalazione solo per ricercatori con storico verificato.
2. Automazione del triage iniziale: strumenti di validazione automatica che richiedono proof-of-concept eseguibili in sandbox, non solo descrittivi.
3. Spostamento del focus: priorità alle vulnerabilità con impatto dimostrabile su production environment, ignorando i bug teorici.

Per le aziende che gestiscono programmi simili, la lezione è immediata: non aspettare che il rumore diventi insostenibile. In Romiltec, abbiamo iniziato a implementare filtri di pre-screening che richiedono artefatti eseguibili e non solo report narrativi. La tecnologia dell’IA generativa non può essere bloccata, ma può essere confinata a un ruolo di assistente, non di autore. La domanda strategica non è come fermare gli spammer AI, ma come ricostruire un processo di fiducia dove il costo della validazione umana sia giustificato dal valore reale delle segnalazioni. Quando il rumore supera il segnale, il silenzio diventa l’unica opzione razionale.

L’IA può generare plausibilità, ma solo l’esperienza umana può generare verità tecnica.

Stai già riscontrando un aumento di segnalazioni AI-generated nei tuoi canali di sicurezza? Rifletti su come il tuo processo di triage gestirà l’asimmetria economica tra produzione e verifica nei prossimi 18 mesi.