Mille vie in meno per ottenere l’accesso root

La ricerca sulla sicurezza, che un tempo richiedeva un’indagine separata e approfondita per ogni segnalazione, può essere condotta sempre più come un processo sistematico. Questo documento esamina uno dei nostri progetti in quest’ambito.

È sempre più facile cercare vulnerabilità su larga scala, ma l’assegnazione delle priorità e la convalida restano colli di bottiglia operativi. Abbiamo realizzato un prototipo per cercare falle di sicurezza nel kernel Linux all’interno di un ambiente di ricerca controllato. Il nostro prototipo ha individuato e analizzato 2.308 potenziali vulnerabilità del kernel Linux, ne ha riprodotte dinamicamente 1.724 e ha prodotto 948 exploit di escalation locale dei privilegi (LPE) che potrebbero consentire a un utente locale senza privilegi di ottenere l’accesso root.

Abbiamo usato queste prove per stabilire quali vulnerabilità segnalare per prime e sviluppato proposte di patch da sottoporre ai manutentori. Seguendo le indicazioni della comunità del kernel Linux, abbiamo iniziato dalle vulnerabilità critiche e stiamo collaborando con i partner di Patch the Planet a ulteriori segnalazioni e patch.

A giugno, nell’ambito della nostra iniziativa Patch the Planet, abbiamo comunicato che GPT‑5.5 Cyber aveva individuato vulnerabilità nel kernel Linux e sviluppato 24 exploit di escalation locale dei privilegi per convalidarle e segnalarle. Abbiamo ampliato quel lavoro creando una pipeline, basata su un modello cyber di prossima uscita, che comprende individuazione delle vulnerabilità, convalida dinamica, valutazione della sfruttabilità e generazione di patch. Al termine dell’esecuzione, i ricercatori umani hanno esaminato gli output e segnalato le vulnerabilità trovate insieme alle patch.

Il kernel Linux è alla base di dispositivi Android, infrastrutture cloud, supercomputer e altri sistemi usati da miliardi di persone. Con oltre 40 milioni di righe di codice, il kernel espone un’ampia superficie di attacco tramite chiamate di sistema, funzionalità di rete, file system e driver dei dispositivi. Abbiamo scelto Linux per studiare con quale efficacia i modelli di frontiera potessero trovare vulnerabilità e dimostrarne l’impatto sulla sicurezza in una base di codice di queste dimensioni e importanza.

La fase iniziale di individuazione delle vulnerabilità ha prodotto migliaia di potenziali segnalazioni, troppe perché i ricercatori di sicurezza potessero esaminarle e sottoporle a triage manualmente. La sfida operativa della nostra pipeline non era individuare le vulnerabilità, ma determinare quali fossero riproducibili, quale confine di sicurezza oltrepassassero e quali richiedessero l’attenzione più tempestiva dei manutentori.

La missione del team Cyber di OpenAI è contribuire a proteggere il software su cui fa affidamento il mondo. Riportiamo i costi API di ogni fase per aiutare i ricercatori a valutare le risorse necessarie per riprodurre ed estendere questo lavoro. Questi costi rispecchiano i modelli, le configurazioni dei bersagli e il flusso di lavoro usati in questa valutazione. Il nostro obiettivo più ampio è aiutare chi si occupa di difesa a trovare e correggere le vulnerabilità, riducendo le opportunità a disposizione degli attaccanti e aumentando il costo che devono sostenere per sfruttare il software.

Infine, va sottolineato che in questa ricerca ci siamo concentrati sulla metodologia e sulla misurazione delle capacità dei modelli, non sui costi. Riteniamo che un adeguato lavoro di ottimizzazione dell’infrastruttura possa ridurre significativamente il costo di ogni fase; i costi riportati vanno quindi considerati più come un limite superiore.

Il nostro prototipo di ricerca delle vulnerabilità è una pipeline in cinque fasi, basata su un modello cyber di prossima uscita:

• Individuazione delle vulnerabilità: gli agenti identificano le parti del codice rilevanti per la sicurezza e le esaminano alla ricerca di potenziali vulnerabilità.

• Convalida dinamica: gli agenti tentano di riprodurre ogni potenziale vulnerabilità in un ambiente isolato e conservano le prove raccolte durante l’esecuzione. Questo passaggio restituisce le vulnerabilità riprodotte e convalidate.

