Google sospende il Bug Bounty Open Source mentre le segnalazioni AI travolgono i revisori

Google ha sospeso il suo bug bounty open source dopo un'ondata di segnalazioni automatizzate, affermando che la stragrande maggioranza era non valida. La sospensione è iniziata il 1° ottobre 2026 e riguarda le nuove segnalazioni di vulnerabilità dei prodotti inviate all'Open Source Software Vulnerability Reward Program.

La decisione crea una netta contraddizione per la ricerca sulla sicurezza assistita dall'AI. I modelli possono ora ispezionare più codice e produrre segnalazioni convincenti a una velocità senza precedenti. Eppure, ogni invio richiede ancora una persona che stabilisca se la falla dichiarata esista, sia rilevante e possa essere riprodotta.

Google non è sola. Curl ha terminato le ricompense monetarie dopo che il suo tasso di vulnerabilità confermate è sceso sotto il 5% nel 2025. Anche i manutentori del kernel Linux hanno modificato le pratiche di divulgazione dopo aver ricevuto ondate di risultati AI duplicati. Nel complesso, questi casi mostrano che la scoperta delle vulnerabilità è cresciuta più rapidamente della loro revisione.

Il Bug Bounty Open Source di Google smette di accettare segnalazioni sui prodotti

Google ha temporaneamente chiuso un importante canale di ricezione perché gli invii automatizzati generavano più lavoro di revisione che risultati di sicurezza utili.

Il Google OSS VRP, abbreviazione di Open Source Software Vulnerability Reward Program, ricompensa i ricercatori che divulgano responsabilmente falle di sicurezza in progetti open source idonei. Google ha lanciato il programma nel 2022 per coprire il software mantenuto nei suoi repository pubblici e in determinati progetti esterni.

Quel canale per le vulnerabilità dei prodotti ha smesso di accettare nuove segnalazioni il 1° ottobre. Google ha dichiarato di prevedere un nuovo aggiornamento nel corso del primo trimestre del 2027.

“Questa pausa è dovuta a un significativo aumento degli invii automatizzati, la stragrande maggioranza dei quali non è valida”, ha dichiarato Google nel suo avviso. La formulazione è importante perché distingue l'automazione dalla ricerca sulle vulnerabilità verificata.

La pausa non annulla le segnalazioni inviate prima della scadenza. Non chiude neppure ogni percorso associato al programma più ampio. Le segnalazioni di vulnerabilità nella supply chain restano idonee, secondo le regole del programma aggiornate.

Alcune vulnerabilità che coinvolgono repository Google Cloud possono ancora qualificarsi tramite il Cloud VRP. Google ha inoltre indirizzato i ricercatori verso gli altri suoi programmi di ricompensa mentre riesamina il processo di ricezione delle segnalazioni open source.

Questa portata più ristretta rende “congelamento” più accurato di “chiusura”. Google ha sospeso le nuove segnalazioni di vulnerabilità dei prodotti all'interno del programma OSS, non ha abbandonato la ricerca di sicurezza esterna in tutta l'azienda.

L'azienda non ha pubblicato un numero di invii, un tasso di segnalazioni non valide o l'arretrato totale di triage per il canale interessato. Le affermazioni secondo cui i revisori avrebbero ricevuto un numero specifico di segnalazioni errate restano quindi non verificate.

Ciò che Google ha divulgato è il segnale decisivo. Le segnalazioni automatizzate erano diventate abbastanza numerose e inaffidabili da rendere insostenibile il processo esistente.

Quel processo dipende da molto più della ricezione di un documento ben confezionato. Un revisore deve ispezionare il percorso del codice, ricreare le condizioni, valutare la sfruttabilità, cercare duplicati e identificare il team responsabile del progetto.

Una segnalazione plausibile può richiedere molto tempo anche quando è errata. I modelli linguistici di grandi dimensioni rendono il problema più difficile perché possono produrre spiegazioni dettagliate, frammenti di codice e affermazioni sicure sulla gravità senza dimostrare la vulnerabilità sottostante.

Google aveva già irrigidito le sue regole all'inizio del 2026 dopo aver osservato un “massiccio aumento” delle segnalazioni generate dall'AI. La pausa di ottobre suggerisce che i soli requisiti di filtraggio non siano riusciti a ripristinare un rapporto segnale-rumore accettabile.

Il bug bounty open source di Google è quindi diventato un caso di prova per un problema di sicurezza più ampio. Generare un'affermazione è ora economico, mentre confutarla resta costoso.

