Il divario di sicurezza tra Apple e Google si allarga mentre i cacciatori di bug basati sull’IA inondano le code

Le strategie di sicurezza di Apple e Google sono entrate in una nuova fase dopo che cacciatori di bug basati sull’IA hanno messo in luce una debolezza nel processo di ricezione delle vulnerabilità di Apple. Secondo quanto riportato, Apple ha limitato le segnalazioni attive poiché le scoperte generate dalle macchine stavano mettendo sotto pressione la sua capacità di revisione.

Il problema immediato non era semplicemente la presenza di segnalazioni false. I ricercatori dell’azienda italiana di sicurezza Bynario hanno affermato che il loro flusso di lavoro automatizzato ha individuato una reale falla di autorizzazione in macOS in mezzo a un numero molto più elevato di segnalazioni. L’azienda ha infine convalidato un percorso d’attacco in grado di creare file con privilegi root.

Apple ha corretto la vulnerabilità nel luglio 2026. Tuttavia, l’episodio ha rivelato un divario operativo più ampio tra l’individuazione di una falla e la sua valutazione da parte di una persona affidabile. Google ha trascorso anni a costruire questo livello di verifica attorno a Project Zero e al suo sistema di IA, Big Sleep.

Questo è il capovolgimento centrale. Si prevedeva che l’IA aiutasse i fornitori a ispezionare più codice, ma consente anche ai ricercatori esterni di generare segnalazioni più rapidamente di quanto i fornitori riescano a elaborarle. Il collo di bottiglia si è spostato dalla scoperta verso la convalida, la definizione delle priorità e la distribuzione delle patch.

Per Apple, questo cambiamento crea pressioni che vanno oltre un singolo difetto di macOS. Il suo programma di sicurezza deve distinguere la ricerca di valore assistita dall’IA dalle segnalazioni plausibili ma errate, senza bloccare quelle legittime. L’approccio di Google offre un modello, anche se dipende ancora fortemente dalla revisione di esperti.

Una falla corretta su Mac ha rivelato un problema più ampio nella ricezione delle segnalazioni

Il cambiamento importante è che la scoperta automatizzata si è scontrata con un processo per le vulnerabilità progettato per un volume di segnalazioni umane.

Bynario ha pubblicato il proprio resoconto tecnico il 29 luglio, due giorni dopo che Apple aveva rilasciato gli aggiornamenti pertinenti. I ricercatori hanno individuato due problemi di autorizzazione correlati nella Condivisione schermo di macOS e li hanno raggruppati sotto CVE-2026-43760.

La falla interessava un percorso di autenticazione legacy usato da Virtual Network Computing, o VNC. VNC è un protocollo che consente a un utente remoto di visualizzare e controllare lo schermo di un altro computer.

Lo sfruttamento richiedeva diverse condizioni. Condivisione schermo o Gestione remota dovevano essere abilitate. Doveva inoltre essere configurata l’opzione della password VNC legacy, e l’attaccante doveva conoscere quella password.

Questi requisiti rendono la falla più circoscritta di un attacco zero-click non autenticato. Non ne eliminano l’importanza. Una password VNC avrebbe dovuto autorizzare il controllo dello schermo, non l’accesso privilegiato al filesystem.

I ricercatori hanno scoperto che macOS gestiva in modo diverso l’autenticazione nativa Apple e quella VNC legacy. Una sessione nativa associava l’attività a un utente macOS riconosciuto. Il percorso legacy non forniva la stessa identità utente.

Gli helper per la copia dei file mantenevano l’autorità root quando tale identità mancava. Un visualizzatore remoto poteva quindi richiedere file protetti o creare file controllati dall’attaccante in posizioni privilegiate.

Nell’analisi dell’exploit macOS, Bynario ha descritto il posizionamento di un file di policy all’interno di una directory di configurazione protetta. Quel file abilitava comandi amministrativi senza password e supportava una dimostrazione di esecuzione remota di comandi root.

I ricercatori hanno testato il comportamento su recenti sistemi Apple silicon con System Integrity Protection abilitato. La falla non aggirava le protezioni di memoria di Apple perché si trattava di un errore di autorizzazione, non di un exploit di corruzione della memoria.

Questa distinzione conta. Le difese moderne possono rendere più difficili da sfruttare buffer overflow e puntatori falsificati. Non possono impedire a un componente di sistema legittimo di eseguire un’operazione autorizzata con l’identità sbagliata.