• Valutazione della sfruttabilità: gli agenti verificano se le vulnerabilità convalidate possano consentire la divulgazione di informazioni o un’escalation locale dei privilegi.

• Generazione di patch: gli agenti generano patch che correggono ciascuna vulnerabilità individuata.

• Revisione umana: i ricercatori di sicurezza esaminano l’exploit, la patch e il livello di gravità proposto prima di inviare la segnalazione ai manutentori.

Al termine della pipeline, il sistema raccoglie un’analisi della causa radice, un proof of concept minimo che provoca un arresto anomalo, una proposta di patch e un exploit completo, per aiutare i ricercatori umani a valutare la gravità della vulnerabilità e a integrare le correzioni nel progetto upstream.

Non tutte le righe di codice del kernel Linux sono rilevanti per la sicurezza. La nostra pipeline ha usato un team di agenti esploratori per individuare le aree di maggior interesse da sottoporre ad audit, poi passate agli agenti analisti per la scansione delle vulnerabilità.

Gli agenti esploratori esaminano ogni cartella e file e determinano quali aree sottoporre ad audit in base alla loro raggiungibilità da parte di utenti con privilegi limitati e alla loro rilevanza per la sicurezza.

Questa fase ha individuato 5.034 aree da sottoporre ad audit, circa 2,8 milioni di righe di codice, pari a circa il 7% dell’intero codice del kernel Linux, riducendo notevolmente il costo dell’audit di sicurezza rispetto a un’analisi completa del codice. Questo passaggio è costato 3.426 dollari in crediti API.

Successivamente, gli agenti analisti hanno analizzato ogni area assegnata e segnalato potenziali vulnerabilità usando un flusso di lavoro simile a quello del plugin Codex Security⁠(si apre in una nuova finestra). In sintesi, gli agenti analisti leggono il codice dell’area assegnata per comprenderne il funzionamento, identificarne il modello di minaccia e cercarvi vulnerabilità.

In 12 ore, gli agenti analisti hanno prodotto 2.308 segnalazioni di potenziali vulnerabilità, al netto dei duplicati. Questa fase è costata 316.549 dollari in crediti API.

Una potenziale vulnerabilità non equivale a una vulnerabilità convalidata. Su questa scala, esaminare manualmente ogni segnalazione non è praticabile per il nostro team di ricerca.

Ci siamo quindi concentrati sulla convalida delle potenziali vulnerabilità che a) erano raggiungibili da un utente con privilegi limitati, b) non richiedevano capability speciali e c) producevano prove misurabili di corruzione della memoria.

Per ciascuna potenziale vulnerabilità, un agente di triage ha generato un proof of concept e lo ha eseguito in una macchina virtuale isolata con un kernel Linux dotato di Kernel Address Sanitizer (KASAN). L’agente ha osservato sia l’output del programma sia la console di sistema, perfezionando poi in modo iterativo il proof of concept finché non ha riprodotto il comportamento segnalato o esaurito i possibili modi per attivarlo.

In 30 ore, il nostro sistema ha riprodotto 1.724 vulnerabilità, circa il 74,7% delle 2.308 potenziali vulnerabilità segnalate. La sola revisione statica del codice può generare falsi positivi: ci hanno quindi colpito l’accuratezza degli agenti analisti e l’efficacia degli agenti di triage nel creare autonomamente proof of concept funzionanti per quasi tre quarti delle potenziali vulnerabilità segnalate.

La maggior parte delle segnalazioni rimanenti richiedeva privilegi elevati oppure non è stata riprodotta entro il tempo disponibile a causa di race condition difficili da innescare, condizioni di attivazione specifiche (ad esempio un errore di allocazione necessario in una determinata riga) o una convalida dispendiosa in termini di tempo (ad esempio il ritorno a zero del contatore dei riferimenti). Solo il 3,1% era dovuto a un’analisi errata del modello, in cui la vulnerabilità segnalata presupponeva una condizione impossibile.

La fase di convalida è costata complessivamente 73.330 dollari in crediti API. Abbiamo osservato che, nella nostra pipeline di convalida, generare un proof of concept per confermare se una potenziale vulnerabilità fosse reale costava più che formulare una raccomandazione basata sulla sola analisi statica. Inoltre, i costi dei tentativi di convalida di veri e falsi positivi erano simili. Eliminare i falsi positivi nelle fasi iniziali della pipeline rende quindi il processo sensibilmente più efficiente sul piano dei costi.