Perché le segnalazioni di bug AI creano un costo asimmetrico

L'AI cambia l'economia della divulgazione perché una macchina può generare segnalazioni più rapidamente di quanto i manutentori possano convalidarle.

La tradizionale ricerca di bug impone costi significativi al ricercatore. Una persona deve comprendere una base di codice, isolare un comportamento inatteso, verificare se generi un impatto sulla sicurezza e documentare un caso riproducibile.

L'AI generativa riduce parte di quel carico di lavoro. Un agente può analizzare repository, seguire funzioni, confrontare schemi, preparare codice proof-of-concept e trasformare risultati preliminari in segnalazioni dall'aspetto professionale.

Queste capacità possono aiutare i ricercatori legittimi. Possono anche consentire a utenti inesperti di inviare affermazioni che non comprendono e che non sono in grado di sostenere durante le domande successive.

L'asimmetria emerge dopo l'invio. Produrre un'altra segnalazione può richiedere poco sforzo aggiuntivo, ma il suo triage continua a consumare una preziosa attenzione ingegneristica.

Christopher Robinson, chief technology officer della Open Source Security Foundation, ha descritto questo onere in un rapporto sulla sicurezza di marzo. I progetti popolari ricevevano in passato due o tre segnalazioni in una settimana media, ha stimato. Alcuni ne hanno poi ricevute centinaia tutte insieme.

Robinson ha affermato che una singola segnalazione può richiedere da due a otto ore di lavoro non pianificato da parte di un manutentore. Questo costo esiste anche quando la risposta finale è che non esiste alcuna vulnerabilità.

I falsi positivi non sono l'unico problema. I sistemi automatizzati possono inviare scoperte duplicate, interpretare erroneamente comportamenti documentati, ignorare i modelli di minaccia o esagerare difetti a basso impatto.

Una vulnerabilità allucinata è particolarmente costosa perché la segnalazione può apparire internamente coerente. I revisori possono seguire una dettagliata argomentazione tecnica prima di scoprire che una funzione, un percorso di controllo o una condizione di sfruttamento citati sono stati inventati.

Vlad Ionescu, cofondatore dell'azienda di sicurezza AI RunSybil, ha descritto questa esperienza in una precedente indagine sull'AI slop. Ha affermato che le segnalazioni possono apparire tecnicamente solide finché i revisori non indagano e scoprono che il modello ha fabbricato i dettagli.

Questo crea un collo di bottiglia nella verifica. L'AI amplia l'offerta di possibili risultati, ma non aumenta automaticamente il numero di revisori affidabili.

I bug bounty creano inoltre un incentivo finanziario a inviare affermazioni incerte. Un ricercatore può inviare molte segnalazioni speculative mentre i manutentori assorbono la maggior parte del costo di convalida.

I sistemi reputazionali e i limiti di frequenza possono ridurre gli abusi, ma introducono compromessi propri. Filtri rigidi possono escludere nuovi ricercatori privi di cronologia sulla piattaforma ma in possesso di una scoperta legittima.

I requisiti di identità possono scoraggiare la divulgazione responsabile da parte di persone esposte a rischi legali, professionali o geografici. Le commissioni di invio creerebbero una barriera ancora più grande.

Lo screening automatizzato presenta un'altra complicazione. Un filtro che rifiuta le segnalazioni perché sembrano generate da una macchina può scartare vulnerabilità autentiche trovate o documentate con l'assistenza dell'AI.

La distinzione essenziale non è se l'AI abbia contribuito alla segnalazione. È se chi la invia abbia verificato il comportamento e possa sostenere l'affermazione con prove riproducibili.

Questo standard diventa più difficile da applicare quando gli agenti possono creare documenti persuasivi su larga scala. La qualità del testo non fornisce più un segnale affidabile della qualità della ricerca.

La risposta pratica probabilmente comporterà requisiti probatori più rigorosi. I programmi possono richiedere riproduzioni minime, dettagli sulla versione interessata, tracce di exploit, casi di test o patch funzionanti prima di assegnare una revisione umana.

Questi requisiti riportano parte del costo di verifica sul mittente. Favoriscono inoltre i ricercatori che comprendono il codice e restano disponibili a rispondere alle domande.

Il problema delle segnalazioni di bug AI di Google è anche un successo della sicurezza AI