L’avviso di Apple ha usato un linguaggio più prudente, descrivendo un possibile accesso a dati sensibili degli utenti. Bynario ha sostenuto che tale descrizione non cogliesse l’impatto completo della creazione di file privilegiati.

I resoconti pubblici differivano anche sulla gravità. L’avviso di Apple e la valutazione dei ricercatori applicavano punteggi e ipotesi diversi. Questo disaccordo rafforza il motivo per cui la convalida richiede più della semplice accettazione di un’etichetta automatizzata.

Apple ha corretto il problema in macOS Tahoe 26.6 e Sonoma 14.8.8 il 27 luglio. L’aggiornamento di sicurezza dell’azienda attribuisce a ricercatori esterni il merito di diverse vulnerabilità risolte nella release.

Per gli utenti, la risposta pratica è diretta. Installare l’attuale aggiornamento di macOS. Le organizzazioni che non possono aggiornare dovrebbero disabilitare l’opzione della password VNC legacy o disattivare Condivisione schermo quando non è necessaria.

La storia più ampia inizia prima della patch. Secondo le segnalazioni, i ricercatori di Bynario avevano già inviato decine di scoperte nell’arco di diverse settimane. Un limite alle segnalazioni attive ha poi impedito loro di inviare immediatamente un’altra questione potenzialmente grave.

Apple ha in seguito contattato i ricercatori e indagato sulla falla. Questa azione ha contribuito a produrre una patch, ma è dipesa da un’eccezione al normale percorso di ricezione. Un programma di sicurezza scalabile non può contare sul fatto che i ricercatori ricevano un’attenzione individuale dopo che una coda smette di accettare il loro lavoro.

Perché i cacciatori di bug basati sull’IA stanno sovraccaricando la revisione umana

I cacciatori di bug basati sull’IA cambiano l’economia della scoperta più rapidamente di quanto migliorino l’economia della verifica.

La ricerca tradizionale sulle vulnerabilità richiede molto tempo umano. Un ricercatore studia una base di codice, sviluppa un’ipotesi, la testa, elimina le piste false e redige una segnalazione riproducibile.

L’IA può comprimere alcune parti di questo processo. Un modello può cercare pattern sospetti, confrontare percorsi di codice simili, generare casi di test e suggerire dove potrebbero fallire le ipotesi di autorizzazione.

Questa scala è utile quando il sistema produce prove. Diventa costosa quando un agente trasforma ogni pattern incerto in una segnalazione sicura di sé.

Un team di sicurezza deve comunque riprodurre il comportamento, identificare le versioni interessate, valutare le condizioni di sfruttamento, assegnare la responsabilità e coordinare una correzione. Una spiegazione ben confezionata generata da un modello non riduce questi obblighi.

Le linee guida per le segnalazioni di Apple riflettono questa tensione. Scoraggiano descrizioni lunghe generate dall’IA ed escludono le scoperte teoriche dell’IA prive di una convalida adeguata.

Queste regole sono ragionevoli. I fornitori hanno bisogno di prove riproducibili, non di pagine di ragionamenti speculativi. Tuttavia, i limiti alle segnalazioni sono un controllo grossolano quando un ricercatore invia sia piste deboli sia scoperte ad alto impatto.

Il caso Bynario dimostra la distinzione tra volume generato dall’IA e ricerca sulla sicurezza assistita dall’IA. L’azienda afferma che il suo sistema ha fatto emergere la discrepanza nelle credenziali, ma che gli esseri umani hanno convalidato il risultato dall’inizio alla fine.

Quella convalida includeva controlli negativi. Con l’autenticazione nativa, le operazioni protette fallivano con normali permessi utente. Con il percorso legacy, operazioni simili riuscivano con autorità root.

Questo test differenziale è molto più prezioso del punteggio di fiducia di un modello. Stabilisce che il risultato di sicurezza cambia quando cambia un percorso di autenticazione.

La scoperta ha inoltre superato i test di sfruttamento. I ricercatori sono passati da un’insolita differenza nei permessi alla creazione di file privilegiati e poi all’esecuzione di comandi. Ogni passaggio ha fornito prove concrete per il successivo.

Una segnalazione di bassa qualità spesso non dispone di questa catena. Potrebbe identificare codice sospetto senza dimostrarne la raggiungibilità. Potrebbe descrivere un crash senza provare un impatto sulla sicurezza o presumere che un attaccante controlli dati che restano interni.

I modelli generativi fanno sembrare complete tali segnalazioni. Possono fornire classificazioni delle vulnerabilità, narrazioni d’attacco e linguaggio per la correzione prima che l’affermazione sottostante sia stata dimostrata.