La convalida stabilisce che una vulnerabilità è reale, ma non con quale urgenza debba essere corretta. Una vulnerabilità che potrebbe consentire un’escalation locale dei privilegi, ad esempio, merita una priorità maggiore rispetto a una che potrebbe causare solo una negazione del servizio locale. Con 1.724 vulnerabilità convalidate, il compito successivo era individuare quelle con il maggiore impatto potenziale sulla sicurezza.

Un agente di selezione preliminare ha esaminato staticamente ogni report, log di arresto anomalo e porzione pertinente di codice sorgente. Adottava criteri volutamente permissivi per non scartare segnalazioni potenzialmente gravi, escludendo al contempo i casi senza un percorso di sfruttamento plausibile. Questo ha ristretto i risultati a 313 potenziali fughe di informazioni e 1.238 potenziali escalation locali dei privilegi.

Gli agenti di sviluppo degli exploit (ExploitDev) hanno poi testato questi casi in macchine virtuali isolate, configurate con le protezioni attive in una distribuzione Linux standard, tra cui Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) e HARDENED_USERCOPY. Questo ha contribuito a evitare valutazioni irrealistiche che presupponevano la disattivazione delle protezioni.

Gli agenti hanno prodotto 291 proof of concept di fuga di informazioni e 1.169 exploit funzionanti di escalation locale dei privilegi che potrebbero fornire l’accesso root a utenti locali senza privilegi.

Abbiamo analizzato le varianti e sviluppato 948 patch distinte per le vulnerabilità alla base di questi exploit. Usiamo questo dato per determinare il numero complessivo di vulnerabilità LPE distinte. Lo sviluppo degli exploit riusciti è costato in media 359 dollari in crediti. Questo rende relativamente economico, per chi si occupa di difesa, testare la sfruttabilità delle vulnerabilità trovate.

L’agente di selezione preliminare delle vulnerabilità è costato 44.194 dollari in crediti API. La fase di sfruttamento è costata complessivamente 775.929 dollari in crediti API: 84.929 dollari per elaborare i casi di potenziale fuga di informazioni e 691.000 dollari per quelli di potenziale escalation locale dei privilegi.

In media, elaborare un caso di potenziale escalation locale dei privilegi (558 dollari) è costato circa il doppio rispetto a un caso di potenziale fuga di informazioni (271 dollari). Questo perché i PoC di fuga di informazioni erano già disponibili dalla fase di convalida e richiedevano meno modifiche per essere utilizzabili in un exploit. Sviluppare un exploit da un caso di potenziale LPE richiedeva invece molti passaggi aggiuntivi, come pianificare la strategia di sfruttamento, individuare gli oggetti vulnerabili da usare, aggirare le mitigazioni e altro ancora. Abbiamo inoltre notato che i tentativi di sfruttamento non riusciti (3.922 dollari per 69 casi) costavano molto più di quelli riusciti (360 dollari per 1.169 casi). Questo era dovuto ad alcune vulnerabilità difficili da sfruttare, ad esempio le race condition. Definire una ragionevole condizione di interruzione, ad esempio fermare il tentativo dopo un’ora senza progressi, avrebbe ridotto significativamente il costo di ExploitDev.

Per ogni vulnerabilità convalidata, il sistema genera anche una patch. Forniamo al modello il codice sorgente pertinente e istruzioni sulle buone pratiche di scrittura delle patch, come eseguire controlli statici sulla patch, seguire le pratiche di sviluppo software adottate nel codice circostante e analizzare le varianti per verificare che la patch sia completa.

Seguendo il suggerimento della comunità del kernel Linux, abbiamo già inviato centinaia di segnalazioni e patch per vulnerabilità critiche e stiamo collaborando con i partner di Patch the Planet per inviare gradualmente le patch relative alle altre. Questo lavoro rientra nel nostro più ampio impegno a sostegno dei progetti open source nell’ambito di Daybreak.

In questa sezione condividiamo insegnamenti, riflessioni e ulteriori analisi emersi dalla ricerca.

Durante questa ricerca, abbiamo osservato la rapidità con cui i manutentori di Linux intervenivano per correggere le vulnerabilità e proteggere gli utenti. La scansione è stata eseguita sull’ultima versione del kernel Linux a metà ottobre 2026. Quando la scansione autonoma e l’analisi manuale si sono concluse dopo 10 giorni, 61 vulnerabilità LPE erano già state corrette upstream, 43 disponevano di patch in fase di staging e 299 erano oggetto di segnalazioni e discussioni pubbliche.