La stessa tecnologia che crea invii di bassa qualità sta individuando vulnerabilità reali sfuggite ai ricercatori umani.

Considerare ogni segnalazione assistita dall'AI come spazzatura sarebbe un'interpretazione errata delle prove. I modelli avanzati hanno dimostrato capacità significative di analisi del codice in condizioni controllate.

Anthropic ha dichiarato che Claude Opus 4.6 ha individuato più di 500 vulnerabilità precedentemente sconosciute in progetti open source durante test interni. Secondo l'azienda, ricercatori umani o esterni di sicurezza hanno convalidato ogni scoperta prima della divulgazione.

Mozilla ha ricevuto 112 segnalazioni da questo sforzo nell'arco di due settimane. Ha emesso 22 avvisi di sicurezza, di cui 14 per falle ad alta gravità, classificando molti dei risultati rimanenti come bug non legati alla sicurezza.

Questi risultati illustrano un processo diverso dall'invio automatizzato di massa. Anthropic ha affiancato la scoperta automatica alla convalida umana, alla divulgazione coordinata e a una comunicazione mirata con i manutentori.

In un caso, il modello avrebbe creato un proof of concept per dimostrare che una presunta falla era reale. Quel passaggio trasforma uno schema speculativo in prove che i revisori possono verificare.

Le scoperte relative a Firefox mostrano inoltre perché vietare del tutto la ricerca AI sarebbe controproducente. I modelli possono esaminare codice maturo e ampiamente testato e continuare a far emergere difetti rilevanti.

Il conflitto, quindi, non è tra esseri umani e AI. È tra ricerca verificata e generazione di segnalazioni priva di responsabilità.

Un flusso di lavoro assistito dall'AI di alta qualità mantiene un responsabile umano. Questa persona verifica l'output, rimuove i falsi positivi, comprende l'impatto e si assume la responsabilità di comunicare con i manutentori.

Un flusso di lavoro di bassa qualità tratta l'endpoint di divulgazione come un'altra destinazione automatizzata. L'agente identifica uno schema, redige una narrativa sulla gravità e la invia senza riproduzione indipendente.

Entrambi i flussi di lavoro possono produrre testi curati. Solo uno riduce il carico di lavoro del destinatario.

Questa distinzione spiega perché la pausa di Google non dimostra che la ricerca di bug AI abbia fallito. Mostra che la sua architettura di invio non poteva assorbire l'attuale miscela di risultati preziosi, duplicati e allucinazioni.

La sicurezza assistita dall'AI potrebbe alla fine migliorare entrambi i lati di questa architettura. I programmi possono usare modelli per raggruppare i duplicati, confrontare le affermazioni con problemi noti, testare percorsi di exploit e identificare prove mancanti.

HackerOne e altre piattaforme hanno iniziato a introdurre assistenza al triage basata sull'AI. Questi strumenti possono dare priorità alle segnalazioni, ma le loro prestazioni devono essere misurate rispetto ai tassi di falsi rifiuti e vulnerabilità non individuate.

Anche un revisore automatizzato può allucinare. Se i programmi collocano un modello tra ricercatori e manutentori, hanno bisogno di percorsi di escalation per i risultati che il filtro non può classificare con sicurezza.

Il modello più solido è probabilmente stratificato. Le macchine svolgono controlli economici, triager esperti esaminano le segnalazioni sopravvissute e i manutentori del progetto gestiscono solo i risultati credibili.

Questo approccio ricorda l'integrazione continua per i contributi software. I test respingono gli errori evidenti prima che un manutentore dedichi tempo a una revisione dettagliata.

Le affermazioni di sicurezza restano più difficili da testare rispetto alle normali modifiche al codice. La sfruttabilità dipende dal contesto, dalla configurazione, dai confini di fiducia e dalle capacità dell'attaccante, che i controlli automatizzati possono interpretare erroneamente.

Ciononostante, richiedere prove verificabili automaticamente può migliorare il livello di base. Una segnalazione con un test fallito, una traccia di esecuzione o un arresto anomalo riproducibile offre ai revisori qualcosa di concreto da valutare.

Anche le organizzazioni hanno bisogno di registri duraturi per questo lavoro. Una base di conoscenza ingegneristica consultabile può aiutare i team a confrontare nuove scoperte con rapporti, decisioni e correzioni precedenti.

L’obiettivo non è rallentare le scoperte legittime. È impedire che una generazione illimitata consumi un budget limitato di revisione umana.

