Google ferma il bug bounty open source: l’AI sommerge i maintainer di falsi bug

📌 In Sintesi

• Google ha sospeso dal 1° ottobre 2026 le nuove segnalazioni di vulnerabilità di prodotto nel programma OSS VRP dedicato all’open source.
• La società attribuisce la decisione a una crescita delle segnalazioni automatizzate in gran parte non valide, dopo avere già denunciato a marzo l’esplosione di report generati con AI.
• Restano aperte le segnalazioni sulla software supply chain: il problema non è trovare più potenziali bug, ma distinguere automaticamente quelli reali dal rumore prodotto dalle macchine.

L’intelligenza artificiale doveva moltiplicare la capacità di trovare vulnerabilità nel software. Sta riuscendo anche in qualcosa di meno utile: moltiplicare il numero di bug che qualcuno deve perdere tempo a dimostrare che non esistono. Google ha sospeso le nuove segnalazioni di vulnerabilità di prodotto nel proprio Open Source Software Vulnerability Rewards Program, il programma che permette ai ricercatori di segnalare falle nei progetti open source dell’azienda. La decisione arriva dopo mesi di tentativi per alzare la qualità delle submission e fotografa uno dei primi effetti economici concreti dell’automazione applicata alla vulnerability research: generare un rapporto costa ormai pochissimo, verificarlo continua a richiedere competenze, tempo umano e capacità di riprodurre realmente la vulnerabilità.

Google blocca le nuove vulnerabilità di prodotto ma lascia aperta la supply chain

Dal 1° ottobre Google non accetta più nuove segnalazioni classificate come product vulnerabilities nell’OSS VRP. La pagina ufficiale delle regole del Google Open Source Software Vulnerability Reward Program chiarisce che la sospensione non riguarda i report già aperti né le segnalazioni relative alla supply chain, mentre per alcuni progetti collegati a Google Cloud possono rimanere disponibili percorsi differenti attraverso il Cloud VRP. Google invita inoltre i ricercatori a utilizzare gli altri programmi di vulnerability reward o il Patch Rewards Program e promette un aggiornamento sulla riorganizzazione del meccanismo nel primo trimestre del 2027. La distinzione è importante: non viene abbandonata la ricerca sulle vulnerabilità open source e soprattutto non viene chiuso il canale destinato alle compromissioni della catena di sviluppo, terreno nel quale attacchi come Shai-Hulud hanno dimostrato quanto una singola compromissione npm possa propagarsi tra decine di pacchetti.

Leggi anche: Software spia e bug: incompetenza o dossieraggio? Parola agli Hackers

L’allarme era partito a marzo: l’AI inventava exploit e percorsi di attacco

La sospensione non arriva improvvisamente. A marzo Google aveva già modificato le regole dell’OSS VRP dopo avere osservato una crescita massiccia dei report prodotti attraverso strumenti di intelligenza artificiale. Nel precedente intervento ufficiale del team Google Bug Hunters l’azienda descriveva segnalazioni contenenti informazioni errate, allucinazioni sulle modalità con cui una vulnerabilità avrebbe potuto essere attivata e problemi di codice tecnicamente presenti ma privi di reale impatto perché collocati in percorsi non raggiungibili. Google aveva quindi iniziato a pretendere prove più forti per alcune categorie, comprese riproduzioni verificabili o patch effettivamente integrate. Sei mesi dopo quella barriera non è bastata. Il problema non è che l’AI non sappia trovare bug, ma che può produrre ipotesi di vulnerabilità a una velocità superiore alla capacità umana di scartare quelle sbagliate.

Il bug bounty entra nella sua crisi economica: attaccare costa meno che verificare

Il modello dei bug bounty si basa su un’asimmetria precisa: migliaia di ricercatori cercano problemi, ma il vendor paga e analizza soltanto una parte delle scoperte realmente utili. L’automazione cambia l’equilibrio perché un singolo ricercatore può utilizzare modelli linguistici, scanner e agenti per produrre quantità enormi di potenziali finding, corredandoli automaticamente con descrizioni, analisi del codice e possibili scenari di exploit. La forma del rapporto può apparire professionale anche quando la sostanza è inesistente. A quel punto il costo marginale della submission tende verso zero, mentre dall’altra parte un maintainer deve leggere il report, individuare il codice, ricostruire le condizioni operative, tentare la riproduzione e stabilire se esista realmente un impatto di sicurezza. È il rovescio della promessa discussa da anni nell’incontro tra cybersecurity e intelligenza artificiale: l’automazione aumenta contemporaneamente la capacità di difendere e quella di saturare i processi difensivi.

L’open source rischia più di Google perché il collo di bottiglia sono i maintainer

Google può permettersi team dedicati, infrastrutture di triage e sistemi interni per classificare le submission. Un progetto open source mantenuto da poche persone non dispone della stessa capacità. Ed è proprio qui che lo spam di vulnerabilità diventa un problema di sicurezza invece che un semplice fastidio amministrativo: ogni ora spesa per dimostrare che un report generato automaticamente è falso è un’ora sottratta alla revisione del codice, alla manutenzione o alla correzione di una falla reale. La pressione aumenta ulteriormente quando una vulnerabilità riguarda dipendenze utilizzate da migliaia di progetti, perché il valore dell’open source moderno deriva dalla riutilizzazione del codice ma anche il rischio si propaga lungo la stessa struttura. Le campagne che hanno interessato npm, comprese quelle con pacchetti malevoli capaci di propagare worm e componenti DDoS, mostrano perché Google mantenga aperto proprio il canale dedicato alle compromissioni della supply chain.

Continua con:

Gli sviluppatori Linux riparano bug più velocemente di chiunque altro

Due bug al prezzo di uno, la triste storia di Log4j

La prossima difesa dovrà valutare il bug prima ancora che un umano lo legga

La sospensione dell’OSS VRP anticipa quindi un problema destinato a estendersi ben oltre Google. Se l’intelligenza artificiale permette di generare milioni di ipotesi di vulnerabilità, i programmi di disclosure non potranno continuare a utilizzare modelli di triage progettati quando ogni rapporto richiedeva un investimento significativo da parte del ricercatore. Serviranno dimostrazioni riproducibili, proof-of-concept realmente eseguibili, verifica automatica dell’accessibilità del codice vulnerabile e probabilmente sistemi AI incaricati di controllare altre AI prima che il finding raggiunga un analista umano. La vulnerability research sta entrando in una fase nella quale produrre una possibile falla diventa semplice e dimostrarne l’esistenza diventa la vera competenza rara. Google non sta rinunciando ai bug hunter: sta constatando che, quando una macchina può comportarsi contemporaneamente come migliaia di ricercatori mediocri, il vecchio filtro basato sulla semplice segnalazione non regge più.