Siamo molto grati ai manutentori di Linux, che si sono adoperati con urgenza per correggere i problemi individuati, e all’intera comunità di sicurezza, che ha contribuito con le proprie segnalazioni. È questa risposta collettiva che serve per mettere in sicurezza il software di tutto il mondo. Il ritmo rapido con cui le vulnerabilità vengono divulgate e corrette sottolinea anche quanto sia cruciale per utenti e aziende mantenere il software aggiornato.

Indicazione chiave: il triage automatizzato deve tenere conto della rapidità del ciclo di correzione. Convalidare nuovamente le segnalazioni rispetto al codice più recente, incluso quello integrato dopo la scansione originale, aiuta a evitare segnalazioni duplicate o obsolete. In questo modo l’attenzione si concentra sulle vulnerabilità irrisolte e i manutentori ricevono prove su cui intervenire, senza un inutile carico aggiuntivo di revisione.

Mentre sviluppavamo la pipeline, a fine luglio 2026, GPT‑5.6 Sol ha trovato e sfruttato 166 vulnerabilità LPE distinte, con un costo complessivo di 513.690 dollari in crediti API.

Nella seconda scansione, a metà ottobre 2026, il modello cyber più recente ha trovato e sfruttato 948 vulnerabilità LPE distinte, con un costo complessivo di 1.213.430 dollari in crediti API. In entrambe le campagne, abbiamo esaminato la versione più recente del branch master del kernel Linux disponibile in quel momento.

Indicazione chiave: eseguire nuove scansioni del codice già sottoposto ad audit man mano che migliorano le capacità dei modelli. Un modello più capace può scoprire vulnerabilità sfuggite ai modelli precedenti, anche usando la stessa infrastruttura di ricerca.

Abbiamo selezionato un campione di 166 exploit sviluppati dagli agenti e analizzato le tecniche di sfruttamento utilizzate. Per quanto ne sappiamo, gli agenti hanno usato 10 nuove tecniche di sfruttamento negli exploit del campione. Abbiamo condiviso le tecniche con esperti esterni di sfruttamento del kernel, che a loro volta non le conoscevano.

Delle 10 tecniche, due sono nuovi oggetti elastici persistenti che il modello ha usato per effettuare lo spraying di oggetti nella cache del kernel bersaglio; due sono nuove tecniche di page grooming per migliorare l’affidabilità degli exploit; cinque sono nuove tecniche data-only per ottenere l’escalation dei privilegi direttamente o tramite una scrittura arbitraria; l’ultima prevede una confusione di tipi arbitraria. Per ragioni di sicurezza, in questo articolo non condividiamo tutti i dettagli tecnici di queste nuove tecniche di sfruttamento.

Indicazione chiave: i modelli di frontiera non si limitano a riconoscere schemi noti di codice vulnerabile o a usare esclusivamente tecniche di sfruttamento conosciute; dimostrano creatività e adottano approcci nuovi.

Una parte importante della missione del nostro team consiste nel misurare il costo necessario per trovare e sfruttare le vulnerabilità e nell’usare questi dati per orientare gli investimenti nella difesa. Il nostro obiettivo è aiutare chi si occupa di difesa a correggere le vulnerabilità prima che gli attaccanti possano usarle e rendere economicamente proibitivo sfruttare il software. Misurare i costi di sfruttamento ci aiuta a valutare come cambia questa sfida con il miglioramento delle capacità dei modelli. In questa sezione confrontiamo il costo di esecuzione della nostra pipeline con le ricompense dei programmi bug bounty per le vulnerabilità individuate.

Le macchine virtuali bersaglio del nostro esperimento eseguivano un sistema operativo desktop con configurazione standard, non un bersaglio indebolito, secondo lo stesso modello di minaccia usato nelle competizioni di sicurezza informatica (ad esempio Pwn2Own⁠(si apre in una nuova finestra) e TyphoonPWN⁠(si apre in una nuova finestra)). In passato, Pwn2Own e TyphoonPWN hanno offerto ricompense bug bounty rispettivamente di 20.000 e 70.000 dollari per exploit di escalation locale dei privilegi nel kernel Linux. Applicando questi importi storici ai 948 exploit si ottiene una valutazione ipotetica di 18,9–66,3 milioni di dollari, pari a circa 16–55 volte il costo della nostra pipeline.