Questo crea un carico di lavoro asimmetrico. Generare dieci segnalazioni plausibili può richiedere meno tempo che smentirne accuratamente una. Il destinatario sostiene la maggior parte del costo quando chi segnala non convalida le proprie scoperte.

Le operazioni di sicurezza IA di Apple affrontano quindi due sfide correlate. L’azienda ha bisogno di controlli migliori nella ricezione delle segnalazioni, ma anche di un percorso per i ricercatori che dimostrano ripetutamente un lavoro affidabile.

I sistemi di reputazione possono aiutare. Una cronologia di segnalazioni convalidate, una proof of concept completa, passaggi di riproduzione deterministici e dati chiari sulle versioni interessate dovrebbero aumentare la priorità di una segnalazione.

Il triage assistito dalle macchine può anche confrontare le segnalazioni, identificare duplicati e testare le affermazioni di base. Tuttavia, usare un altro modello per giudicare l’output non supportato di un modello può amplificare errori condivisi.

L’approccio più solido combina filtraggio automatizzato e falsificazione. Invece di chiedersi se una segnalazione suoni credibile, un sistema di triage dovrebbe testare attivamente le condizioni che la renderebbero falsa.

Ciò richiede accesso a build, log, stati di configurazione e ambienti di test controllati. Richiede inoltre revisori umani che comprendano il confine che la segnalazione afferma di oltrepassare.

La sfida della ricezione continuerà a crescere perché il costo di generare scoperte continua a diminuire. I fornitori che trattano ogni segnalazione allo stesso modo annegheranno nel rumore. Quelli che bloccano indiscriminatamente l’automazione perderanno falle reali.

Gli approcci di Apple e Google divergono a livello di verifica

La differenza tra Apple e Google riguarda meno l’accesso ai modelli di IA e più il modo in cui ciascuna azienda organizza la verifica da parte di esperti.

Google ha avviato Project Zero nel 2014 come gruppo di ricerca specializzato e focalizzato sulle vulnerabilità gravi. Questa esperienza istituzionale ha fornito a Google un processo già esistente per selezionare gli obiettivi, riprodurre le scoperte e divulgare i difetti.

Big Sleep combina questa esperienza nella sicurezza con la ricerca sui modelli di Google DeepMind. Il sistema è progettato per investigare software, testare ipotesi e produrre segnalazioni che passano attraverso la revisione di esperti.

Nell’agosto 2025, Google ha dichiarato che Big Sleep aveva trovato e riprodotto 20 vulnerabilità in progetti open source. Il software interessato includeva, secondo quanto riportato, componenti per media ed elaborazione delle immagini ampiamente utilizzati.

Google non ha divulgato immediatamente i dettagli tecnici perché le correzioni erano ancora in sospeso. Un portavoce ha inoltre affermato che un esperto umano aveva esaminato ogni questione prima della segnalazione, sebbene il sistema avesse trovato e riprodotto autonomamente le vulnerabilità.

Questo controllo umano è la parte cruciale dei risultati di Big Sleep. Non rende il processo completamente autonomo, ma protegge i manutentori dal ricevere output grezzo del modello.

Google Big Sleep opera inoltre all’interno di un team che comprende le scadenze di divulgazione e le dipendenze a valle. Le sue scoperte non vengono semplicemente lasciate in code di fornitori non correlati senza contesto.

Il sistema di divulgazione di Project Zero crea un altro vantaggio. Google tiene traccia di quando un problema è stato segnalato, quando scade una deadline e quando gli utenti interessati ricevono effettivamente una patch.

La sua politica di divulgazione usa una scadenza standard, pur riconoscendo il divario tra una correzione upstream e la sua installazione sul dispositivo di un utente finale. Big Sleep partecipa allo stesso quadro.

Apple dispone di proprie risorse significative di ingegneria della sicurezza. Mantiene funzionalità di hardening della piattaforma, un programma di dispositivi per la ricerca sulla sicurezza e un processo pubblico di bounty.

Il programma bounty di Apple chiede inoltre ai ricercatori descrizioni tecniche e proof of concept. I suoi più recenti target flags forniscono un metodo oggettivo per dimostrare che sono state raggiunte determinate condizioni di sfruttamento.

Quegli investimenti dimostrano che Apple non sta ignorando la ricerca sulle vulnerabilità. Il divario emerso qui riguarda la capacità di gestione e la fiducia quando le segnalazioni automatizzate arrivano dall’esterno dell’organizzazione.

