Il divario di sicurezza tra Apple e Google si amplia mentre le segnalazioni di bug AI travolgono Apple
Apple ha imposto nuovi limiti dopo che le segnalazioni di bug assistite dall'AI hanno iniziato a sovraccaricare il suo processo di ricezione delle vulnerabilità, nonostante il crescente valore della scoperta automatizzata. Il divario di sicurezza tra Apple e Google mette ora in luce una contraddizione più ampia. L'AI può individuare potenziali falle più rapidamente, ma i fornitori non possono decidere automaticamente quali segnalazioni meritino un intervento urgente.
Secondo quanto riportato, Apple ha introdotto a giugno 2026 un limite alle segnalazioni e un periodo di attesa di 30 giorni. I ricercatori che raggiungono il limite devono richiedere una quota più alta tramite il portale di sicurezza di Apple. L'azienda non ha divulgato pubblicamente il limite predefinito, il volume delle segnalazioni, il tasso di rifiuto o l'entità dell'arretrato di revisione.
Google, nel frattempo, presenta la ricerca di vulnerabilità con l'AI come un moltiplicatore di forza per i difensori. Il suo agente Big Sleep ha individuato falle software precedentemente sconosciute, mentre esperti umani continuano a supervisionare la divulgazione. Il contrasto non riguarda semplicemente Apple contro Google. È una prova della capacità dei programmi di sicurezza AI di scalare il proprio giudizio con la stessa rapidità con cui scalano la scoperta.
Apple ha posto un cancello davanti alla sua pipeline di bug
Le nuove restrizioni di Apple sono un'ammissione del fatto che la scoperta di vulnerabilità ha superato gli attuali controlli di ricezione dell'azienda.
La modifica riportata riguarda le segnalazioni inviate tramite il portale di sicurezza interno di Apple. Un limite restringe il numero di report che un ricercatore può presentare, mentre il periodo di attesa impedisce ulteriori invii immediati. I ricercatori possono chiedere ad Apple maggiore capacità, ma questo aggiunge un ulteriore passaggio di revisione.
La documentazione pubblica di Apple segnala già una crescente preoccupazione per i materiali generati dall'AI. Le sue linee guida per il bounty invitano i ricercatori a evitare descrizioni prolisse generate da strumenti AI. Escludono inoltre problemi teorici o scoperti dall'AI che non dispongono di un'adeguata convalida umana.
La distinzione è importante. Un modello AI può individuare codice sospetto senza dimostrare che un attaccante possa raggiungerlo. Può anche produrre una spiegazione plausibile che crolla durante i test. Un team di sicurezza deve riprodurre il comportamento, valutarne la sfruttabilità, cercare duplicati, stimare l'esposizione e coordinare una correzione.
Ogni segnalazione comporta quindi un costo di revisione, incluse quelle false. Una scoperta ben confezionata ma non valida può consumare più tempo di una palesemente incompleta. Il revisore deve separare un linguaggio sicuro di sé dalle prove tecniche.
Apple afferma che l'invio ripetuto di segnalazioni non idonee può attivare una sospensione dell'elaborazione di 180 giorni. Più di due periodi di sospensione possono portare all'esclusione permanente dal programma bounty. I suoi termini identificano inoltre i modelli ad alto volume di affermazioni AI-assistite false o non convalidate come comportamento inaccettabile.
Queste politiche sono progettate per scoraggiare lo spam. Il nuovo limite si spinge oltre perché riduce il volume prima che Apple abbia valutato ciascuna segnalazione. Lo rende un controllo di ricezione d'emergenza, anziché una decisione finale sulla qualità.
Il meccanismo può ridurre rapidamente la crescita della coda. Tuttavia, tratta un ricercatore prolifico con segnalazioni valide in modo molto simile a qualcuno che invia output speculativi di un modello. Apple può concedere eccezioni, ma l'azienda non ha spiegato i propri criteri né il tempo di risposta previsto.
Questo crea un serio caso limite. Un ricercatore potrebbe usare l'AI per scoprire diverse vulnerabilità indipendenti e riproducibili durante un audit concentrato. Se quel ricercatore raggiunge il limite, una segnalazione valida potrebbe attendere per tutto il periodo di attesa mentre un attaccante studia lo stesso codice.
Apple non ha affermato che questo scenario si sia verificato. Non ha nemmeno pubblicato prove che il limite abbia ritardato una divulgazione critica. La possibilità mostra comunque perché le quote siano un filtro poco preciso.
L'esposizione alla sicurezza dell'azienda rende il problema particolarmente rilevante. Apple afferma che le sue tecnologie proteggono più di 2,35 miliardi di dispositivi attivi. Una falla in un componente condiviso può quindi colpire telefoni, tablet, computer, orologi e servizi in un'enorme base installata.
Il programma Apple promette inoltre ricompense sostanziali per catene di exploit avanzate. L'azienda afferma di aver pagato oltre 35 milioni di dollari a più di 800 ricercatori dall'apertura del programma pubblico nel 2020. Questi dati suggeriscono che Apple continui a valorizzare la ricerca esterna, pur limitando il modo in cui le segnalazioni entrano nella sua coda.
Il cambiamento importante non è che Apple respinga segnalazioni di bassa qualità. Ogni programma bounty maturo lo fa. Apple ha riconosciuto che persino il tasso di ricezione ora richiede un contenimento.
Perché le segnalazioni di bug AI creano più lavoro prima di far risparmiare tempo
L'AI riduce il costo di individuare comportamenti sospetti, ma non elimina il costoso lavoro necessario per stabilire l'impatto sulla sicurezza.
La ricerca tradizionale di vulnerabilità impone limiti naturali. I ricercatori devono comprendere un bersaglio, ispezionare il codice o il comportamento del sistema, progettare test e sviluppare una proof of concept. Questi passaggi richiedono tempo, limitando il volume delle segnalazioni.
Gli agenti AI comprimono alcune parti di quel processo. Possono ispezionare molti file, generare test harness, mutare input, tracciare percorsi di esecuzione e proporre ipotesi di exploit. Diversi agenti possono essere eseguiti in parallelo sullo stesso codebase pubblico.
Questo crea due tipi distinti di scala. La scala produttiva genera più vulnerabilità reali. Quella inefficiente genera duplicati, crash irraggiungibili, errori previsti e osservazioni tecnicamente corrette senza un percorso d'attacco pratico.
Entrambi i tipi arrivano nella stessa coda.
Una proof of concept è una dimostrazione ripetibile che mostra il comportamento segnalato in condizioni definite. Apple chiede ai ricercatori un exploit funzionante o una proof of concept affidabile. Si aspetta inoltre una spiegazione del confine di sicurezza aggirato da un attaccante.
Questo requisito filtra molte segnalazioni deboli, ma l'AI generativa può imitare la forma di un report completo. Può fornire vocabolario tecnico, frammenti di codice, affermazioni sull'impatto e suggerimenti di correzione. Nessuno di questi elementi garantisce che il problema esista.
I revisori umani devono testare le prove. Devono anche stabilire se un altro ricercatore abbia inviato la stessa falla di fondo attraverso sintomi diversi. Questa analisi dei duplicati diventa più difficile quando molti agenti analizzano in modo indipendente lo stesso codice.
GitHub ha pubblicato prove insolitamente chiare del più ampio cambiamento di volume. Le segnalazioni private di vulnerabilità sulla sua piattaforma sono passate da circa 550 a settimana nel gennaio 2026 a oltre 3.000 a settimana per gran parte di maggio. Il suo team di advisory ha pubblicato quel mese 1.560 avvisi revisionati, più di cinque volte il suo output tipico.
Eppure GitHub ha affermato che persino quel ritmo record di elaborazione non riusciva a tenere il passo. Il suo resoconto dell'impennata di vulnerabilità mostra che una revisione più rapida da sola non può risolvere una ricezione illimitata.
Il principale collo di bottiglia è il giudizio. I team di sicurezza devono stabilire quali report rappresentino condizioni raggiungibili e sfruttabili e quali descrivano soltanto stati insoliti del programma. Questo lavoro richiede spesso conoscenza dell'architettura, della distribuzione, delle mitigazioni e delle capacità degli attaccanti.
L'AI può assistere in queste decisioni, ma consentire a un sistema automatizzato di respingere le segnalazioni crea un altro rischio. Un modello potrebbe liquidare un exploit non familiare perché assomiglia a falsi positivi passati. Gli attaccanti ne traggono vantaggio se nuove scoperte scompaiono in un filtro automatizzato.
I team dei fornitori affrontano quindi un problema di errori asimmetrici. Accettare una segnalazione falsa spreca il tempo dei revisori. Rifiutare una vulnerabilità reale può lasciare esposti gli utenti.
I limiti alle segnalazioni controllano il primo rischio riducendo il volume in entrata. Possono peggiorare il secondo quando ritardano ricercatori credibili. Un sistema migliore deve valutare la qualità delle prove senza presumere che la quantità equivalga a un abuso.
I segnali utili includono riproducibilità, percorsi d'attacco raggiungibili, output dei sanitizer, versioni interessate, prerequisiti dell'exploit e chiaro impatto sulla sicurezza. La storia del ricercatore può essere utile, ma non dovrebbe escludere permanentemente i nuovi arrivati. Ogni ricercatore affermato è stato un tempo sconosciuto.
Le segnalazioni di bug AI spiegate da questo episodio non sono normali ticket di assistenza. Sono affermazioni tecniche non attendibili che possono contenere sia scoperte preziose sia finzioni persuasive. Il problema della coda di Apple riflette il costo di distinguere queste categorie.
Il modello Apple Google si divide sulla convalida, non sulla scoperta
Il contrasto tra Apple e Google è in realtà un disaccordo sul punto in cui debba collocarsi la convalida in una pipeline di sicurezza assistita dall'AI.
Big Sleep di Google combina modelli di Google DeepMind con l'esperienza sulle vulnerabilità di Project Zero. L'agente cerca falle sconosciute, ma il processo pubblicato da Google mantiene la supervisione umana prima della divulgazione esterna.
Google ha annunciato nel 2025 che Big Sleep aveva individuato una vulnerabilità critica di SQLite tracciata come CVE-2025-6965. L'azienda ha affermato che l'intelligence sulle minacce suggeriva che gli attaccanti fossero a conoscenza della falla e si stessero preparando a sfruttarla.
Questa affermazione proviene da Google e dovrebbe essere trattata come la valutazione dell'azienda. Tuttavia, dimostra il miglior caso d'uso per la scoperta assistita dall'AI. Un agente individua una falla ad alto impatto abbastanza presto da consentire ai difensori di intervenire.
Google ha poi riferito di un primo gruppo di 20 vulnerabilità trovate da Big Sleep in software open source. Esperti umani hanno revisionato le scoperte prima di segnalarle ai manutentori. Questo passaggio di revisione ha ridotto la probabilità che i manutentori ricevessero speculazioni grezze del modello.
La panoramica di Big Sleep di Google sottolinea inoltre la supervisione umana e procedure di divulgazione consolidate. L'azienda non presenta la scoperta autonoma come un'autorizzazione all'invio autonomo di massa.
Questo produce un'interfaccia più pulita per i destinatari. Google assorbe il primo ciclo di convalida all'interno del proprio programma di ricerca. I manutentori ricevono segnalazioni che hanno già superato un controllo esperto.
Il portale di Apple affronta il lato opposto di questa interfaccia. Accetta segnalazioni da ricercatori indipendenti i cui metodi, strumenti, incentivi e livelli di competenza variano ampiamente. Apple non può presumere che ogni mittente abbia svolto una convalida comparabile.
L'apparente divario tra Apple e Google contiene quindi un'importante differenza strutturale. Google controlla il flusso di lavoro di Big Sleep. Apple non controlla gli agenti che i ricercatori esterni indirizzano verso i suoi prodotti.
Ciononostante, il modello di Google offre uno standard utile. La scoperta AI funziona meglio quando la parte che gestisce l'agente possiede anche l'onere di convalidarne i risultati. Inviare scoperte grezze trasferisce tale costo ai manutentori che non hanno mai scelto di eseguire la scansione.
Lo standard diventa più difficile da applicare quando sono disponibili ricompense bounty. L'automazione consente ai ricercatori di esaminare più bersagli e inviare più segnalazioni. Ciò può produrre lavoro prezioso, ma incoraggia anche una strategia da lotteria basata sul volume di invii.
Le regole di Apple cercano di contrastare questo incentivo. Le segnalazioni devono essere complete, attuabili, sfruttabili e inviate per prime. L'azienda esclude scoperte prive di un percorso di riproduzione affidabile o che descrivono scenari irrealizzabili.
Tuttavia, un limite misura la quantità anziché la qualità. Il processo di Google si concentra sulla convalida prima dell'invio. Il controllo d'emergenza di Apple limita l'invio prima della convalida.
Il sistema futuro più solido combinerebbe entrambe le idee. I ricercatori fornirebbero prove verificabili dalla macchina, mentre i fornitori userebbero strumenti automatizzati di clustering e riproduzione. Gli esperti umani si concentrerebbero su scoperte nuove e impatti ambigui.
Quel processo non può eliminare del tutto il ruolo umano. La gravità di una vulnerabilità dipende dal contesto, inclusi i modelli di distribuzione, le autorizzazioni, le mitigazioni e le possibilità di concatenare attacchi. I modelli possono analizzare questi fattori, ma le loro conclusioni richiedono comunque una revisione responsabile.
Anche Google ha riconosciuto che gli esseri umani da soli faticheranno a tenere il passo. Il suo progetto CodeMender mira a individuare e correggere vulnerabilità con l’AI, spingendo l’automazione oltre la sola scoperta. Agenti specializzati di verifica esaminano le patch proposte prima dell’approvazione finale da parte di un umano.
Questo evidenzia la reale pressione competitiva su Apple. Una scoperta più rapida richiede conferme e correzioni più rapide, non soltanto filtri d’ingresso più severi. Se la capacità di revisione di Apple resta principalmente umana, le segnalazioni assistite dall’AI continueranno a metterla alla prova.
Apple non deve copiare gli strumenti interni di Google. Deve però avere una risposta per l’intera pipeline. Ciò comprende scoperta, autenticazione, deduplicazione, riproduzione, definizione delle priorità, correzione e comunicazione con i ricercatori.
A vincere non sarà l’azienda la cui AI produce più avvisi. Sarà quella che trasforma le segnalazioni credibili in correzioni distribuite con il minor spreco di risorse.
I programmi di sicurezza nel settore stanno chiudendo i propri accessi
Il limite di Apple fa parte di una trasformazione dell’intero settore: dalle segnalazioni aperte verso reputazione, evidenze e accesso gestito.
GitHub ha ristrutturato il proprio programma di bug bounty nel luglio 2026, dopo aver affrontato una coda crescente. Ha introdotto un programma permanente basato su invito accanto a un percorso pubblico. Il programma pubblico ora richiede un segnale HackerOne per ridurre le segnalazioni a basso sforzo e generate dall’AI.
I nuovi ricercatori privi della reputazione richiesta ricevono quattro invii per costruirsi uno storico. GitHub descrive questo modello come un canale di accesso al proprio programma su invito, non come una barriera permanente attorno alla ricerca sulla sicurezza.
Le modifiche al bounty dell’azienda sono entrate in vigore per le segnalazioni inviate dal 27 luglio in poi. Le segnalazioni precedenti restano coperte dalla struttura precedente.
L’approccio di GitHub differisce da un limite fisso perché usa la qualità delle segnalazioni passate come indicatore. Crea inoltre un percorso verso un maggiore accesso. Tuttavia, i sistemi reputazionali possono svantaggiare i nuovi arrivati qualificati o i ricercatori che lavorano al di fuori delle piattaforme bounty dominanti.
Il progetto curl ha adottato una misura più drastica. Ha chiuso il proprio programma bounty su HackerOne dopo che i manutentori hanno avuto difficoltà a gestire segnalazioni generate dall’AI. Il piccolo team di sicurezza ha dichiarato che gli invii falsi o di scarso valore imponevano un carico mentale e operativo insostenibile.
I manutentori Linux hanno segnalato una pressione simile dovuta a risultati AI duplicati. Più persone possono eseguire strumenti analoghi sullo stesso codice e inviare privatamente lo stesso risultato. Ogni mittente può ritenere originale la scoperta, perché le code private nascondono le segnalazioni esistenti.
Questi esempi mostrano che Apple non è l’unica a essere impreparata. L’economia della segnalazione delle vulnerabilità è cambiata più rapidamente delle istituzioni che ricevono le segnalazioni.
In passato, la scoperta assorbiva gran parte dello sforzo di un ricercatore. Ora gli agenti AI possono automatizzare la revisione del codice e i test su molti target. La capacità di triage non ha registrato un’espansione equivalente.
I progetti open source affrontano lo squilibrio più marcato, perché i manutentori potrebbero non disporre di personale di sicurezza dedicato. I grandi fornitori possiedono più risorse, ma hanno anche più prodotti, ricercatori, utenti e potenziali superfici d’attacco.
La lezione sbagliata è che le segnalazioni assistite dall’AI abbiano poco valore. I risultati di Google dimostrano il contrario. I sistemi AI possono identificare difetti reali in software maturi, compresi problemi sfuggiti alla revisione tradizionale.
La lezione corretta è che l’output non convalidato genera esternalità negative. Chi esegue il modello ottiene piste a basso costo, mentre il destinatario paga per stabilire se ciascuna pista sia rilevante.
I programmi del settore stanno rispondendo spostando questo costo verso chi invia le segnalazioni. Richiedono prove più solide, impongono quote, considerano la cronologia del ricercatore oppure riservano l’accesso premium ai partecipanti fidati.
Questa transizione solleva interrogativi di governance. Un ricercatore fidato può comunque sbagliarsi, mentre un ricercatore sconosciuto può individuare un difetto critico. Un punteggio reputazionale dovrebbe orientare il triage, non sostituire le evidenze tecniche.
I programmi necessitano inoltre di percorsi di ricorso trasparenti. Se un sistema automatizzato contrassegna una segnalazione come duplicata o non praticabile, il ricercatore dovrebbe poter fornire nuove evidenze. Altrimenti, il filtraggio può nascondere guasti autentici.
Le tempistiche di divulgazione aggiungono ulteriore pressione. I ricercatori spesso si aspettano che i fornitori correggano le vulnerabilità entro un periodo definito prima della pubblicazione. Un lungo ritardo nella presa in carico consuma parte di quel periodo prima ancora che un ingegnere valuti la segnalazione.
Il processo bounty di Apple prende generalmente decisioni sulle ricompense dopo la risoluzione di un problema. Ciò può incoraggiare una valutazione accurata, ma significa anche che i ricercatori dipendono dai tempi interni e dalla comunicazione dell’azienda. Ulteriori ritardi nella presa in carico possono mettere sotto pressione tale rapporto.
I ricercatori indipendenti restano un essenziale controllo esterno sulla sicurezza dei fornitori. Un programma che diventa troppo restrittivo può spingerli verso la divulgazione pubblica, i mercati privati degli exploit o altri obiettivi.
Apple deve quindi proteggere due risorse scarse. Una è l’attenzione dei suoi revisori. L’altra è la disponibilità dei ricercatori a segnalare privatamente difetti gravi.
Un limite tutela immediatamente la prima risorsa. Se danneggerà la seconda dipenderà dalla gestione delle eccezioni, dai tempi di risposta e dal trattamento dei ricercatori che inviano più segnalazioni valide.
Cosa non ci dicono i limiti di Apple
La politica riportata dimostra che Apple vede un problema nella presa in carico, ma non dimostra che l’azienda stia trascurando vulnerabilità critiche.
Apple non ha pubblicato il numero di segnalazioni assistite dall’AI che riceve. Non ha rivelato quante siano valide, duplicate, teoriche o completamente inventate. Senza questi dati, gli osservatori esterni non possono misurare la scala o la qualità dell’arretrato.
L’azienda non ha neppure spiegato se il limite predefinito vari in base alla reputazione del ricercatore. Non è chiaro con quale rapidità Apple esamini le richieste di quota o se le segnalazioni urgenti possano aggirare il periodo di raffreddamento.
Questi dettagli mancanti impediscono conclusioni definitive sul rischio operativo. Un limite abbinato a una rapida revisione delle eccezioni potrebbe avere scarso effetto sui ricercatori credibili. Un processo lento e rigido potrebbe ritardare scoperte importanti.
Anche l’espressione “segnalazione generata dall’AI” nasconde pratiche molto diverse. Un ricercatore può usare un modello soltanto per revisionare la prosa. Un altro può usare un agente per individuare un difetto, quindi riprodurlo e analizzarlo manualmente. Un terzo può inviare output grezzo senza aprire il software interessato.
Trattare questi flussi di lavoro come un’unica categoria confonderebbe l’assistenza con la negligenza. Le regole pubblicate da Apple si concentrano generalmente sulla convalida anziché vietare l’uso dell’AI in sé. Questa distinzione dovrebbe restare centrale.
Non esistono inoltre prove verificate che gli strumenti di Google possano risolvere direttamente il problema di intake di Apple. Big Sleep opera in un ambiente di ricerca controllato, supportato da esperti di Google. I portali bounty pubblici ricevono materiale molto più eterogeneo.
I risultati di Google sono in parte auto-riportati. L’azienda fornisce dettagli sul monitoraggio dei problemi e sulla divulgazione, ma le sue ampie affermazioni sul vantaggio difensivo meritano comunque un esame indipendente. Le prestazioni di un singolo agente gestito non rappresentano ogni strumento di sicurezza AI.
La correzione automatizzata introduce ulteriore incertezza. Una patch può eliminare un crash visibile mantenendo la vulnerabilità sottostante. Può anche creare problemi di compatibilità o chiudere un percorso d’attacco aprendone un altro.
L’approvazione umana resta importante, specialmente per sistemi operativi distribuiti su miliardi di dispositivi. Apple deve valutare non solo se una correzione funzioni, ma anche se incida su prestazioni, privacy, autonomia della batteria o compatibilità delle applicazioni.
Il modello di sviluppo chiuso dell’azienda complica la valutazione esterna. I ricercatori possono osservare il comportamento pubblico e ispezionare il software rilasciato, ma non possono vedere gli strumenti interni di triage, i livelli di personale o le code di correzione di Apple.
I lettori dovrebbero quindi resistere a due narrazioni semplicistiche. Apple non ha ammesso che l’AI abbia di per sé sconfitto il suo team di sicurezza. Ha riconosciuto, attraverso la politica e la conferma riportata, che il volume delle segnalazioni richiede controlli più rigorosi.
Anche la narrazione opposta è incompleta. Il limite non è semplice manutenzione ordinaria. Un periodo di raffreddamento di 30 giorni segnala che le normali regole di revisione e anti-spam erano insufficienti per almeno alcuni modelli di invio.
La politica dovrebbe essere valutata in base ai risultati. I ricercatori hanno bisogno di conferme tempestive, le segnalazioni riproducibili necessitano di una rapida revisione tecnica e i difetti critici richiedono patch coordinate. La dimensione della coda conta perché può rallentare ciascuna di queste fasi.
È qui che la gestione della conoscenza diventa sicurezza operativa. I team necessitano di collegamenti ricercabili tra segnalazioni, componenti interessati, duplicati precedenti, patch e scadenze di divulgazione. Una base di conoscenza ricercabile ben progettata può supportare questo lavoro, anche se non può sostituire la competenza in materia di sicurezza.
La sfida di Apple non consiste semplicemente nel memorizzare più segnalazioni. Deve preservare il contesto mentre le scoperte passano tra il personale addetto alla presa in carico, gli ingegneri di prodotto, i responsabili della risposta agli incidenti e i team di rilascio. La perdita di contesto trasforma anche una segnalazione valida in lavoro ripetuto.
L’AI può aiutare a raggruppare le scoperte correlate e a recuperare decisioni precedenti. Può redigere passaggi di riproduzione o identificare i responsabili del codice interessato. Questi impieghi riducono il carico amministrativo senza conferire a un modello l’autorità finale sulla gravità.
La domanda senza risposta è se Apple stia costruendo questa capacità più profonda o si stia affidando soprattutto alla limitazione del flusso. Il limite compra tempo, ma non rivela cosa Apple intenda fare con quel tempo.
Tre segnali mostreranno se il divario tra Apple e Google persiste
La prossima fase sarà misurata dalla qualità della presa in carico, dalla velocità di correzione e dal trattamento dei ricercatori credibili.
Il primo segnale è se Apple pubblicherà regole sulle quote più chiare. I ricercatori devono conoscere i limiti predefiniti, i criteri per le eccezioni, il canale di emergenza e i tempi di revisione previsti. La trasparenza trasformerebbe una restrizione opaca in un processo operativo prevedibile.
Una rapida approvazione delle quote per ricercatori con scoperte riproducibili sosterrebbe l’argomento di Apple secondo cui la politica prende di mira il rumore. Segnalazioni di richieste di accesso irrisolte o di divulgazioni critiche ritardate lo indebolirebbero.
Il secondo segnale è se Apple amplierà il triage automatizzato senza indebolire la revisione umana. Cambiamenti utili includerebbero il raggruppamento dei duplicati, l’esecuzione delle proof-of-concept in ambienti isolati e requisiti di evidenza leggibili dalle macchine.
Apple potrebbe inoltre offrire più diffusamente i target flag. Un target flag è un indicatore controllato che dimostra che un ricercatore ha raggiunto un obiettivo di sicurezza protetto. Apple utilizza già tali flag in alcune parti del proprio programma bounty per accelerare la valutazione.
L’automazione basata sulle evidenze affronterebbe la qualità più direttamente di un limite fisso. Consentirebbe ad Apple di dare priorità alle scoperte che includono percorsi di riproduzione affidabili, preservando al contempo un canale per vulnerabilità insolite.
Il terzo segnale riguarda il rendimento degli agenti di sicurezza di Google al di fuori di dimostrazioni attentamente gestite. Le divulgazioni pubbliche di Big Sleep, i controlli sui falsi positivi e il tempo dalla scoperta alla patch forniranno un confronto significativo.
Project Zero di Google ha inserito Big Sleep nel proprio quadro di divulgazione, che pone l’accento sulla disponibilità delle patch e sulla trasparenza. La sua politica di divulgazione offre agli osservatori esterni un modo per esaminare come le scoperte avanzino verso la pubblicazione.
Se Google continuerà a produrre vulnerabilità convalidate senza sovraccaricare i manutentori, il suo modello acquisirà credibilità. Se i destinatari segnaleranno un eccesso di duplicati o rilevamenti superficiali, il divario rispetto ad Apple si ridurrà.
Anche il settore nel suo complesso osserverà GitHub. La sua struttura basata sulla reputazione offre una via di mezzo tra accesso illimitato e un limite universale. La qualità delle segnalazioni, il successo dei nuovi arrivati e i tempi di risposta mostreranno se questo modello funziona.
Per gli sviluppatori e gli acquirenti aziendali, la questione riguarda le tempistiche delle patch, non una politica astratta sull’AI. Individuare più falle migliora la sicurezza solo quando i fornitori riescono a verificarle e correggerle prima che gli aggressori le sfruttino.
I responsabili della sicurezza dovrebbero chiedere ai fornitori come distinguono la ricerca assistita dall’AI dall’automazione non convalidata. Dovrebbero anche chiedere se la crescita delle segnalazioni ha modificato gli obiettivi di correzione, il coordinamento della divulgazione o il personale.
Anche i ricercatori hanno delle responsabilità. Dovrebbero confermare le versioni interessate, documentare i prerequisiti esatti, riprodurre il comportamento e spiegare quale confine di sicurezza è stato oltrepassato. Il testo generato dall’AI non può sostituire questi passaggi.
La vicenda Apple-Google riguarda, in ultima analisi, la capacità operativa dell’intero sistema di sicurezza. Google sta dimostrando una scoperta più rapida sotto supervisione controllata. Apple sta limitando l’afflusso proveniente da una popolazione esterna non controllata.
Nessuno dei due approcci risolve da solo il problema. La scoperta senza convalida crea rumore. Le restrizioni senza una maggiore capacità di convalida creano ritardi nascosti.
Nei prossimi mesi, osservate se Apple sostituirà il suo freno d’emergenza con una pipeline a segnale più elevato. Eccezioni chiare, gestione automatizzata delle prove e comunicazioni più rapide con i ricercatori rafforzerebbero la sua posizione.
Se il periodo di raffreddamento resterà la principale risposta visibile, il divario di sicurezza tra Apple e Google si approfondirà. L’AI continuerà ad aumentare l’offerta di rilevamenti plausibili, mentre la revisione umana rimarrà la risorsa scarsa.
Questo squilibrio dovrebbe preoccupare chiunque dipenda, nel proprio lavoro, da software ampiamente distribuito. Chiedetevi se i vostri fornitori si limitano a contenere le segnalazioni o stanno migliorando il percorso dalla scoperta alla correzione. La risposta determinerà se la ricerca di vulnerabilità basata sull’AI diventerà un vantaggio difensivo o l’ennesima casella di posta sovraccarica.