Abbiamo anche testato la pipeline nell’ambito del programma di ricompense per le vulnerabilità kernelCTF⁠(si apre in una nuova finestra) di Google, il cui bersaglio è un kernel Linux con sicurezza rafforzata e superfici di attacco ridotte. Abbiamo eseguito la pipeline sull’ultima versione del kernel Linux nell’ambiente kernelCTF, ottenendo 25 proof of concept di fuga di informazioni e 21 exploit di escalation locale dei privilegi. Poiché questa versione era incompatibile con la mitigazione SLAB_VIRTUAL di kernelCTF, l’abbiamo rimossa dalla configurazione. Per confronto, al momento della stesura kernelCTF aveva accettato 26 exploit LPE 0-day confermati nel 2026. L’intera campagna è durata 112 ore ed è costata circa 32.936 dollari in crediti API; l’individuazione delle vulnerabilità ha rappresentato l’83,7% del costo API. Se le 21 vulnerabilità fossero accettate dal programma, frutterebbero una ricompensa di circa 1,5 milioni di dollari, pari a circa 45 volte il costo.

Indicazione chiave: in base agli importi pubblici delle ricompense, al momento di questa ricerca la nostra pipeline di ricerca delle vulnerabilità, con gli attuali modelli dotati di capacità cyber, generava un utile netto. Chi si occupa di difesa dovrebbe analizzare preventivamente il proprio software, così da renderne lo sfruttamento economicamente proibitivo per gli attaccanti.

Durante la valutazione della sfruttabilità, gli agenti ExploitDev ricevevano un report su una vulnerabilità con il compito di creare un exploit pienamente funzionante. La nostra pipeline contrassegnava una vulnerabilità come sfruttata se veniva ottenuta una shell root. Durante una delle prime esecuzioni, la fase di sfruttamento ha segnalato 200 exploit riusciti di escalation locale dei privilegi. Dopo una revisione umana, tuttavia, abbiamo scoperto che 20 di questi avevano ottenuto i privilegi root tramite una vulnerabilità 0-day diversa da quella assegnata. Questo suggerisce che anche gli exploit riusciti sviluppati dagli agenti richiedono una convalida adeguata.

Abbiamo quindi reso più stringenti i vincoli del compito e aggiunto un controllo indipendente per confermare che ogni exploit finale usasse la vulnerabilità assegnata.

Indicazione chiave: nella ricerca autonoma sulla sicurezza, occorre verificare il percorso che porta a un risultato, oltre al risultato stesso; isolamento, monitoraggio e controlli indipendenti sono misure necessarie.

All’inizio di questa ricerca, abbiamo valutato se progettare un’orchestrazione complessa attorno all’agente per migliorarne le capacità cyber. I risultati hanno suggerito che i modelli più capaci richiedono meno orchestrazione e una guida meno dettagliata. Inoltre, il miglioramento marginale non giustifica il costo di manutenzione. Abbiamo quindi deciso di rimuovere l’orchestrazione complessa.

L’esperimento ha confrontato GPT‑5.5 Cyber e GPT‑5.6 Cyber. Abbiamo osservato che GPT‑5.5 Cyber non individuava in modo costante quando e come applicare le tecniche esistenti di sfruttamento del kernel Linux. Abbiamo quindi raccolto 103 tecniche in un formato facilmente utilizzabile dal modello, le abbiamo rese disponibili nell’ambiente dell’agente e gli abbiamo chiesto di usarle. Su 63 potenziali vulnerabilità da sfruttare, questo ha aumentato il tasso di successo dal 76,2% all’88,9%.

Ripetendo l’esperimento con GPT‑5.6 Cyber, il modello si è dimostrato più capace di trovare, selezionare e applicare autonomamente le tecniche pertinenti. Abbiamo rimosso l’orchestrazione delle tecniche e delle skill: questo flusso di lavoro con GPT‑5.6 Cyber, orchestrato in modo leggero, ha superato quello con GPT‑5.5 Cyber, dotato di una struttura di supporto più articolata. Reintrodurre il livello aggiuntivo di tecniche per GPT‑5.6 Cyber ha prodotto solo un miglioramento marginale di 1,5 punti percentuali.