Google controlla sia il sistema AI sia il team di esperti che ne esamina l’output. Apple riceve segnalazioni da molti ricercatori indipendenti che utilizzano modelli, prompt, strumenti e standard di convalida diversi.

Si tratta di un problema di acquisizione più complesso. Apple non può presumere che un agente basato su un modello esterno segua i metodi di Project Zero o che chi segnala abbia testato l’affermazione prima dell’invio.

Apple resta comunque responsabile della progettazione del proprio canale di segnalazione. Se i ricercatori con risultati convalidati non possono inviare un problema serio perché le segnalazioni precedenti restano aperte, il sistema sta ottimizzando la dimensione della coda anziché l’impatto sulla sicurezza.

Un programma maturo richiede più corsie. Un potenziale problema automatizzato e scarsamente documentato può entrare in una coda a bassa priorità, mentre un exploit dimostrato con prove ripetibili riceve immediata attenzione umana.

Apple deve inoltre trovare un modo per aumentare la capacità destinata ai segnalatori affidabili senza incentivare gli invii in massa. Una quota più elevata dovrebbe derivare da una qualità verificata, non semplicemente da una richiesta di maggiore spazio.

L’approccio di Google non è immune dagli errori. Il suo sistema utilizza una costosa supervisione da parte di esperti e i primi risultati pubblici non hanno chiarito l’efficacia di Big Sleep su piattaforme proprietarie.

Resta inoltre poco chiaro quanti candidati il sistema abbia scartato prima di arrivare alle scoperte riportate. Senza quel denominatore, gli osservatori esterni non possono calcolarne il tasso di falsi positivi né il costo di revisione.

La lezione utile è più circoscritta. La scoperta tramite AI funziona meglio quando i modelli operano all’interno di una pipeline di prove con esperti responsabili. La sfida per Apple è riprodurre questo standard in un programma aperto di segnalazioni esterne.

Il compromesso nella sicurezza è tra velocità e segnale

Un maggior numero di scoperte migliora la sicurezza solo quando i fornitori riescono a trasformarle in correzioni verificate prima che gli aggressori utilizzino gli stessi strumenti.

La scoperta di vulnerabilità assistita dall’AI crea pressione su entrambi i lati del processo di divulgazione. I ricercatori possono analizzare più codice, mentre gli attori malevoli possono cercare nello stesso software errori sfruttabili.

Google ha dichiarato nel maggio 2026 di aver interrotto un’attività criminale che coinvolgeva la scoperta di uno zero-day assistita dall’AI. L’azienda non ha rivelato il prodotto interessato né il modello che, secondo quanto riportato, sarebbe stato usato dagli aggressori.

Secondo il resoconto dell’attacco AI, la vulnerabilità poteva aggirare l’autenticazione a due fattori per un prodotto di amministrazione dei sistemi. Google ha dichiarato di aver avvisato il fornitore e le forze dell’ordine prima che si verificassero danni.

I dettagli restano limitati, quindi il caso non stabilisce quanta parte del lavoro sia stata completata dal modello. Mostra però perché i ritardi nell’elaborazione delle segnalazioni comportano ora un rischio maggiore.

Un difetto in attesa in una coda non è statico. Un altro team di ricerca, un gruppo criminale o un operatore sostenuto da uno Stato può scoprirlo indipendentemente. Una ricerca più rapida aumenta la probabilità di questa convergenza.

Apple non può risolvere il problema accettando ogni segnalazione automatizzata. Ciò consumerebbe il tempo dei revisori e ritarderebbe le segnalazioni più rilevanti.

Non può nemmeno risolverlo sopprimendo la ricerca assistita dalle macchine. Il difetto Bynario dimostra che un valido errore di autorizzazione può emergere da un flusso di lavoro automatizzato e superare rigorosi test umani.

Il compromesso corretto è una velocità selettiva. Le segnalazioni con prove solide necessitano di una rapida escalation, mentre le affermazioni incomplete richiedono verifiche automatizzate meno costose prima di raggiungere gli ingegneri senior.

Una segnalazione dovrebbe stabilire la build interessata, la configurazione richiesta, i prerequisiti dell’aggressore, il risultato osservato, il risultato previsto e un test ripetibile. L’impatto sulla sicurezza dovrebbe derivare dalle prove, non da speculazioni generate dal modello.

Per un problema di privilegi, ciò potrebbe significare registrare l’identità del processo durante un’operazione controllata. Per un difetto di memoria, potrebbe includere una traccia di sanitizer e un riproduttore minimo.