Curl e Linux dimostrano che è un problema di settore

La sospensione di Google segue un modello in cui i progetti open source restringono i canali di segnalazione dopo che l’AI ha sovraccaricato i sistemi di fiducia esistenti.

Curl offre l’esempio precedente più chiaro. Il progetto di trasferimento dati, molto diffuso, ha concluso il proprio programma di bug bounty con premi in denaro il 31 gennaio 2026, dopo averlo gestito dal 2019.

Il manutentore Daniel Stenberg ha dichiarato che il programma aveva prodotto 87 vulnerabilità confermate. Tuttavia, la tendenza della qualità è peggiorata drasticamente nel corso del 2025.

In precedenza Curl confermava come vulnerabilità oltre il 15% delle segnalazioni. Il tasso è sceso sotto il 5% nel 2025, il che significa che meno di una segnalazione su venti si è rivelata valida.

Stenberg ha attribuito il fenomeno a tre tendenze collegate: contenuti AI di scarsa qualità, un calo qualitativo nelle altre segnalazioni e ricercatori concentrati sui premi anziché sul miglioramento del progetto.

«Le segnalazioni spazzatura senza fine impongono un pesante costo mentale da gestire», ha scritto annunciando la decisione di curl.

Curl non ha smesso di accettare segnalazioni di sicurezza. Ha eliminato i premi in denaro, mantenuto HackerOne come canale raccomandato e indirizzato i ricercatori verso segnalazioni private su GitHub o email.

Quella risposta mirava agli incentivi, non alla tecnologia in sé. Stenberg ha sostenuto che i premi attiravano scoperte legittime, ma rendevano anche troppo facile inviare segnalazioni speculative.

Ha riconosciuto il compromesso. Eliminare i pagamenti può ridurre il rumore, ma può anche indebolire gli incentivi per ricercatori indipendenti esperti che dedicano molto tempo a indagini difficili.

La comunità del kernel Linux ha affrontato un problema correlato riguardante le scoperte duplicate. Più ricercatori hanno eseguito strumenti AI simili sullo stesso codice e inviato gli stessi problemi attraverso un canale privato.

La divulgazione privata impediva ai ricercatori di vedere che un’altra persona aveva già segnalato o discusso una scoperta. I manutentori reindirizzavano ripetutamente i duplicati o indicavano correzioni già disponibili pubblicamente.

Linus Torvalds ha descritto la mailing list privata sulla sicurezza come «quasi interamente ingestibile». Ha sostenuto che le scoperte rilevate dall’AI dovrebbero generalmente passare attraverso i canali pubblici del progetto, salvo quando la riservatezza sia davvero necessaria.

La documentazione Linux ha inoltre alzato lo standard atteso dai segnalanti. I ricercatori dovrebbero fornire prove concise, contattare i manutentori pertinenti e contribuire con una patch quando possibile.

Questa politica preserva la responsabilità umana. L’AI può assistere nella scoperta, ma una persona deve comprendere la segnalazione e restare responsabile delle sue conseguenze.

Google, curl e Linux hanno scelto interventi diversi perché i loro programmi hanno strutture differenti. Google ha sospeso una categoria di invio. Curl ha eliminato i premi. Linux ha reindirizzato molte segnalazioni e sottolineato la gestione pubblica.

La loro conclusione condivisa è più importante dei dettagli delle singole politiche. L’accettazione aperta senza costi significativi per l’invio non funziona quando gli agenti automatizzati possono generare affermazioni quasi illimitate.

I progetti più piccoli affrontano il rischio maggiore. Google può assegnare ingegneri e riprogettare l’infrastruttura, mentre i manutentori volontari potrebbero non disporre di un team dedicato al triage.

Il software open source è spesso integrato in prodotti commerciali, servizi cloud, strumenti di sviluppo e sistemi critici. Tuttavia, la responsabilità di esaminare le segnalazioni di sicurezza può ricadere su pochi contributori non retribuiti.

L’AI amplifica questo squilibrio. Consente a soggetti esterni di analizzare continuamente codice importante senza fornire il lavoro necessario per convalidare, correggere e coordinare ogni possibile scoperta.

Il risultato assomiglia a un problema di denial-of-service, anche quando chi invia le segnalazioni ha buone intenzioni. Ogni rapporto chiede ai manutentori di dedicare attenzione, e il volume complessivo può sottrarre spazio alle vulnerabilità autentiche.