Indicazione chiave: rivalutare l’orchestrazione e l’infrastruttura quando cambiano le capacità del modello di base. Una struttura di supporto che migliora sensibilmente una generazione di modelli può aggiungere poco valore a un modello più capace: occorre quindi valutarne i benefici rispetto ai costi di manutenzione.

Inizialmente, quando gli veniva chiesto direttamente di generare proposte di patch, il modello creava patch funzionalmente corrette che neutralizzavano il proof of concept, ma talvolta introducevano altri problemi: codice più abbondante del necessario, possibili compromessi sulle prestazioni, deviazioni dalle convenzioni di programmazione o mancata analisi del codice correlato alla ricerca di varianti della stessa vulnerabilità, con conseguenti patch incomplete.

Ulteriori istruzioni e revisioni iterative del processo di generazione hanno migliorato la qualità delle patch. Questo suggerisce che, con una gestione adeguata, le patch di sicurezza generate dall’IA possono essere corrette, essenziali e coerenti con le convenzioni del codice esistente. È un ambito di ricerca attivo e riteniamo che i modelli futuri renderanno questo processo più semplice ed efficace. In alcuni casi, il nostro prototipo di ricerca è riuscito anche a individuare problemi nelle patch scritte da esperti umani, che sono stati poi corretti prima dell’integrazione.

Indicazione chiave: i modelli possono accelerare il processo di correzione, ma le skill e le infrastrutture dedicate potrebbero richiedere perfezionamenti iterativi per garantire che le patch soddisfino in modo affidabile i requisiti funzionali e non funzionali. Raccomandiamo inoltre di usare i modelli per revisionare le patch umane e quelle generate dall’IA dal punto di vista di un attaccante, così da individuare problemi come la possibilità di aggirare la patch, percorsi di attacco o varianti non considerati e altro ancora.

Nell’esecuzione su kernelCTF, oltre ai 21 exploit 0-day del kernel Linux, il nostro prototipo di ricerca ha trovato e sfruttato anche una vulnerabilità di QEMU TCG. L’agente analista aveva il compito di analizzare il codice di ingresso delle chiamate di sistema e, mentre scriveva programmi per sperimentare le transizioni di privilegio, ha riscontrato un arresto anomalo inatteso del kernel. Ha eseguito il triage dell’arresto anomalo e ricondotto il problema a QEMU TCG, senza accesso al codice sorgente di QEMU, includendo la vulnerabilità nel report. Successivamente, l’agente ExploitDev ha sviluppato con successo un exploit di escalation locale dei privilegi per questa vulnerabilità. Abbiamo scoperto questa vulnerabilità di QEMU analizzando manualmente gli exploit e confermato che era stata corretta nel progetto upstream di QEMU, ma non nella build di rilascio usata durante l’esperimento.

Indicazione chiave: i modelli di frontiera dotati di capacità cyber possono trovare vulnerabilità nell’infrastruttura di test. Raccomandiamo di testare ogni componente dell’infrastruttura prima di svolgere ricerca offensiva sulle vulnerabilità. Abbiamo testato preventivamente la nostra infrastruttura, segnalando e correggendo numerose vulnerabilità in Kata, Moby/Docker, gVisor e altri progetti.

Il nostro obiettivo è trasformare le crescenti capacità dei modelli in un vantaggio duraturo per chi protegge Internet. Questa ricerca dimostra che le crescenti capacità dei modelli di frontiera in ambito cyber possono essere impiegate per cercare efficacemente vulnerabilità in software complessi, come il kernel Linux. Rafforzare la sicurezza di progetti software critici come Linux e altri progetti open source può proteggere molti sistemi e utenti che ne dipendono.

Attraverso Patch the Planet, un’iniziativa di Daybreak, puntiamo a estendere questa ricerca ad altri progetti software critici e a sviluppare un processo affidabile di correzione automatizzata insieme ai manutentori e ai partner di sicurezza. Vogliamo ridurre progressivamente le opportunità a disposizione degli attaccanti e aumentare il costo necessario per trovare e sfruttare le vulnerabilità, finché il guadagno atteso non giustifichi più l’attacco.

Ogni generazione di modelli dovrebbe aiutarci a creare software più difficili da compromettere per la generazione successiva. Continueremo a lavorare per costruire un Internet sicuro, su cui chiunque possa creare con entusiasmo.