Google ha smesso di accettare nuove segnalazioni di vulnerabilità di prodotto nell’Open Source Software Vulnerability Reward Program il 1º ottobre 2026. L’azienda ha indicato una forte crescita degli invii automatizzati, in grandissima parte non validi. Prevede un aggiornamento nel primo trimestre 2027.
È la pausa di una categoria, non la chiusura di tutti i premi Google né un divieto di ricerca assistita dall’IA. Il problema è più preciso: generare una tesi di sicurezza plausibile costa poco, ma verificarne la realtà richiede ancora competenze scarse.
Che cosa chiude e che cosa resta aperto
Google avviò OSS VRP nel 2022 per problemi di sicurezza open source ammissibili. Le segnalazioni di prodotto riguardano difetti di codice, logica o progetto. La pausa interessa i nuovi invii della categoria; quelli precedenti restano esaminabili.
Le segnalazioni sulla catena di fornitura rimangono aperte. Alcuni problemi di repository Google Cloud possono rientrare nel Cloud VRP, secondo prodotto e regole. Continuano anche gli altri programmi, tra cui Chrome, Android, dispositivi e sicurezza dell’IA. I ricercatori devono controllare l’ambito effettivo, senza presumere un’alternativa identica per ogni repository.
La sospensione segue cambiamenti precedenti. Le regole del 2026 richiedevano validazione dei risultati assistiti e un impatto reale. In aprile Google eliminò denaro e riconoscimento pubblico per alcune categorie inferiori di vulnerabilità di prodotto e altri problemi. Quegli interventi più mirati non impedirono la successiva pausa.
Google non ha pubblicato conteggi precisi, tasso di accettazione o arretrato del canale. Le cronache secondarie descrivono migliaia di rapporti deboli, ma il numero non compare nell’avviso aziendale. “Quasi tutti non validi” segnala un problema serio senza offrire una base statistica completa.
Il sostituto non è ancora definito pubblicamente. Riproduzioni testate, limiti di invio, identità e selezione automatica sono opzioni, non condizioni annunciate di riapertura.
Un rapporto convincente può non contenere vulnerabilità
Un modello può individuare un’operazione sospetta, costruire un attacco e aggiungere una valutazione professionale della gravità. L’operazione potrebbe però non ricevere mai dati dell’attaccante, essere irraggiungibile o protetta. Anche un errore reale può non avere conseguenze di sicurezza nel modello di minaccia del progetto.
I revisori ricostruiscono queste condizioni: esaminano versioni, riproducono comportamento, controllano mitigazioni e cercano duplicati. Una funzione o condizione inventata può nascondersi in un’esposizione coerente. La buona presentazione non sostituisce più la prova.
Christopher Robinson dell’Open Source Security Foundation stimava in marzo che progetti abituati a due o tre segnalazioni settimanali ricevessero poi centinaia di rapporti insieme. Una singola indagine poteva richiedere da due a otto ore impreviste al manutentore. Sono osservazioni attribuite su più progetti, non misure della coda Google.
Le ricompense possono aggravare l’asimmetria. L’autore genera molte ipotesi mentre il destinatario paga gran parte della verifica. Duplicati, gravità esagerata e comportamenti documentati fraintesi competono con scoperte vere. Anche il volume in buona fede può sottrarre tempo alle riparazioni.
Non conta soprattutto se un modello abbia scritto il testo. Traduzione, spiegazione e test possono migliorare una ricerca legittima. Una persona deve comunque capire il percorso raggiungibile, riprodurre il risultato e rispondere alle domande. Riscrivere in stile umano un’ipotesi non testata non la valida.
La ricerca verificata impedisce un rifiuto generale dell’IA
Google continua le difese assistite, tra cui OSS-Fuzz, Big Sleep e CodeMender. Le squadre interne possono definire obiettivi, raccogliere prove di esecuzione e controllare patch. Un programma esterno riceve materiali da strumenti e ambienti diversi senza la stessa catena controllata.
I premi complessivi restano rilevanti. Il bilancio annuale indica oltre 17 milioni di dollari a più di 700 ricercatori nel 2025, oltre il 40% in più del 2024. Sono totali dei programmi più ampi, non budget o produttività della categoria sospesa.
Le notizie riportano un altro contrasto. Anthropic affermava che Claude Opus 4.6 avesse trovato oltre 500 vulnerabilità open source sconosciute, tutte validate da persone o esperti esterni prima della divulgazione. Mozilla ricevette 112 rapporti in due settimane e pubblicò 22 avvisi, 14 ad alta gravità. Molti altri risultati furono classificati come errori non di sicurezza.
Le unità vanno separate: rapporti, avvisi e vulnerabilità validate non sono conteggi equivalenti. L’esempio sostiene scoperta automatizzata con validazione esperta, non una garanzia per qualsiasi rapporto generato.
La selezione automatica può raggruppare duplicati o richiedere prove mancanti, ma sbaglia anch’essa. L’accordo tra due modelli è meno forte di un test riproducibile indipendentemente. Casi insoliti e divergenze richiedono ancora un percorso umano.
Curl, Linux e HackerOne cambiano passaggi diversi
Curl terminò i premi monetari il 31 gennaio 2026 dopo un programma iniziato nel 2019. Daniel Stenberg riferì 87 vulnerabilità confermate nell’intero periodo. La quota di segnalazioni confermate era però scesa da oltre il 15% in precedenza a meno del 5% nel 2025.
La sua spiegazione univa rumore dell’IA, peggioramento degli altri rapporti e attenzione eccessiva al compenso. La fine dei pagamenti non eliminò la divulgazione responsabile: GitHub privato ed e-mail restarono disponibili. L’intervento mirava agli incentivi, con il rischio di scoraggiare anche ricercatori indipendenti accurati.
Linux riceveva gli stessi risultati da persone con strumenti simili. La gestione privata nascondeva discussioni e correzioni agli altri autori, costringendo i manutentori a ripetere verifiche. Torvalds sostenne canali pubblici per molti risultati facilmente riscopribili, salvo un’esigenza reale di segretezza.
Non significa pubblicare ogni exploit senza patch. Le regole del kernel richiedono descrizioni concise, revisioni interessate, condizioni, riproduzioni testate e impatto realistico. Gli autori devono capire il codice, coinvolgere i manutentori corretti e contribuire una patch quando possibile.
HackerOne segnalò un aumento superiore al 100% nel volume di settore dopo strumenti IA più capaci apparsi nel febbraio 2026. L’analisi include risultati utili, duplicati e affermazioni non verificabili. La piattaforma insiste su prove riproducibili, gravità corretta e difese esistenti; grandi lotti non verificati possono provocare sanzioni. È un’osservazione della piattaforma, non il tasso di invalidità Google.
Gli interventi differiscono: Google sospende una categoria, curl rimuove il denaro e Linux modifica aspettative e instradamento. Il limite comune è il tempo degli esperti, soprattutto quando dipendenze commerciali sono mantenute da volontari.
Riaprire richiede prove e una strada per i nuovi
Soglie rigide proteggono i revisori ma possono nascondere falle reali. La reputazione favorisce ricercatori affermati. Depositi e inviti opachi escludono esordienti. Richiedere un exploit completo può incoraggiare test pericolosi quando basterebbe una riproduzione minima controllata.
Un buon pacchetto identifica commit, ambiente, controllo dell’attaccante, input e confine di sicurezza superato. Documenta ciò che è stato davvero provato, distingue inferenza e osservazione e protegge dettagli riservati. Non dovrebbe imporre danni o l’invio di codice sensibile a un servizio non approvato.
I filtri devono individuare prove mancanti, non trattare lo stile IA come prova di invalidità. Non esiste un controllo affidabile della scrittura per stabilire se una falla sia reale. Ricorsi e specialisti contano perché catene insolite non sempre rientrano nei moduli.
Il prossimo aggiornamento mostrerà se Google preferisce requisiti chiari o meno partecipanti. I risultati utili includono conferme, duplicati, tempi di esame e riparazione, carico e falsi rifiuti, non soltanto meno invii. Le esperienze variano: Mozilla aveva descritto un tasso stabile di rifiuto dei rapporti invalidi. Google non rappresenta tutto l’ecosistema.
La distinzione costruttiva separa scala della scoperta e dell’invio. Gli agenti possono esplorare ampiamente; le persone dovrebbero ricevere risultati validati, deduplicati e con autori responsabili. La pausa non dimostra che l’IA non trovi bug. Mostra che ipotesi illimitate diventano valore di sicurezza solo dopo essere dimostrate.
Fonti
Regole Google OSS · Carico dei manutentori · Indagine sui rapporti falsi · Risultati verificati Mozilla · Decisione di curl · Base tecnica · Notizia sulla sospensione · Precedenti regole Google · Premi Google 2025 · Analisi dei volumi HackerOne · Regole di segnalazione Linux · TechCrunch sulla pausa Google · Techmeme sulla pausa Google