Controlli più severi possono anche nascondere vulnerabilità reali

I programmi devono ridurre il volume di bassa qualità senza creare un sistema di sicurezza accessibile soltanto ai ricercatori già affermati.

La sospensione di Google protegge i revisori nel breve termine, ma rimuove anche un percorso di segnalazione per scoperte legittime. Una vulnerabilità valida in un prodotto individuata dopo il 1° ottobre potrebbe richiedere un altro programma idoneo o canale di divulgazione.

Questo attrito conta perché i ricercatori non comprendono sempre i confini organizzativi di un’azienda. Un difetto in un repository open source può interessare un prodotto cloud, una dipendenza o un’applicazione a valle.

Regole di instradamento complicate aumentano il rischio di divulgazioni ritardate o indirizzate erroneamente. Possono anche incoraggiare la pubblicazione pubblica quando i ricercatori non riescono a individuare un canale privato accettato.

L’accesso basato sulla reputazione crea un altro rischio. È più facile fidarsi di ricercatori esperti, ma i nuovi partecipanti hanno storicamente contribuito con scoperte importanti ai programmi di bounty.

Un sistema che favorisce identità consolidate può riprodurre le disuguaglianze di accesso esistenti. Potrebbe svantaggiare ricercatori indipendenti, studenti e persone esterne alle principali comunità di sicurezza.

Anche requisiti rigorosi per le proof-of-concept possono diventare rischiosi. Dimostrare la sfruttabilità può richiedere la gestione di dati reali, l’aggiramento delle protezioni o test che violano le regole del programma.

I programmi necessitano quindi di standard probatori robusti ma sicuri. Un riproduttore minimo, un test controllato o un percorso di codice dettagliato possono stabilire credibilità senza richiedere uno sfruttamento dannoso.

Inoltre, non esiste un rilevatore affidabile per la scrittura generata dall’AI. I ricercatori usano comunemente modelli per traduzione, editing, spiegazione del codice o formattazione anche quando il lavoro sottostante è legittimo.

Rifiutare le segnalazioni in base allo stile punirebbe una divulgazione accurata e incentiverebbe a nascondere l’uso dell’AI. Non stabilirebbe se il difetto segnalato sia reale.

La dichiarazione pubblica di Google lascia senza risposta diverse domande. L’azienda non ha rivelato quali misure di screening abbiano fallito, quante scoperte legittime siano state coinvolte nell’ondata o quale riprogettazione stia valutando.

Non è inoltre chiaro se la sospensione terminerà con maggiore automazione, soglie probatorie più elevate, accesso limitato o un diverso modello di ricompensa.

La mancanza di numeri limita la valutazione esterna. «La stragrande maggioranza» comunica la gravità, ma non rivela se la validità sia scesa solo leggermente sotto una soglia esistente o sia quasi completamente crollata.

I lettori dovrebbero anche evitare di trattare l’esperienza di Google come universale. Mozilla aveva precedentemente dichiarato che il proprio tasso di rifiuto delle segnalazioni non valide era rimasto stabile in un periodo precedente, nonostante le più ampie preoccupazioni del settore.

La progettazione del programma, la visibilità del progetto, gli incentivi delle ricompense e le regole di invio incidono tutti sul volume e sulla qualità delle segnalazioni. Una politica che funziona per un progetto può fallire per un altro.

Anche i sistemi AI stanno cambiando rapidamente. Modelli migliori possono produrre falsi positivi più convincenti, ma possono anche generare prove più solide e ridurre le allucinazioni.

Questo doppio movimento rende fragili le regole statiche. I programmi hanno bisogno di controlli di qualità misurabili che valutino le prove anziché indovinare quale strumento le abbia prodotte.

Per i responsabili della sicurezza, la metrica centrale non dovrebbe essere il volume grezzo delle segnalazioni. Misure utili includono il tasso di vulnerabilità confermate, il tasso di duplicati, il tempo mediano di triage, il tempo di correzione e il carico di lavoro dei revisori.

Un programma può ricevere più segnalazioni diventando al contempo meno efficace. Al contrario, un’accettazione più rigorosa può ridurre il volume aumentando la quota di scoperte gravi che raggiungono i manutentori.

La sospensione dell’OSS VRP di Google dovrebbe quindi essere valutata in base a ciò che la sostituirà. Chiudere una coda sovraccarica è comprensibile, ma un risultato di sicurezza duraturo richiede un percorso affidabile per le segnalazioni valide.