I fornitori possono pubblicare modelli strutturati per l’invio basati su questi requisiti. Prove leggibili dalle macchine aiuterebbero il triage automatizzato a testare una segnalazione senza trattare una prosa fluente come prova.

Anche i ricercatori hanno una responsabilità. Inviare decine di scoperte incerte trasferisce al fornitore il costo della convalida e indebolisce la fiducia in ogni invio successivo.

Gli strumenti di sicurezza AI dovrebbero includere una fase di falsificazione prima di generare una segnalazione. L’agente dovrebbe cercare controlli di accesso che gli sono sfuggiti, testare build corrette e non corrette e verificare che l’aggressore dichiarato controlli ogni input necessario.

La revisione umana deve restare obbligatoria per le affermazioni ad alto impatto. Il revisore dovrebbe riprodurre il problema in modo indipendente ed esaminare se l’ambiente di test abbia introdotto una condizione artificiale.

Questo requisito non riduce il valore dell’AI. Indirizza il modello verso il lavoro investigativo ripetitivo in cui la scalabilità è utile, mantenendo al contempo la responsabilità in capo a un ricercatore identificato.

Il pubblico deve inoltre evitare di considerare il numero di vulnerabilità come una classifica. Venti difetti accettati non sono automaticamente più importanti di una catena di attacco verificata.

I conteggi possono premiare scansioni superficiali e segnalazioni duplicate. Misure migliori includono il tempo necessario alla convalida, la gravità confermata, la distribuzione della patch, l’onere dei falsi positivi e l’adozione della correzione da parte degli utenti.

Il limite alle segnalazioni di Apple interviene solo su una di queste misure. Può ridurre il numero di invii aperti, ma non dimostra che le segnalazioni più pericolose raggiungano rapidamente l’ingegnere corretto.

Un triage migliore conterà più di ricompense più alte

Il prossimo vantaggio competitivo nella sicurezza AI sarà una pipeline affidabile dalla scoperta della macchina alla correzione verificata dall’uomo.

Apple offre già incentivi per la ricerca avanzata, ma il denaro da solo non può riparare un processo di acquisizione congestionato. Un ricercatore deve avere la certezza che una scoperta ben documentata venga letta, riprodotta e indirizzata correttamente.

Il primo miglioramento dovrebbe essere la prioritizzazione basata sulle prove. Un proof of concept funzionante, prerequisiti chiari e un impatto convalidato dovrebbero prevalere sull’ordine di invio.

Il secondo dovrebbe essere un accesso graduato. I ricercatori il cui lavoro precedente ha prodotto correzioni confermate potrebbero ricevere maggiori quote di segnalazioni attive e un’escalation tecnica diretta.

Il terzo dovrebbe essere uno stato trasparente. Lunghi periodi senza feedback significativo incoraggiano messaggi duplicati, divulgazioni premature e incertezza sul fatto che una segnalazione abbia raggiunto il team corretto.

Il concetto di flag per i target di Apple va in questa direzione. Segnali oggettivi possono ridurre le dispute sulla sfruttabilità e premiare i ricercatori che dimostrano un controllo significativo.

Tuttavia, i flag coprono solo classi di comportamento definite. Un nuovo difetto logico potrebbe non rientrare in un target preselezionato, soprattutto quando la vulnerabilità attraversa diversi componenti fidati.

CVE-2026-43760 illustra questa difficoltà. Ogni operazione di copia dei file si comportava normalmente in isolamento. L’errore emergeva dall’interazione tra identità di autenticazione, privilegi dell’helper e accesso al filesystem.

Questo tipo di bug richiede ragionamento semantico. L’analisi semantica esamina se il comportamento del sistema corrisponda al suo intento di sicurezza, non semplicemente se il codice vada in crash.

I modelli AI possono aiutare perché riescono a tracciare relazioni tra funzioni e componenti. Possono anche inventare relazioni inesistenti, rendendo essenziale la verifica eseguibile.

Una solida piattaforma di triage conserverebbe il ragionamento del modello separandolo dalle prove. I revisori potrebbero vedere quali affermazioni sono osservate, inferite o ancora non testate.

I team potrebbero applicare lo stesso principio alla documentazione tecnica interna. Una base di conoscenza tecnica ricercabile aiuta a collegare difetti passati, ipotesi di progettazione, risultati dei test e responsabilità senza trattare i riepiloghi generati come autorevoli.

Questo contesto è importante quando una nuova segnalazione assomiglia a un problema precedente. Il sistema dovrebbe identificare componenti e correzioni correlati, mantenendo al contempo l’accesso agli artefatti originali.

