La sospensione dell'OSS VRP di Google dimostra che le segnalazioni di bug dell'IA hanno un problema di verifica
Google ha sospeso una categoria del proprio programma per le vulnerabilità open source il 1° ottobre, dopo che segnalazioni non valide generate dall'IA avrebbero sommerso il suo processo di revisione.
La sospensione dell'OSS VRP di Google blocca le nuove segnalazioni di “Product Vulnerability” mentre l'azienda riprogetta quella parte del programma. Google prevede di fornire un aggiornamento nel primo trimestre del 2027.
La decisione non chiude tutti i programmi di Google dedicati alle vulnerabilità. Né vieta ai ricercatori di usare l'intelligenza artificiale per analizzare il codice.
Piuttosto, mette in luce un conflitto crescente tra scoperta automatizzata e verifica umana. L'IA può generare potenziali risultati molto più rapidamente di quanto i maintainer riescano a riprodurli, valutarli e correggerli.
L'azione di Google segue mesi di pressione crescente nella sicurezza open source. I maintainer del kernel Linux e di altri progetti hanno affrontato ondate simili di segnalazioni duplicate, speculative o sottoposte a test insufficienti.
Questo schema più ampio conta più di un singolo modulo di invio sospeso. Tradizionalmente, i programmi di sicurezza premiano i ricercatori che individuano problemi sfuggiti ai team interni. L'IA cambia tale modello rendendo insolitamente economica la generazione di candidati.
La risorsa scarsa non è più il sospetto iniziale. È l'attenzione degli esperti necessaria per dimostrare che una falla è raggiungibile, sfruttabile e rilevante per un modello di minaccia reale.
Cosa cambia realmente con la sospensione dell'OSS VRP di Google
Google ha sospeso una categoria di segnalazioni, non ha abbandonato la ricerca sulle vulnerabilità open source né ha chiuso l'intera operazione di bounty.
L'Open Source Software Vulnerability Reward Program, noto come OSS VRP, copre problemi di sicurezza idonei nei repository open source di proprietà di Google. Google ha introdotto il programma nel 2022.
Le segnalazioni di vulnerabilità di prodotto identificano difetti nel codice, nella logica o nel design di un progetto. Una segnalazione valida deve fare più che indicare codice sospetto.
In genere, i ricercatori devono mostrare una versione interessata, un percorso di esecuzione raggiungibile, passaggi per la riproduzione e una conseguenza di sicurezza significativa. Questi requisiti distinguono le vulnerabilità sfruttabili dai normali errori di programmazione.
Secondo i dettagli della sospensione, la pausa è entrata in vigore quando Google l'ha annunciata il 1° ottobre. Le segnalazioni di vulnerabilità di prodotto inviate prima di tale data restano idonee alla revisione.
Anche le segnalazioni relative alla supply chain restano aperte. Queste riguardano compromissioni che incidono sul modo in cui dipendenze software, codice sorgente, build o rilasci raggiungono gli utenti.
Alcune vulnerabilità che interessano prodotti Google Cloud possono ancora essere idonee attraverso il Cloud VRP separato. L'idoneità dipende dal repository e dal suo collegamento a un prodotto cloud coperto.
I ricercatori possono inoltre partecipare agli altri programmi di ricompensa di Google. Questi includono programmi che coprono Chrome, Android, dispositivi Google, servizi cloud e specifici problemi di sicurezza dell'IA.
Questa distinzione di ambito è importante. Definire la misura una chiusura completa esagererebbe l'evento e oscurerebbe la risposta più mirata di Google.
L'azienda sta di fatto chiudendo un canale di acquisizione ad alto volume, lasciando però disponibili canali più ristretti. Prevede di riformattare quel canale prima di discuterne il futuro.
La sostituzione precisa resta sconosciuta. Google non ha spiegato pubblicamente se introdurrà requisiti più stringenti in materia di identità, riproduzione, frequenza o prove.
Google aveva già inasprito il programma prima della sospensione. Le sue regole dell'OSS VRP richiedevano ai ricercatori di convalidare i risultati assistiti dall'IA e dimostrare un impatto effettivo sulla sicurezza.
Le regole descrivevano diversi problemi ricorrenti. Alcune segnalazioni generate dall'IA includevano condizioni di attivazione errate o dettagli tecnici inventati.
Altre segnalazioni identificavano veri errori di codice, ma non riuscivano a stabilirne le conseguenze per la sicurezza. Un buffer overflow, per esempio, potrebbe esistere soltanto in codice irraggiungibile o dietro un'efficace barriera di sicurezza.
Google ha inoltre eliminato le ricompense monetarie e il riconoscimento pubblico per alcune vulnerabilità di prodotto di livello inferiore e altri problemi di sicurezza. Tale cambiamento dell'aprile 2026 tentava di rimuovere gli incentivi per le segnalazioni a basso impatto.
La sospensione successiva suggerisce che tali controlli più circoscritti non abbiano ridotto a sufficienza il carico di revisione. Google è passata dal disincentivare le segnalazioni deboli al rifiutare temporaneamente la categoria.
La sospensione dell'OSS VRP di Google rappresenta quindi una decisione operativa. I revisori del programma non potevano più trattare ogni possibile segnalazione inviata come un punto di partenza sostenibile.
Le segnalazioni di bug dell'IA hanno cambiato il costo di formulare un'affermazione
L'IA riduce il costo di denunciare una vulnerabilità senza ridurre il costo di dimostrarla.
La ricerca tradizionale sulle vulnerabilità richiedeva un notevole impegno manuale prima che un ricercatore potesse produrre una segnalazione plausibile. Il ricercatore doveva esaminare il codice, comprendere i percorsi di esecuzione e costruire un test.
I moderni modelli linguistici e gli agenti autonomi per il codice possono analizzare repository e generare ipotesi molto più rapidamente. Possono anche produrre segnalazioni curate che somigliano a un'analisi umana approfondita.
Quell'apparenza crea una pericolosa asimmetria. Un documento convincente può essere generato in pochi secondi, mentre smentirne le affermazioni può richiedere ore di attenzione specialistica.
Una segnalazione potrebbe identificare un'operazione di memoria sospetta e prevedere l'esecuzione di codice remoto. Il modello può quindi costruire una dettagliata narrazione di attacco attorno a quella previsione.
Tuttavia, la funzione interessata potrebbe non elaborare mai input controllato da un attaccante. Il compilatore potrebbe eliminare il percorso, oppure una convalida esistente potrebbe bloccare l'innesco proposto.
Anche il modello di minaccia del progetto potrebbe escludere i privilegi dell'attaccante presunti. In ciascun caso, la segnalazione sembra seria senza riuscire a dimostrare una vulnerabilità.
I maintainer non possono rifiutare in sicurezza ogni segnalazione automatizzata a prima vista. Un invio scritto male può comunque contenere una falla reale, mentre un invio rifinito può essere interamente speculativo.
I revisori devono ispezionare il codice, ricreare l'ambiente, testare l'input dichiarato e valutare le difese esistenti. Potrebbero inoltre dover contattare il segnalante per ottenere prove mancanti.
Questo carico di lavoro cresce con ogni segnalazione, comprese quelle non valide. Gli invii automatizzati trasferiscono quindi il costo della convalida dai segnalanti ai maintainer.
L'effetto assomiglia più allo spam email che alla ricerca tradizionale sulla sicurezza. Inviare un altro messaggio costa quasi nulla, ma le organizzazioni riceventi devono comunque filtrare ogni affermazione potenzialmente importante.
Le ricompense finanziarie possono intensificare questo squilibrio. Se un singolo risultato accettato copre il costo di generare migliaia di invii, il volume diventa una strategia razionale per i partecipanti meno rigorosi.
Tale comportamento danneggia i ricercatori che svolgono un lavoro accurato. Le loro scoperte entrano nella stessa coda e competono per gli stessi revisori.
Danneggia inoltre gli utenti, quando i maintainer dedicano meno tempo alla correzione di vulnerabilità confermate. Il triage diventa il collo di bottiglia prima ancora che possa iniziare la mitigazione.
Il problema non è semplicemente che i modelli allucinano. Anche i ricercatori umani commettono errori, sovrastimano l'impatto e inviano duplicati.
L'IA cambia la scala, la velocità e la presentazione di questi fallimenti. Consente a una persona di produrre più affermazioni plausibili di quante quella stessa persona possa convalidare personalmente.
Questa distinzione spiega perché vietare il testo generato dall'IA risolverebbe ben poco. Un ricercatore potrebbe riscrivere un output del modello non verificato e inviare la stessa affermazione priva di prove.
I programmi hanno invece bisogno di barriere basate sulle prove. La domanda rilevante è se il segnalante abbia testato il risultato, non se un modello abbia contribuito alla sua scoperta.
La pausa di Google segnala che le sue regole esistenti non potevano far rispettare questa distinzione in modo efficiente. I requisiti scritti erano più facili da pubblicare che da applicare contro un volume industrializzato di segnalazioni.
La strategia di sicurezza IA di Google affronta ora il suo stesso compromesso
Google promuove la scoperta di problemi di sicurezza assistita dall'IA, ma il suo programma di ricompense non può assorbire ogni risultato prodotto dalla stessa ondata di automazione.
La sospensione dell'OSS VRP di Google non significa che l'azienda consideri l'IA inutile per la sicurezza. Google continua a investire nella scoperta e nella correzione automatizzate delle vulnerabilità.
I suoi team di sicurezza usano strumenti tra cui OSS-Fuzz, Big Sleep e CodeMender. Questi sistemi combinano analisi automatizzata con test controllati e revisione da parte di esperti.
Google ha inoltre rielaborato i suoi programmi di ricompensa per Android e Chrome in vista di quella che definisce l'era dell'IA. L'azienda si aspetta che l'automazione scopra vulnerabilità che la ricerca convenzionale non rileva.
Questo rende la sospensione una significativa inversione di rotta. Google non si sta ritirando dalla ricerca sulla sicurezza IA, ma sta limitando un canale esterno colpito dai minori costi di invio dell'IA.
La divisione centrale non è tra ricerca umana e ricerca delle macchine. È tra automazione convalidata internamente e affermazioni inviate dall'esterno con una convalida disomogenea.
Google controlla l'ambiente dei propri sistemi. Gli ingegneri possono definire i target, eseguire test, raccogliere crash e misurare se le patch generate preservano il comportamento.
Un programma di ricompense aperto non dispone di tale controllo. I partecipanti usano strumenti, prompt, modelli, versioni del codice e definizioni di impatto sulla sicurezza diversi.
I revisori ricevono l'affermazione finale senza vedere ogni passaggio che l'ha prodotta. Devono ricostruire le ipotesi mancanti prima di decidere se il risultato sia rilevante.
Questa differenza trasforma la provenienza in una questione pratica di sicurezza. I team devono sapere quale revisione sia stata testata, quale input abbia attivato il risultato e se un essere umano l'abbia riprodotto.
Il più ampio sistema di ricompense di Google resta consistente. L'azienda ha dichiarato che i suoi programmi hanno pagato più di 17 milioni di dollari a oltre 700 ricercatori nel 2025.
La sua revisione annuale del VRP ha descritto tale totale come un massimo storico. L'importo è aumentato di oltre il 40 percento rispetto al 2024.
Queste cifre mostrano che Google continua a valorizzare la ricerca esterna. Dimostrano inoltre perché sia importante mantenere canali di invio credibili.
Un programma di bounty dipende dalla fiducia reciproca. I ricercatori devono credere che i risultati validi riceveranno un'attenzione equa, mentre le aziende devono fidarsi che i segnalanti testino le proprie affermazioni.
L'automazione non filtrata indebolisce entrambi i lati. I ritardi nelle revisioni frustrano i ricercatori capaci, e le ricorrenti segnalazioni non valide rendono i revisori più scettici verso contributori sconosciuti.
La risposta di Google protegge la capacità di triage, ma restringe anche l'accesso. I ricercatori indipendenti non possono attualmente inviare comuni vulnerabilità di prodotto attraverso la categoria OSS VRP sospesa.
Questa limitazione potrebbe sopprimere risultati preziosi insieme al rumore. Un nuovo ricercatore con un problema valido potrebbe non avere un programma alternativo evidente.
La sfida è quindi un compromesso tra apertura e verifica. Un accesso ampio aumenta le opportunità di scoperta, mentre barriere rigorose proteggono il tempo limitato dei revisori.
Qualsiasi programma riprogettato deve preservare entrambi gli obiettivi. Se i requisiti di accesso diventano troppo gravosi, Google rischia di concentrare la partecipazione tra ricercatori affermati e aziende specializzate.
Se i requisiti restano troppo permissivi, la coda delle segnalazioni può tornare allo stesso sovraccarico. L'aggiornamento del primo trimestre del 2027 rivelerà dove Google traccerà quella linea.
L'ondata di segnalazioni IA è un problema per l'intero settore
La decisione di Google fa parte di un cambiamento più ampio, in cui le comunità della sicurezza stanno riscrivendo le regole di disclosure attorno alla scoperta automatizzata.
HackerOne ha segnalato un aumento di oltre il 100 percento del volume di report nel settore dopo la comparsa di strumenti di AI più capaci, nel febbraio 2026.
La sua analisi del volume di report ha rilevato che alcune segnalazioni contenevano scoperte utili. Altre erano duplicati, affermazioni non verificabili o report privi di dettagli concretamente utilizzabili.
La piattaforma non ha reagito vietando l’assistenza responsabile dell’AI. Ha invece rafforzato l’obbligo del ricercatore di validare le scoperte e dimostrarne l’impatto reale.
Le regole di HackerOne richiedono una proof of concept riproducibile, una valutazione accurata della gravità e la considerazione delle difese esistenti. Grandi lotti di report non verificati possono portare a misure di enforcement.
Questo approccio attribuisce la responsabilità all’operatore, non allo strumento. Un ricercatore resta responsabile di ogni endpoint generato, passaggio dell’attacco e dichiarazione di impatto.
La comunità del kernel Linux ha adottato un approccio altrettanto incentrato sulle prove. Le sue regole per la segnalazione di problemi di sicurezza affrontano ora direttamente la revisione del codice assistita dall’AI.
La documentazione afferma che i report prodotti dall’AI diventano spesso eccessivamente lunghi e nascondono i fatti critici. Chiede ai segnalanti di fornire descrizioni concise, revisioni interessate, condizioni di attivazione e riproduttori testati.
Linux avverte inoltre che gli strumenti possono inventare impatti teorici senza comprendere il modello di minaccia del kernel. Chiede invece ai segnalanti di indicare conseguenze verificabili.
Il progetto tratta le scoperte automatizzate ampiamente riproducibili in modo diverso dalle vulnerabilità tradizionalmente scoperte in privato. Più ricercatori trovano spesso lo stesso problema perché eseguono strumenti simili.
Ciò crea lavoro duplicato nei canali di disclosure progettati per vulnerabilità scarse e scoperte in modo indipendente. L’automazione cambia le ipotesi su cui si basano tali canali.
Il maintainer di Curl Daniel Stenberg ha descritto un’altra versione del problema nel 2025. La sua argomentazione sulla “death by a thousand slops” si concentrava sul costo cumulativo della revisione di segnalazioni deboli.
Un singolo report scadente può sembrare gestibile. Ripetere quel costo per centinaia di affermazioni generate può esaurire un progetto mantenuto da volontari.
Questi casi condividono un unico meccanismo. L’AI amplia l’offerta di ipotesi di vulnerabilità più rapidamente di quanto aumenti la disponibilità di lavoro qualificato per il triage.
L’impatto varia tra le organizzazioni. Google può assegnare ingegneri della sicurezza retribuiti, mentre i progetti più piccoli dipendono spesso da volontari con tempo limitato.
I maintainer open source affrontano una struttura di incentivi particolarmente difficile. Il codice pubblico è facile da acquisire per gli scanner automatizzati, ma i maintainer non ricevono risorse proporzionate.
Le taglie possono aggiungere un ulteriore squilibrio. Un’azienda può premiare le scoperte accettate, mentre i maintainer della comunità gestiscono le discussioni iniziali o la correzione upstream senza compenso.
Questo non rende la ricerca automatizzata intrinsecamente dannosa. L’AI può ispezionare componenti poco conosciuti, tradurre codice non familiare e aiutare i ricercatori a creare test.
Può anche migliorare la qualità dei report quando viene usata dopo la verifica. Un modello può organizzare i passaggi di riproduzione o spiegare più chiaramente un flusso di controllo complesso.
Le stesse capacità diventano distruttive quando sostituiscono la verifica. Generare una narrazione plausibile non equivale a dimostrare una condizione sfruttabile.
Il consenso emergente nel settore è quindi un’accettazione condizionata. L’assistenza dell’AI resta benvenuta quando un operatore umano può riprodurre e difendere ogni affermazione importante.
La chiusura temporanea di Google è più restrittiva di questo principio. Tuttavia, riflette la stessa valutazione su dove debba ricadere la responsabilità.
La persona che invia un report deve sostenere un costo di validazione sufficiente a proteggere il destinatario. Altrimenti, il programma diventa una coda di test esternalizzata per output speculativi delle macchine.
Barriere Più Rigide Possono Aiutare, ma Introducono Nuovi Rischi
Un programma riprogettato deve incorporare il costo della verifica in ogni segnalazione senza escludere i ricercatori indipendenti legittimi.
Google non ha reso nota la sostituzione definitiva per le segnalazioni di vulnerabilità dei prodotti. Diversi controlli si adatterebbero ai problemi individuati nelle sue precedenti regole.
Il primo è un riproduttore testato obbligatorio. Un riproduttore fornisce un piccolo programma, input o procedura che attiva in modo coerente il comportamento dichiarato.
Google potrebbe richiedere ai segnalanti di indicare l’esatta revisione del repository e l’ambiente. Queste informazioni ridurrebbero il tempo perso nel testare codice obsoleto o incompatibile.
I report potrebbero inoltre richiedere un argomento esplicito sulla raggiungibilità. Il segnalante dovrebbe mostrare come dati controllati dall’attaccante raggiungano l’operazione vulnerabile.
Un campo strutturato per il modello di minaccia potrebbe obbligare i ricercatori a identificare privilegi richiesti, confini di fiducia e mitigazioni esistenti. Le dichiarazioni di gravità non supportate diventerebbero più facili da individuare.
I limiti di frequenza offrono un’altra opzione. Google potrebbe limitare il numero di report irrisolti che un account può inviare in un periodo stabilito.
Questo scoraggerebbe le segnalazioni indiscriminate preservando al contempo l’accesso per i ricercatori scrupolosi. Limiti più elevati potrebbero seguire una storia di contributi accettati.
Depositi o requisiti di reputazione potrebbero offrire un filtro più forte, ma comportano maggiori rischi di equità. I nuovi ricercatori potrebbero faticare a entrare nel programma.
Il pre-screening automatizzato è un altro probabile componente. Google potrebbe usare analisi statica, esecuzione in sandbox o revisione basata su modelli per segnalare duplicati e prove mancanti.
Tuttavia, lo screening automatizzato non può diventare in sicurezza l’autorità finale. Può respingere ricerche insolite ma valide o favorire schemi di vulnerabilità familiari.
Un modello che revisiona il report di un altro modello può anche riprodurre le stesse ipotesi errate. Le prove di esecuzione indipendente restano più preziose dell’accordo testuale.
Privacy e riservatezza creano ulteriori complicazioni. I ricercatori possono esporre dettagli non corretti a servizi AI di terze parti quando chiedono ai modelli un’analisi.
Un programma rivisto potrebbe richiedere la divulgazione dell’uso di modelli esterni in relazione a scoperte riservate. Potrebbe inoltre limitare quali materiali sensibili entrano nei sistemi ospitati.
Google deve anche chiarire come i maintainer open source partecipino al triage. Un report può interessare un repository Google imponendo al contempo lavoro a una comunità più ampia di contributori.
L’azienda dovrebbe evitare di risolvere il problema della propria coda trasferendo i compiti di verifica upstream. Ciò sposterebbe il peso anziché ridurlo.
La trasparenza sarà importante durante la pausa. Google non ha fornito pubblicamente una ripartizione dettagliata dei report accettati, duplicati, non validi e assistiti dall’AI.
Tom’s Hardware ha descritto ingegneri e maintainer alle prese con migliaia di segnalazioni di scarsa qualità. L’avviso pubblicato da Google, tuttavia, non ha fornito un volume preciso né un tasso di accettazione.
Questa distinzione limita le conclusioni che gli osservatori esterni possono trarre. Le prove disponibili supportano l’esistenza di un serio problema di qualità, ma non offrono un quadro quantitativo completo.
Google dovrebbe pubblicare dati aggregati sufficienti a spiegare le soglie riprogettate. Misure utili includono il tempo mediano di revisione e la quota di report privi di riproduttori funzionanti.
Anche i tassi di falsi rifiuti contano. Una coda più rapida non è un successo se scoperte solide scompaiono perché i filtri automatizzati le classificano erroneamente.
Il programma dovrebbe distinguere l’assistenza alla scoperta dalla presentazione autonoma. Una scoperta dell’AI revisionata da un umano può essere preziosa, mentre una pipeline di report non supervisionata crea rischi non gestiti.
Il progetto più solido di Google renderebbe le prove meno costose da valutare della prosa. Test leggibili dalle macchine, template vincolati e ambienti riproducibili potrebbero sostenere questo obiettivo.
L’azienda dovrebbe inoltre preservare un percorso di escalation per le scoperte non convenzionali. Alcune vulnerabilità importanti resistono a semplici casi di test o coinvolgono catene complesse.
Nessuna singola barriera bilancerà questi requisiti. La risposta più probabile è un accesso a più livelli basato sulla qualità delle prove, sulla storia del ricercatore e sull’impatto di sicurezza dimostrato.
Cosa Osservare Prima dell’Aggiornamento di Google del Q1 2027
La prossima fase mostrerà se Google potrà riaprire le segnalazioni con standard probatori migliori anziché limitarsi ad accettare meno ricercatori.
Il primo segnale è l’ambito del programma sostitutivo. Google deve spiegare se le segnalazioni di vulnerabilità dei prodotti riapriranno completamente o torneranno attraverso un canale più ristretto.
Una riapertura completa suggerirebbe che nuovi filtri hanno ripristinato la fiducia nel processo di revisione. Un sistema di inviti limitato indicherebbe che la capacità di triage resta vincolata.
Il secondo segnale sono le prove richieste ai segnalanti. Riproduttori testati, commit interessati e percorsi di attacco concreti prenderebbero di mira le debolezze già identificate da Google.
Tali requisiti rafforzerebbero il programma se restassero accessibili. Lo indebolirebbero se solo ricercatori affermati potessero soddisfare standard di revisione opachi.
Il terzo segnale è il modo in cui rispondono gli altri programmi di sicurezza. HackerOne, Linux e i principali fornitori stanno tutti sperimentando regole di segnalazione consapevoli dell’AI.
Se convergeranno sulla riproducibilità e sulla responsabilità umana, il settore potrebbe sviluppare una base condivisa. Ciò potrebbe ridurre la confusione per i ricercatori che lavorano su più programmi.
Se i programmi adotteranno invece restrizioni incompatibili, la disclosure diventerà più difficile. I ricercatori potrebbero aver bisogno di pacchetti di prove, policy AI e pratiche di riservatezza differenti per ogni obiettivo.
Gli sviluppatori dovrebbero anche osservare gli strumenti stessi. Agenti migliori possono produrre test funzionanti, ma possono generare prove non valide con maggiore sicurezza.
Il parametro chiave non è quanti avvisi trovi un agente. È quante scoperte indipendentemente riproducibili e rilevanti per la sicurezza superano la revisione degli esperti.
I maintainer dovrebbero monitorare il tempo speso per ogni vulnerabilità accettata, non il numero grezzo di segnalazioni. Questa metrica mostra se l’automazione migliora la sicurezza o si limita ad ampliare la coda.
I team di ricerca possono prepararsi documentando ogni fase del lavoro assistito dall’AI. Conservate il commit testato, la configurazione, i log, gli input e i tentativi di riproduzione falliti.
I team necessitano inoltre di un registro ricercabile delle scoperte precedenti. Una base di conoscenza ingegneristica strutturata può aiutare a identificare i duplicati prima che raggiungano i maintainer.
I ricercatori dovrebbero essere in grado di spiegare il difetto senza affidarsi a prosa generata. Dovrebbero sapere perché il percorso del codice è raggiungibile e quale controllo esistente fallisce.
Se questa spiegazione manca, la scoperta resta un’ipotesi. Non è pronta per un programma di ricompense per vulnerabilità.
La sospensione del Google OSS VRP è quindi un avvertimento sul design del flusso di lavoro, non un verdetto contro la ricerca sulla sicurezza con AI. La scoperta ha accelerato, ma la verifica non è scomparsa.
L’aggiornamento di Google del Q1 2027 verificherà se un grande fornitore possa ricostruire un programma aperto attorno a questa realtà. Il miglior risultato non massimizzerebbe le segnalazioni.
Massimizzerebbe il valore di sicurezza verificato per ogni ora di attenzione del revisore. Questo standard offre ai ricercatori seri un obiettivo chiaro e protegge i maintainer dal volume speculativo.
Prima di inviare ovunque una scoperta assistita dall’AI, ponetevi tre domande. Un’altra persona può riprodurla, attraversa un confine di sicurezza reale e avete testato ogni affermazione principale?
Se una risposta è no, continuate a investigare. Il report più economico da generare può diventare il più costoso da smentire per un maintainer.