Cosa succederà ora al bug bounty open source di Google

Tre segnali riveleranno se la sospensione di Google diventerà un sistema di divulgazione migliore o un ritiro duraturo dalla partecipazione aperta.

Il primo segnale è l’aggiornamento promesso da Google durante il primo trimestre del 2027. I dettagli più importanti riguarderanno l’idoneità, gli standard probatori, lo screening automatizzato e le procedure di ricorso.

Una riapertura con chiari requisiti di riproduzione rafforzerebbe l’ipotesi che Google abbia usato la sospensione per riprogettare l’accettazione. Una proroga indefinita suggerirebbe che l’invio aperto resti economicamente difficile.

Occorre osservare se Google richiederà ai segnalanti di fornire test eseguibili, commit interessati, tracce di sfruttamento o correzioni proposte. Tali regole sposterebbero la responsabilità verso i ricercatori senza vietare l’assistenza dell’AI.

Il secondo segnale è il tasso di segnalazioni confermate dopo un’eventuale riapertura. Google non ha pubblicato una base di riferimento attuale, quindi la trasparenza sui futuri tassi di validità e duplicazione aiuterebbe a valutare il nuovo sistema.

Un tasso di conferma più alto con un accesso stabile alla divulgazione sosterrebbe l’utilità di filtri più severi. Un forte calo della partecipazione potrebbe indicare che i controlli stiano escludendo ricercatori legittimi insieme allo spam.

Anche il tempo di triage è importante. Se i revisori possono valutare più rapidamente le segnalazioni credibili, Google avrà la prova che la riprogettazione ha ridotto il lavoro nascosto anziché limitarsi a ridurre il volume visibile.

Il terzo segnale è il modo in cui reagiranno altri progetti e piattaforme. Curl ha eliminato i premi, Linux ha reindirizzato le scoperte automatizzate e Google ha sospeso una categoria di invio.

Se più programmi adotteranno riproduzioni verificate, requisiti di patch o soglie reputazionali, tali pratiche potrebbero diventare lo standard per la divulgazione assistita dall’AI.

Le piattaforme potrebbero anche costruire difese condivise. Il rilevamento dei duplicati tra programmi, prove standardizzate leggibili dalle macchine e identità di agenti responsabili potrebbero ridurre il lavoro ripetuto.

L’esito più costruttivo separerebbe la scala della scoperta dalla scala dell’invio. I ricercatori potrebbero eseguire agenti su larga scala, ma solo le scoperte convalidate e deduplicate entrerebbero nelle code di revisione umana.

Quel modello richiede responsabilità a ogni passaggio. Gli sviluppatori di strumenti devono progettare per la verifica, i ricercatori devono testare le scoperte, le piattaforme devono filtrare con attenzione e i manutentori hanno bisogno di percorsi di escalation chiari.

Gli sviluppatori che usano strumenti di sicurezza AI dovrebbero già comportarsi come se tali regole esistessero. Dovrebbero riprodurre ogni affermazione, comprendere il codice interessato, verificare la cronologia pubblica dei problemi e documentare un impatto realistico.

Dovrebbero inoltre restare disponibili dopo l’invio. Un segnalante che non sa rispondere a domande tecniche fondamentali trasferisce al progetto l’intero costo dell’indagine.

Per le aziende, la lezione va oltre i bug bounty. Qualsiasi sistema di accettazione pubblica può sovraccaricarsi quando l’AI rende economica la generazione di contenuti e la valutazione resta costosa.

Code di assistenza, candidature di lavoro, programmi di sovvenzioni, pull request e rapporti di conformità affrontano lo stesso squilibrio di base. La risorsa scarsa non è più la scrittura. È la revisione affidabile.

La sospensione del bug bounty open source di Google rende visibile questo squilibrio in un contesto ad alta posta in gioco. Una falsa segnalazione di sicurezza fa perdere tempo, mentre una vulnerabilità reale non rilevata può esporre milioni di utenti a valle.

La sfida non è scegliere tra AI e ricercatori umani. È progettare un sistema di divulgazione in cui l’automazione aumenti il lavoro di sicurezza verificato anziché moltiplicare affermazioni non supportate.

Google ha ora tempo fino al prossimo aggiornamento per mostrare come appare quel sistema. Riaprirà con controlli probatori più robusti e un accesso significativo, oppure la partecipazione aperta continuerà a restringersi con l’aumentare del volume delle segnalazioni?