Apple potrebbe anche pubblicare dati aggregati sull’elaborazione senza esporre vulnerabilità. Misure utili includono il tempo mediano di convalida, il tasso di duplicati, le richieste di ulteriori informazioni e la quota di segnalazioni chiuse in quanto non supportate.

Una simile rendicontazione chiarirebbe se gli invii AI siano principalmente rumore oppure se la capacità non sia semplicemente riuscita a tenere il passo con la ricerca valida.

Google dovrebbe rispettare lo stesso standard di trasparenza. Pubblicizzare scoperte riuscite senza pubblicarne i costi di revisione offre un quadro incompleto della ricerca automatizzata sulla sicurezza.

Il confronto non dovrebbe trasformarsi nell’affermazione che Google abbia risolto la sicurezza AI. La revisione umana di Big Sleep è un punto di forza, ma è anche la prova che la ricerca autonoma di vulnerabilità necessita ancora di controllo da parte di esperti.

Apple può recuperare senza copiare la struttura organizzativa di Google. Ha bisogno di un sistema di segnalazione che renda le prove dimostrate rare e preziose, anche quando le scoperte proposte diventano abbondanti.

Tre segnali indicheranno se Apple sta recuperando terreno

I prossimi mesi riveleranno se Apple considera questo episodio un problema temporaneo di coda o un cambiamento permanente nella ricerca sulla sicurezza.

Il primo segnale sarà una modifica ai controlli di invio di Apple. Un aggiornamento significativo distinguerebbe i ricercatori con risultati convalidati e gli exploit riproducibili dalle scoperte automatizzate non testate.

Un semplice aumento del limite non sarebbe sufficiente. Aumenterebbe il volume senza migliorare l’ordine in cui le segnalazioni ricevono attenzione.

Un’escalation basata sulle prove rafforzerebbe l’idea che Apple si stia adattando. La continua dipendenza da contatti individuali suggerirebbe che il processo resta fragile.

Il secondo segnale sarà il trattamento riservato da Apple alle scoperte assistite dall’AI nei futuri avvisi di sicurezza. Crediti chiari, descrizioni accurate dell’impatto e dettagli di correzione coerenti dimostrerebbero che l’automazione non riduce il valore di una segnalazione.

Osservate disaccordi come quello relativo a CVE-2026-43760. Valutazioni della gravità differenti sono normali, ma divari inspiegati tra un avviso e un exploit dimostrato rendono più difficile la prioritizzazione per i difensori.

Una descrizione più completa non richiede la pubblicazione di dettagli utilizzabili come arma. I fornitori possono spiegare prerequisiti e impatto trattenendo istruzioni che aiuterebbero gli aggressori.

Il terzo segnale sarà il rendimento di Google Big Sleep e di sistemi simili al di fuori del primo lotto pubblico. Difetti logici confermati, bassi tassi di falsi positivi e un efficiente coordinamento delle patch rafforzerebbero il modello di Google.

Un’ondata di segnalazioni deboli lo indebolirebbe. Lo farebbero anche risultati che dipendono da livelli non documentati di lavoro umano, pur essendo presentati come scoperta autonoma.

Questi segnali sono importanti per gli acquirenti aziendali perché la gestione delle vulnerabilità interessa ogni parco dispositivi. Una funzionalità di sicurezza ha valore limitato quando una segnalazione valida non può raggiungere la revisione o una correzione rilasciata resta non installata.

Anche gli sviluppatori dovrebbero interessarsi al cambiamento degli standard di prova. L’AI può aiutare a ispezionare il codice, ma i responsabili della manutenzione richiederanno sempre più test riproducibili prima di dedicare tempo a una segnalazione.

I ricercatori di sicurezza affrontano la stessa scelta. Possono usare i modelli per aumentare il volume degli invii oppure per costruire esperimenti più solidi, che rendano ogni invio più difficile da respingere.

La competizione tra Apple e Google non è quindi una corsa a generare il maggior numero di affermazioni sulle vulnerabilità. È una corsa a trasformare output incerti delle macchine in azioni difensive affidabili.

Questa corsa ha già raggiunto i comuni team software. Rivedete le vostre regole di acquisizione delle vulnerabilità, definite le prove richieste per l’escalation e verificate se una segnalazione ad alto impatto possa aggirare i limiti ordinari della coda. Se non può farlo, la prossima scoperta valida assistita dall’AI potrebbe esporre il processo prima ancora del codice.