La sospensione di Google OSS VRP rivela il costo nascosto delle segnalazioni di bug generate dall'IA
Il 1° ottobre Google ha smesso di accettare nuove segnalazioni di vulnerabilità dei prodotti attraverso il proprio bug bounty open source, dopo che report IA non validi hanno sovraccaricato il processo di revisione. La sospensione di Google OSS VRP non pone fine a ogni componente del programma. Tuttavia, chiude un importante canale di segnalazione finché Google non completerà una riprogettazione.
Il problema immediato non è che l'intelligenza artificiale non possa individuare difetti software. I sistemi IA stanno già scoprendo vulnerabilità valide in codebase grandi e sottoposte a revisioni approfondite. Il problema è che generare un report plausibile costa ora molto meno che dimostrarne l'impatto sulla sicurezza.
Questo squilibrio ha trasformato il triage delle vulnerabilità nella risorsa scarsa. Google deve distinguere le scoperte reali da percorsi di attacco allucinati, codice irraggiungibile, duplicati e normali errori di programmazione. GitHub, i manutentori di Linux e i progetti open source più piccoli affrontano la stessa pressione.
Google afferma che le segnalazioni inviate prima della scadenza saranno comunque prese in considerazione. Le segnalazioni relative alla supply chain restano aperte, mentre alcune vulnerabilità nei repository di Google Cloud possono utilizzare il Cloud Vulnerability Reward Program. L'azienda prevede di fornire un ulteriore aggiornamento entro il primo trimestre del 2027.
La pausa mette in luce un conflitto rivelatore. L'IA promette di ampliare la ricerca difensiva sulla sicurezza, ma l'automazione non verificata può assorbire l'attenzione umana necessaria per correggere vulnerabilità autentiche. Il futuro della ricerca di bug assistita dall'IA dipende ora meno dal volume puro delle scoperte e più dalla qualità delle prove.
La sospensione di Google OSS VRP è circoscritta ma immediata
Google ha congelato una categoria di invii, non ha abbandonato il suo rapporto più ampio con i ricercatori di sicurezza esterni.
Il programma interessato è l'Open Source Software Vulnerability Reward Program, comunemente chiamato OSS VRP. Google lo ha lanciato nel 2022 per premiare i ricercatori che divulgavano responsabilmente vulnerabilità che interessavano progetti open source idonei.
Il programma copre software ospitato in repository pubblici di proprietà di Google e progetti selezionati ospitati altrove. Il suo ambito ha incluso sia vulnerabilità di prodotto sia compromissioni della supply chain. Queste categorie affrontano rischi diversi e ora seguono percorsi di segnalazione differenti.
Le vulnerabilità di prodotto riguardano difetti nel codice, nella logica o nella progettazione di un progetto. Un report convincente deve dimostrare che gli aggressori possono raggiungere il difetto e produrre conseguenze significative per la sicurezza. La sola individuazione di una funzione dall'aspetto non sicuro non dimostra lo sfruttamento.
Le segnalazioni relative alla supply chain riguardano minacce al modo in cui il software viene compilato, pacchettizzato, firmato o distribuito. Una pipeline di rilascio compromessa può diffondere codice dannoso anche quando il codice sorgente sottostante appare legittimo. Google ha mantenuto aperta quella categoria di segnalazione.
La sospensione si applica alle nuove segnalazioni di vulnerabilità dei prodotti presentate il 1° ottobre 2026 o dopo tale data. Le segnalazioni precedenti restano idonee alla revisione secondo il processo precedente. Google ha inoltre indirizzato i ricercatori verso gli altri programmi di ricompensa per vulnerabilità, ove applicabile.
Alcune segnalazioni che riguardano repository Google Cloud possono ancora qualificarsi tramite il Cloud VRP. Questa eccezione dipende dal fatto che il problema interessi un prodotto Google Cloud, non semplicemente dal fatto che il repository sorgente appartenga a Google.
Google ha annunciato il cambiamento attraverso il suo account Bug Hunters su X. Secondo il primo resoconto pubblicato, l'azienda ha collegato la propria decisione a un afflusso di segnalazioni non valide generate dall'IA.
La pausa segue mesi di irrigidimento delle regole, anziché un'inversione improvvisa. In un aggiornamento delle regole di aprile, Google ha descritto un'impennata di report di bassa qualità e non validi inviati all'OSS VRP.
Google ha individuato due schemi ricorrenti. Alcune segnalazioni contenevano spiegazioni allucinate su come una presunta vulnerabilità potesse essere attivata. Altre individuavano errori di programmazione reali, ma non riuscivano a dimostrare codice raggiungibile o un impatto significativo sulla sicurezza.
Questa distinzione conta perché difetti software e vulnerabilità di sicurezza non sono intercambiabili. Un crash in un'utilità di test irraggiungibile ha conseguenze diverse dall'esecuzione di codice remoto in un servizio di produzione.
Google aveva già smesso di offrire premi o riconoscimenti per alcune vulnerabilità di prodotto e altri problemi di sicurezza nei livelli di progetti a priorità inferiore. Ha inoltre sottolineato l'importanza di scoperte azionabili, passaggi di riproduzione verificati e dimostrazioni dell'impatto.
L'azione di ottobre estende quindi uno sforzo già in corso per ridurre il rumore. Invece di modificare i criteri di idoneità mentre i report continuano ad arrivare, Google ha chiuso il canale di ricezione interessato durante una riprogettazione più ampia.
L'azienda non ha divulgato il numero esatto di report respinti, l'entità dell'arretrato o il tasso di accettazione. Le affermazioni su migliaia di segnalazioni restano cifre riportate, non statistiche complete del programma.
L'assenza di questi dati limita l'analisi esterna. Tuttavia, la sequenza di modifiche alle regole, avvisi pubblici e il congelamento finale mostra che il filtraggio incrementale non ha risolto il problema del carico di lavoro.
Perché le segnalazioni di bug IA non valide compromettono il triage della sicurezza
L'IA cambia l'economia delle segnalazioni perché gli invii possono crescere automaticamente, mentre la validazione richiede ancora un giudizio umano scarso.
La ricerca tradizionale sulle vulnerabilità richiede diversi passaggi costosi. Un ricercatore deve comprendere il bersaglio, individuare una debolezza, costruire un attacco riproducibile, valutarne l'impatto e comunicare chiaramente il risultato.
I modelli linguistici di grandi dimensioni possono accelerare parti di questo lavoro. Possono esaminare il codice sorgente, suggerire flussi di dati pericolosi, redigere casi di test e trasformare appunti grezzi in prosa rifinita. Gli agenti automatizzati possono ripetere questi passaggi su molti repository.
Gli stessi strumenti possono anche produrre spiegazioni sicure di sé ma false. Un modello può presumere che gli aggressori controllino un input che resta affidabile. Può trascurare un controllo delle autorizzazioni, interpretare erroneamente una configurazione di deployment o inventare un percorso di esecuzione raggiungibile.
Questi errori diventano costosi dopo l'invio. Un ingegnere della sicurezza non può respingere un report dall'aspetto credibile basandosi sul tono. Deve esaminare il codice citato, riprodurre le condizioni, tracciare i dati e verificare se l'impatto dichiarato esiste.
Un report falso può quindi richiedere minuti per essere creato e ore per essere scartato. Mille report simili trasformano questo squilibrio in un denial of service operativo, anche senza intento malevolo.
La presentazione del report può peggiorare il problema. I modelli linguistici producono facilmente lunghe narrazioni di vulnerabilità, etichette di gravità, diagrammi di attacco e consigli di mitigazione. Nessuna di queste aggiunte sostituisce una riproduzione funzionante.
Un linguaggio curato può persino aumentare i costi del triage. I revisori devono individuare l'affermazione fattuale all'interno di pagine di contesto generato. Devono inoltre stabilire quali dichiarazioni derivano da test e quali da inferenze del modello.
Le regole precedenti di Google si concentravano su questa differenza tra rilevamento e validazione. Un avviso di un analizzatore statico può identificare codice sospetto. Non dimostra automaticamente che quel codice generi una violazione sfruttabile di un confine di sicurezza.
La raggiungibilità è un test essenziale. I revisori hanno bisogno di prove che un input non attendibile possa raggiungere l'operazione pericolosa in condizioni realistiche. I report devono inoltre tenere conto di sanitizzazione, privilegi, configurazione e difese esistenti.
L'impatto è un altro test. Un buffer overflow sembra grave, ma la sua posizione e i controlli circostanti determinano ciò che un aggressore può ottenere. Alcuni difetti terminano soltanto un processo isolato senza esporre dati o controllo.
Anche la novità è importante. I sistemi automatizzati possono riscoprire problemi noti, ripetere teorie già respinte o produrre diverse descrizioni della stessa causa radice. Ogni duplicato continua comunque a consumare capacità di ricezione e revisione.
Questo carico di lavoro ricade su persone specializzate. Manutentori e ingegneri della sicurezza esperti comprendono assunzioni architetturali che i modelli spesso non colgono. Coinvolgerli nella validazione ripetitiva ritarda patch, audit, revisioni progettuali e risposta agli incidenti.
Il costo opportunità si estende oltre Google. I progetti open source spesso hanno piccoli gruppi di manutentori, anche quando il loro codice supporta servizi ampiamente utilizzati. Una campagna di segnalazioni automatizzate può superare l'intera capacità di sicurezza disponibile.
I team possono preservare il contesto mantenendo decisioni, riproduzioni e risultati precedenti in una base di conoscenza ingegneristica ricercabile. Questa pratica riduce le indagini ripetute, ma non può eliminare la necessità di una verifica esperta.
La pausa del bug bounty di Google rende visibile questo vincolo di manodopera. I programmi di sicurezza sono stati progettati attorno a segnalazioni che comportano uno sforzo significativo da parte dei ricercatori. L'IA consente a chi invia il report di trasferire gran parte di quello sforzo al team ricevente.
Le segnalazioni di bug IA creano un problema di qualità, non un divieto dell'IA
Il conflitto centrale riguarda la ricerca verificata contrapposta all'automazione non verificata, non i ricercatori umani contrapposti all'intelligenza artificiale.
Google non ha sostenuto che i ricercatori debbano evitare del tutto l'IA. La sua posizione dichiarata è che le persone debbano validare l'output dell'IA durante la ricerca. Questo requisito considera l'IA uno strumento, anziché un soggetto responsabile della segnalazione.
Una segnalazione utile assistita dall'IA può comunque includere prove dirette. I ricercatori possono fornire versioni interessate, comandi esatti, casi di test minimizzati, log, screenshot e risultati osservati. Possono anche spiegare il confine di sicurezza violato.
La domanda decisiva è se una persona abbia confermato l'affermazione. Un'ipotesi generata da un modello diventa preziosa quando i test dimostrano che il codice rilevante è raggiungibile e che il risultato influisce su riservatezza, integrità o disponibilità.
Questo standard protegge l'automazione legittima. I fuzzer generano da anni scoperte di sicurezza inviando input inattesi e registrando i fallimenti. Il loro valore deriva da output concreti e riproducibili, non da descrizioni persuasive.
Gli agenti IA possono estendere questo modello. Possono ragionare sul codice sorgente, creare harness, indagare i crash e proporre patch. Il loro spazio di ricerca più ampio può far emergere difetti che gli strumenti convenzionali non rilevano.
Tuttavia, i sistemi di ragionamento introducono un'altra modalità di errore. Possono colmare le prove mancanti con un linguaggio plausibile. Uno scanner convenzionale di norma riporta il pattern rilevato, mentre un modello linguistico può inventare un'intera narrazione di attacco.
Questa differenza spiega perché i programmi di disclosure non possono semplicemente valutare i report in base alla loro fluidità. I revisori hanno bisogno di artefatti legati a comportamenti osservabili. Le affermazioni su conseguenze teoriche meritano minore fiducia rispetto a esiti dimostrati.
La prova più forte contro un rifiuto generalizzato dell'IA proviene da attività di sicurezza IA riuscite. I sistemi IA hanno individuato vulnerabilità autentiche in importanti progetti open source, inclusi difetti che i revisori umani non avevano rilevato.
Questi risultati mostrano perché vietare ogni report assistito dall'IA sarebbe miope. I team difensivi desiderano una copertura più ampia, soprattutto tra grandi grafi di dipendenze e codebase mature. Non desiderano speculazioni illimitate e non testate.
Google stessa usa l'IA nella ricerca difensiva sulla sicurezza. Il suo lavoro di sicurezza più ampio include la scoperta di vulnerabilità assistita dall'IA e il fuzzing open source. L'obiezione dell'azienda riguarda la qualità della validazione al confine della segnalazione.
Quel confine solleva una questione di responsabilità. Quando un agente autonomo invia un report, chi risponde alle domande successive? Qualcuno deve chiarire le ipotesi, modificare la riproduzione e distinguere il comportamento osservato da quello previsto.
Un report privo di un ricercatore responsabile trasferisce questi compiti al maintainer. Il destinatario diventa responsabile di completare l’indagine avviata dal mittente.
Una chiara divulgazione dell’uso dell’AI può aiutare, ma la sola divulgazione non può garantire la qualità. Anche un report scritto da un umano può essere errato. Un report generato dall’AI può essere corretto, conciso e testato approfonditamente.
I programmi necessitano quindi di filtri basati sulle evidenze, non di rilevatori di stile. I classificatori di testo AI possono etichettare erroneamente la scrittura tecnica, soprattutto quando i ricercatori usano modelli o scrivono in una seconda lingua.
Un sistema di raccolta migliore verifica la sostanza del report. Può richiedere una riproduzione minima, dettagli dell’ambiente, commit interessati, prova della raggiungibilità e una spiegazione diretta delle capacità dell’attaccante.
La sospensione del Google OSS VRP dà all’azienda il tempo di progettare tali filtri. Il rischio è che un sistema più rigido escluda anche nuovi ricercatori qualificati che non hanno reputazione ma dispongono di una scoperta valida.
Questo compromesso non può scomparire. I programmi aperti attirano scoperte inattese perché chiunque può partecipare. Limitare l’accesso migliora la qualità media, riducendo però la probabilità che un ricercatore sconosciuto raggiunga il team giusto.
GitHub e i maintainer open source stanno restringendo lo stesso accesso
La decisione di Google rientra in un cambiamento che coinvolge l’intero settore: dalla raccolta aperta verso reputazione, evidenze e canali di invio più ristretti.
GitHub ha affrontato nel 2026 una propria coda di report a basso sforzo e generati dall’AI. Ha risposto ristrutturando il suo programma di bug bounty e creando percorsi separati per ricercatori pubblici e su invito.
Il programma pubblico ha aggiunto un requisito di segnale HackerOne, che utilizza lo storico precedente di un ricercatore sulla piattaforma come misura di idoneità. Il programma su invito offre un percorso distinto per ricercatori con una fiducia consolidata.
GitHub ha dichiarato che il suo obiettivo era ridurre il volume di invii a basso sforzo preservando al contempo la ricerca esterna seria. Il suo annuncio della ristrutturazione ha applicato la nuova struttura ai report inviati dal 27 luglio 2026.
Le linee guida precedenti spiegavano quali evidenze la piattaforma considerasse utili. Un report solido richiedeva un riepilogo conciso, passaggi di riproduzione con artefatti di supporto e una dichiarazione chiara dell’impatto ottenibile da un attaccante.
GitHub ha inoltre avvertito che le narrazioni teoriche e il riempitivo generato dall’AI rallentavano il triage. Il problema non era soltanto il contenuto impreciso. Una spiegazione eccessiva poteva nascondere la scoperta effettiva e ritardare la revisione.
Google e GitHub hanno scelto risposte immediate diverse. GitHub ha mantenuto un percorso pubblico con filtri più rigorosi di reputazione e qualità. Google ha sospeso una categoria OSS VRP lasciando disponibili altri programmi per le vulnerabilità.
Entrambi gli approcci proteggono l’attenzione dei revisori. Creano anche attrito per i nuovi ricercatori che non hanno ancora costruito una reputazione sulle piattaforme. Un eccellente primo report può provenire da qualcuno senza una lunga storia nei bug bounty.
I maintainer open source affrontano una versione ancora più netta di questo problema. Molti progetti non dispongono di personale di sicurezza dedicato, team di triage retribuiti o infrastrutture formali per l’invio. Un maintainer può esaminare i report nel proprio tempo personale.
Le linee guida del settore attribuiscono sempre più responsabilità a entrambe le parti. L’Open Source Security Foundation consiglia ai ricercatori di verificare le scoperte, comprendere le politiche dei progetti e dichiarare chiaramente in che modo l’AI ha contribuito al lavoro.
Le sue linee guida per i maintainer riconoscono inoltre che l’AI può supportare un’analisi difensiva legittima. La risposta raccomandata si concentra su un’integrazione sicura e sulla revisione umana.
Il modello più ampio assomiglia al controllo dello spam. Quando l’invio diventa quasi gratuito, i destinatari devono introdurre filtri, segnali di reputazione, limiti di frequenza o costi di invio. Altrimenti, il volume di bassa qualità travolge le comunicazioni di valore.
I programmi di bug bounty non possono copiare esattamente i normali filtri antispam. I report di sicurezza contengono dettagli tecnici inediti e spesso arrivano da ricercatori sconosciuti. Rifiutare contenuti insoliti con eccessiva aggressività può nascondere la scoperta più importante.
I programmi probabilmente combineranno diversi controlli. I moduli strutturati possono imporre risposte concrete. I controlli automatizzati possono verificare l’esistenza degli artefatti richiesti. La reputazione può determinare limiti di invio anziché l’idoneità assoluta.
I limiti di frequenza potrebbero diventare particolarmente importanti per gli agenti autonomi. Una persona può esaminare diversi candidati generati da macchine e inviare soltanto i più solidi. Un sistema senza supervisione può inondare un programma prima che i maintainer forniscano un riscontro.
Depositi o cauzioni di invio rimborsabili creerebbero costi più elevati, ma sollevano preoccupazioni sull’accesso. I ricercatori nelle regioni a reddito più basso potrebbero incontrare barriere sproporzionate. Aumenterebbero anche la complessità legale e amministrativa.
I programmi privati o solo su invito evitano il volume pubblico ma perdono un’ampia partecipazione. Concentrano la fiducia tra ricercatori noti, rischiando di non intercettare esterni con conoscenze specialistiche di un componente particolare.
La riprogettazione di Google ha quindi implicazioni che vanno oltre una singola azienda. Altri operatori di programmi studieranno se riesce a ripristinare il segnale senza chiudere la porta ai nuovi talenti.
Filtri più rigidi possono anche nascondere vulnerabilità reali
Ridurre il rumore dell’AI è necessario, ma ogni filtro crea la possibilità che un report valido e non familiare non raggiunga mai l’ingegnere giusto.
Google ha descritto le ragioni della sospensione, ma non ha pubblicato dati completi sulle prestazioni. Gli osservatori esterni non possono confrontare i tassi di falsi positivi prima e dopo l’adozione dell’AI né misurare la reale gravità dell’arretrato.
Senza questi numeri, restano possibili diverse interpretazioni. Gli invii generati dall’AI potrebbero dominare la coda, oppure un gruppo più ristretto di segnalatori ripetitivi potrebbe creare la maggior parte dell’onere. Cause diverse richiedono controlli diversi.
Conta anche la qualità dei modelli sottostanti. Una politica progettata attorno agli attuali tassi di allucinazione potrebbe invecchiare rapidamente. Agenti migliori possono produrre riproduzioni più solide, ma possono anche generare un maggior volume di report.
La progettazione del programma deve distinguere la fiducia dalle evidenze. Un agente che assegna un’alta probabilità allo sfruttamento non ha dimostrato lo sfruttamento. Al contrario, un report incompleto può comunque descrivere una grave falla che merita un approfondimento.
I nuovi ricercatori spesso inviano report imperfetti perché non hanno esperienza nella divulgazione. La loro scrittura può somigliare a un output automatizzato di bassa qualità, anche quando l’osservazione di fondo è autentica.
Lingua e accessibilità creano rischi simili. Richiedere un inglese impeccabile può svantaggiare ricercatori dotati di profonde conoscenze tecniche. I moduli dovrebbero richiedere evidenze specifiche senza trasformare lo stile in un indicatore sostitutivo di credibilità.
I filtri basati sulla reputazione rafforzano anche l’accesso preesistente. I ricercatori affermati ricevono più opportunità per costruire segnale, mentre i nuovi arrivati faticano a entrare. Un circuito chiuso può migliorare l’efficienza ma indebolire la diversità.
L’automazione sul lato ricevente presenta un’altra incertezza. Google potrebbe utilizzare modelli per riassumere, deduplicare o dare priorità ai report. Questi sistemi richiedono audit perché un falso negativo comporta conseguenze diverse da un falso positivo.
Un falso positivo spreca il tempo dei revisori. Un falso negativo può lasciare una vulnerabilità non scoperta. I sistemi di raccolta dovrebbero quindi automatizzare l’instradamento e i controlli sulle evidenze più facilmente del rifiuto finale.
I ricorsi offrono una salvaguardia. Un ricercatore respinto dovrebbe comprendere quale elemento non ha superato il controllo e se ulteriori evidenze possano riaprire il report. I messaggi di rifiuto generici incoraggiano invii ripetuti e frustrazione pubblica.
Anche esempi trasparenti possono migliorare i comportamenti. I programmi possono pubblicare casi anonimizzati che mostrino codice irraggiungibile, affermazioni d’impatto non supportate, cause alla radice duplicate e riproduzioni accettabili.
Google offre già linee guida per la segnalazione nei suoi programmi di vulnerabilità. Il suo framework di qualità pone l’accento su informazioni sul target, riproducibilità, impatto e comunicazione.
La riprogettazione deve decidere se questi standard diventeranno prerequisiti applicati dalle macchine. Deve anche stabilire quali report meritino discrezionalità umana pur in assenza di un campo formale.
C’è un altro pericolo nel definire ogni invio indesiderato come materiale AI scadente. L’etichetta può oscurare reali disaccordi sui modelli di minaccia. Ricercatori e fornitori valutano spesso la sfruttabilità in modo diverso.
Un’azienda può respingere un problema perché un attaccante necessita dell’interazione dell’utente. Un ricercatore può sostenere che l’interazione resti realistica. Queste controversie precedono l’AI generativa e non possono essere risolte tramite il rilevamento dell’autorialità.
La stessa cautela vale per gli ordinari difetti del codice. Alcuni bug non hanno un impatto immediato ma diventano pericolosi dopo un’altra modifica al prodotto. I programmi hanno bisogno di confini, ma tali confini non dovrebbero essere scambiati per giudizi universali sulla gravità.
La sospensione è quindi un intervento di triage, non la prova che i repository interessati siano diventati più sicuri. Le vulnerabilità continuano a esistere mentre un canale di segnalazione resta chiuso.
I ricercatori devono individuare un altro canale appropriato o contattare direttamente il progetto pertinente. Percorsi di divulgazione frammentati possono aumentare ritardi, pubblicazioni accidentali e sforzi duplicati.
Google può ridurre questo rischio instradando chiaramente i report esclusi. La sua directory pubblica dei programmi separa già gli ambiti Google, Cloud, Chrome, Android, AI, abuso e open source.
La riprogettazione avrà successo solo se i ricercatori validi potranno prevedere la destinazione corretta. Una coda più piccola serve a poco se i report seri scompaiono tra regole sovrapposte di programmi diversi.
Cosa osservare prima che Google riapra le segnalazioni sui prodotti
Il prossimo test sarà stabilire se Google sostituirà una casella di invio aperta con un sistema che verifica le evidenze senza mettere a tacere ricercatori non familiari.
Il primo segnale è l’aggiornamento promesso entro il primo trimestre del 2027. Google dovrebbe chiarire se gli invii relativi a vulnerabilità dei prodotti riapriranno, saranno spostati altrove o torneranno tramite un processo ad accesso limitato.
Una riapertura con requisiti strutturati sulle evidenze sosterrebbe l’idea che la sospensione fosse un triage temporaneo. Una chiusura indefinita mostrerebbe che Google non considera più sostenibile il precedente modello pubblico.
Il secondo segnale è la progettazione del filtro di raccolta. Riproduzioni obbligatorie, versioni interessate, commit testati, tracce di esecuzione e dichiarazioni concise sull’impatto affronterebbero direttamente le modalità di fallimento documentate.
Le restrizioni basate esclusivamente sulla reputazione rappresenterebbero una scelta diversa. Potrebbero ridurre rapidamente il volume, ma attribuirebbero più peso alla storia del ricercatore che alle evidenze contenute in ciascun report.
Il trattamento riservato da Google agli agenti autonomi sarà particolarmente importante. L’azienda potrebbe richiedere a una persona nominata di attestare che ogni invio è stato riprodotto. Potrebbe anche imporre limiti di frequenza alle segnalazioni assistite da macchine.
Una politica significativa dovrebbe distinguere l’assistenza AI dall’invio di massa non supervisionato. I ricercatori usano abitualmente automazione, debugger, fuzzer, scanner e modelli linguistici. La questione decisiva è chi convalida e si assume la responsabilità dell’affermazione.
Il terzo segnale è se l’arretrato migliorerà senza ridurre le scoperte confermate. Google non ha rilasciato dati sufficienti per questo confronto, ma una futura trasparenza aiuterebbe altri programmi a imparare dalla riprogettazione.
Metriche utili includerebbero volume degli invii, tempo di convalida, tassi di duplicazione, scoperte accettate, ricorsi dei segnalatori e quota di report contenenti riproduzioni funzionanti. Dati aggregati potrebbero proteggere i dettagli sensibili.
I ricercatori dovrebbero inoltre tenere d'occhio gli altri VRP di Google. Se segnalazioni di bug AI non valide dovessero migrare verso Cloud, Chrome o i canali generali di Google, la sospensione avrà solo spostato il carico di lavoro invece di risolverlo.
Il più ampio sistema di bug bounty dell'azienda rimane attivo. La directory dei programmi di Google continua a indirizzare i problemi di sicurezza idonei verso diversi programmi specializzati.
I maintainer esterni a Google non dovrebbero attendere la policy definitiva. Possono definire le prove accettate, pubblicare modelli di minaccia, limitare gli invii automatizzati e creare template che separino le osservazioni dall'impatto dedotto.
Anche i ricercatori possono adattarsi. Prima di inviare una segnalazione, dovrebbero riprodurre il comportamento, ridurre al minimo il caso di test, confermare la revisione interessata e spiegare l'accesso necessario a un attaccante.
Dovrebbero rimuovere il contesto generato che non supporta la scoperta. Una segnalazione breve con prove dirette è più facile da convalidare di un saggio curato costruito su una premessa incerta.
La ricerca sulla sicurezza assistita dall'AI continuerà a espandersi, perché i suoi benefici legittimi sono considerevoli. I modelli possono analizzare più codice, generare test mirati e aiutare gli investigatori a collegare componenti poco familiari.
Tuttavia, il volume delle scoperte non è più la migliore misura del progresso. Una segnalazione diventa utile solo quando fornisce ai maintainer prove sufficientemente affidabili per intervenire.
La sospensione del VRP OSS di Google segna il momento in cui questa distinzione è diventata impossibile da ignorare. Il prossimo design del programma dovrà premiare le intuizioni verificate, preservare l'accesso e mantenere l'attenzione umana concentrata sul rischio reale.
Prima di inviare un'altra scoperta assistita dall'AI, ponetevi una domanda più difficile rispetto a quella se il modello abbia trovato codice sospetto: un altro ingegnere può riprodurre l'impatto sulla sicurezza a partire dalle prove fornite?
