Cu o mie de căi mai puține către accesul root

Cercetarea în securitate, care necesita cândva o investigație separată și susținută pentru fiecare descoperire, poate fi desfășurată tot mai mult ca un proces sistematic. Acest document prezintă unul dintre demersurile noastre în acest domeniu.

Descoperirea vulnerabilităților devine mai ușor de extins la scară largă, însă prioritizarea și validarea rămân blocaje operaționale. Am construit un prototip pentru a căuta deficiențe de securitate în nucleul Linux, într-un mediu de cercetare controlat. Prototipul nostru a identificat și analizat 2.308 potențiale vulnerabilități în nucleul Linux, a reprodus dinamic 1.724 de vulnerabilități și a produs 948 de exploituri de escaladare locală a privilegiilor (LPE), care ar putea permite unui utilizator local fără privilegii să obțină acces root.

Am folosit aceste dovezi pentru a prioritiza vulnerabilitățile de raportat și am dezvoltat patch-uri propuse spre examinare responsabililor de mentenanță. Urmând îndrumările comunității nucleului Linux, am început cu vulnerabilitățile critice și colaborăm cu partenerii Patch the Planet la alte rapoarte și patch-uri.

În iunie, în cadrul inițiativei noastre Patch the Planet, am anunțat că GPT‑5.5 Cyber identificase vulnerabilități în nucleul Linux și dezvoltase 24 de exploituri de escaladare locală a privilegiilor pentru a le valida și raporta. Am dezvoltat acest demers într-un flux bazat pe un viitor model cibernetic, care acoperă descoperirea vulnerabilităților, validarea dinamică, evaluarea posibilității de exploatare și generarea de patch-uri. La încheierea fluxului, cercetătorii umani au examinat rezultatele și au raportat vulnerabilitățile descoperite împreună cu patch-urile.

Nucleul Linux se află la baza dispozitivelor Android, a infrastructurii cloud, a supercalculatoarelor și a altor sisteme folosite de miliarde de oameni. Cu peste 40 de milioane de linii de cod, nucleul expune o suprafață de atac amplă prin apeluri de sistem, funcții de rețea, sisteme de fișiere și drivere de dispozitiv. Am ales Linux pentru a studia cât de eficient pot modelele de vârf să găsească vulnerabilități și să demonstreze impactul lor asupra securității într-o bază de cod de această amploare și importanță.

Etapa inițială de descoperire a vulnerabilităților a produs mii de rezultate potențiale, prea multe pentru ca cercetătorii în securitate să le examineze și să le trieze manual. Provocarea operațională a fluxului nostru nu a fost descoperirea vulnerabilităților, ci stabilirea celor care puteau fi reproduse, a limitelor de securitate pe care le depășeau și a celor care necesitau cel mai urgent atenția responsabililor de mentenanță.

Misiunea echipei Cyber de la OpenAI este să contribuie la securizarea software-ului de care depinde lumea. Raportăm costurile API pentru fiecare etapă pentru a ajuta cercetătorii să evalueze resursele necesare reproducerii și extinderii acestei cercetări. Aceste costuri reflectă modelele, configurațiile țintelor și fluxul de lucru folosite în această evaluare. Obiectivul nostru mai amplu este să ajutăm echipele de apărare să găsească și să remedieze vulnerabilități, reducând oportunitățile atacatorilor și crescând costul exploatării software-ului pentru aceștia.

În încheiere, reține că în această cercetare ne-am concentrat pe metodologie și pe măsurarea capacităților modelelor, nu pe cost. Ne așteptăm ca o optimizare suficientă a cadrului de testare să reducă semnificativ costurile în fiecare etapă; prin urmare, costurile raportate reprezintă mai degrabă o limită superioară.

Prototipul nostru de cercetare a vulnerabilităților este un flux în cinci etape, care are la bază un viitor model cibernetic:

• Descoperirea vulnerabilităților: Agenții identifică părțile bazei de cod relevante pentru securitate și le scanează pentru a găsi potențiale vulnerabilități.

• Validarea dinamică: Agenții încearcă să reproducă fiecare caz într-un mediu izolat și păstrează dovezile din timpul execuției. Rezultatul acestui pas este setul de vulnerabilități reproduse și validate.

• Evaluarea posibilității de exploatare: Agenții testează dacă vulnerabilitățile validate ar putea permite divulgarea informațiilor sau escaladarea locală a privilegiilor.

• Generarea de patch-uri: Agenții generează patch-uri care remediază fiecare vulnerabilitate identificată.

• Revizuirea umană: Cercetătorii în securitate revizuiesc exploitul, patch-ul și nivelul de gravitate propus înainte de a le raporta responsabililor de mentenanță.

La finalul fluxului, sistemul reunește o analiză a cauzei de bază, o demonstrație de concept minimală care provoacă o cădere, un patch propus și un exploit complet, pentru a ajuta cercetătorii umani să evalueze gravitatea vulnerabilității și să integreze remedierile în proiectul sursă.

Nu toate liniile de cod din nucleul Linux au relevanță pentru securitate. Fluxul nostru a folosit o echipă de agenți exploratori pentru a identifica ținte de audit importante, care au fost apoi transmise agenților analiști pentru scanarea vulnerabilităților.

Agenții exploratori parcurg fiecare folder și fișier și stabilesc ce ținte să auditeze în funcție de accesibilitatea lor pentru utilizatorii cu privilegii reduse și de relevanța pentru securitate.

Această etapă a identificat 5.034 de ținte de audit, aproximativ 2,8 milioane de linii de cod, adică circa 7% din întreaga bază de cod a nucleului Linux, reducând semnificativ costul auditului de securitate față de o analiză a întregii baze de cod. Acest pas a costat 3.426 $ în credite API.

Apoi, agenții analiști au analizat fiecare țintă de audit și au identificat potențiale vulnerabilități folosind un flux de lucru similar cu cel al pluginului Codex Security⁠(se deschide într-o fereastră nouă). În linii mari, agenții analiști citesc codul țintei de audit atribuite pentru a înțelege cum funcționează, a identifica modelul de amenințări aplicabil și a căuta vulnerabilități.

În decurs de 12 ore, agenții analiști au identificat 2.308 potențiale vulnerabilități, după eliminarea duplicatelor. Această etapă a costat 316.549 $ în credite API.

O potențială vulnerabilitate nu este totuna cu o vulnerabilitate validată. La această scară, investigarea manuală a fiecărui raport nu este fezabilă pentru echipa noastră de cercetare.

Prin urmare, ne-am concentrat pe validarea vulnerabilităților potențiale care a) puteau fi accesate de un utilizator cu privilegii reduse, b) nu necesitau capabilități speciale și c) produceau dovezi măsurabile de corupere a memoriei.

Pentru fiecare caz, un agent de triaj a generat o demonstrație de concept și a rulat-o într-o mașină virtuală izolată, cu un nucleu Linux care folosea Kernel Address Sanitizer (KASAN). Agentul a urmărit atât ieșirea programului, cât și consola sistemului, apoi a rafinat iterativ demonstrația de concept până când a reprodus comportamentul raportat sau a epuizat posibilele moduri de a-l declanșa.

În decurs de 30 de ore, sistemul nostru a reprodus 1.724 de vulnerabilități, aproximativ 74,7% din cele 2.308 potențiale vulnerabilități. Revizuirea exclusiv statică a codului poate produce rezultate fals pozitive, așa că ne-au impresionat precizia agenților analiști și eficiența agenților de triaj, care au creat autonom demonstrații de concept funcționale pentru aproape trei sferturi dintre vulnerabilitățile potențiale.

Majoritatea cazurilor rămase fie necesitau privilegii ridicate, fie nu au putut fi reproduse în timpul alocat, din cauza unor condiții de cursă dificile, a unor condiții specifice de declanșare (de exemplu, necesitatea unui eșec de alocare la o anumită linie) sau a unei validări de durată (de exemplu, revenirea la zero a contorului de referințe prin depășirea limitei). Doar 3,1% reflectau o analiză incorectă a modelului, în care vulnerabilitatea raportată presupunea o condiție imposibilă.

Etapa de validare a costat în total 73.330 $ în credite API. Am observat că, în fluxul nostru de validare, unde era necesară generarea unei demonstrații de concept pentru a confirma dacă un caz reprezenta o vulnerabilitate reală, acest proces era mai costisitor decât formularea unei recomandări bazate doar pe analiza statică. Costurile încercărilor de validare a rezultatelor adevărat pozitive și fals pozitive erau similare. Prin urmare, eliminarea mai devreme a rezultatelor fals pozitive din flux îmbunătățește semnificativ eficiența costurilor.

Validarea stabilește că o vulnerabilitate este reală, dar nu și cât de urgent trebuie remediată. De exemplu, o vulnerabilitate care ar putea permite escaladarea locală a privilegiilor merită o prioritate mai mare decât una care ar putea provoca doar o indisponibilizare locală a serviciului. Având 1.724 de vulnerabilități validate, următoarea sarcină a fost identificarea celor cu cel mai mare impact potențial asupra securității.

Un agent de selecție inițială a examinat static fiecare raport, jurnal de cădere și cod sursă relevant. Agentul a fost intenționat permisiv pentru a evita eliminarea unor cazuri potențial grave, filtrând totuși cazurile fără o cale plauzibilă de exploatare. Astfel, rezultatele s-au restrâns la 313 cazuri de posibilă divulgare a informațiilor și 1.238 de cazuri de posibilă escaladare locală a privilegiilor.

Agenții de dezvoltare a exploiturilor (ExploitDev) au testat apoi aceste cazuri în mașini virtuale izolate, configurate cu protecțiile activate de o distribuție Linux standard, inclusiv Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) și HARDENED_USERCOPY. Acest lucru a contribuit la evitarea evaluărilor nerealiste care depindeau de dezactivarea protecțiilor.

Agenții au produs 291 de demonstrații de concept pentru divulgarea informațiilor și 1.169 de exploituri funcționale de escaladare locală a privilegiilor, care ar putea oferi acces root utilizatorilor locali fără privilegii.

Am efectuat o analiză a variantelor și am dezvoltat 948 de patch-uri distincte pentru vulnerabilitățile care stăteau la baza acestor exploituri. Folosim această cifră pentru a stabili numărul total de vulnerabilități LPE distincte. Dezvoltarea exploiturilor reușite a costat în medie 359 $ în credite. Prin urmare, echipele de apărare pot testa cu un cost relativ redus dacă vulnerabilitățile descoperite sunt exploatabile.

Agentul de selecție inițială a vulnerabilităților a costat 44.194 $ în credite API. Etapa de exploatare a costat în total 775.929 $ în credite API: 84.929 $ pentru procesarea cazurilor de posibilă divulgare a informațiilor și 691.000 $ pentru cele de posibilă escaladare locală a privilegiilor.

În medie, procesarea unui caz de posibilă escaladare locală a privilegiilor (558 $) a fost de aproximativ două ori mai scumpă decât procesarea unui caz de posibilă divulgare a informațiilor (271 $). Aceasta deoarece PoC-urile pentru divulgarea informațiilor au fost preluate din etapa de validare și necesitau mai puține modificări pentru a putea fi folosite într-un exploit. În schimb, dezvoltarea unui exploit pornind de la un posibil caz LPE necesita numeroși pași suplimentari, precum planificarea strategiei de exploatare, identificarea obiectelor vulnerabile de folosit, ocolirea măsurilor de protecție și altele. Am observat și că încercările nereușite de exploatare (3.922 $ pentru 69 de cazuri) costau mult mai mult decât cele reușite (360 $ pentru 1.169 de cazuri). Acest lucru s-a datorat câtorva vulnerabilități greu de exploatat (de exemplu, condiții de cursă). Definirea unei condiții rezonabile de abandon, precum oprirea încercării după o oră fără progres, ar fi redus semnificativ costul ExploitDev.

Pentru fiecare vulnerabilitate validată, sistemul generează și un patch. Furnizăm modelului codul sursă relevant și îi cerem să respecte bunele practici de scriere a patch-urilor, precum verificarea statică a patch-ului, respectarea practicilor de dezvoltare software folosite în codul învecinat și analiza variantelor pentru a se asigura că patch-ul este complet.

Dând curs sugestiei comunității nucleului Linux, am trimis deja sute de rapoarte și patch-uri pentru vulnerabilități critice și colaborăm cu partenerii Patch the Planet pentru a trimite treptat patch-uri pentru celelalte. Această activitate face parte din angajamentul nostru mai amplu Daybreak de a sprijini proiectele open-source.

În această secțiune prezentăm lecții, reflecții și analize suplimentare rezultate din această cercetare.

Pe parcursul acestei cercetări, am observat că responsabilii de mentenanță Linux acționează rapid pentru a remedia vulnerabilitățile și a proteja utilizatorii. Scanarea a fost efectuată pe cel mai recent nucleu Linux, la mijlocul lunii octombrie 2026. Când scanarea autonomă și analiza manuală s-au încheiat, după 10 zile, 61 de vulnerabilități LPE fuseseră deja remediate în proiectul sursă, 43 aveau patch-uri în curs de integrare, iar 299 erau raportate și discutate public.

Apreciem mult eforturile urgente ale responsabililor de mentenanță Linux de a remedia problemele identificate, precum și contribuțiile întregii comunități de securitate, care își raportează descoperirile. Acest răspuns colectiv este necesar pentru a securiza software-ul din întreaga lume. Ritmul rapid de divulgare și remediere a vulnerabilităților subliniază și cât de important este ca utilizatorii și companiile să își mențină software-ul actualizat.

Concluzie: Triajul automat ar trebui să țină cont de ciclul rapid de remediere. Revalidarea rezultatelor pe cea mai recentă versiune a codului, inclusiv codul nou integrat după scanarea inițială, ajută la evitarea rapoartelor duplicate sau depășite. Astfel, atenția se concentrează asupra vulnerabilităților nerezolvate, iar responsabilii de mentenanță primesc dovezi pe baza cărora pot acționa, fără un volum inutil de verificări.

În timp ce dezvoltam fluxul, la sfârșitul lunii iulie 2026, GPT‑5.6 Sol a găsit și exploatat 166 de vulnerabilități LPE distincte, la un cost total de 513.690 $ în credite API.

La a doua scanare, la mijlocul lunii octombrie 2026, modelul cibernetic mai nou a găsit și exploatat 948 de vulnerabilități LPE distincte, la un cost total de 1.213.430 $ în credite API. În ambele campanii, am scanat cea mai recentă versiune de la acel moment a ramurii master a nucleului Linux.

Concluzie: Scanează din nou codul auditat anterior pe măsură ce capacitățile modelelor se îmbunătățesc. Un model mai capabil poate descoperi vulnerabilități pe care modelele anterioare le-au omis, chiar și folosind același cadru de testare pentru cercetare.

Am selectat un eșantion de 166 de exploituri dezvoltate de agenți și am analizat tehnicile de exploatare folosite. Din câte știm, agenții au folosit 10 tehnici noi de exploatare în exploiturile din eșantion. Am prezentat tehnicile unor experți externi în exploatarea nucleului, iar acestea erau noi și pentru ei.

Dintre cele 10 tehnici, două folosesc obiecte elastice persistente noi, utilizate de model pentru a popula cache-ul țintă al nucleului cu obiecte; două sunt tehnici noi de aranjare a paginilor de memorie pentru a spori fiabilitatea exploitului; cinci sunt tehnici noi care modifică doar datele pentru a obține escaladarea privilegiilor direct sau printr-o scriere arbitrară; cealaltă implică o confuzie arbitrară de tipuri. Din motive de siguranță, nu publicăm în acest articol detaliile tehnice complete ale acestor noi tehnici de exploatare.

Concluzie: Modelele de vârf nu se limitează la recunoașterea unor tipare cunoscute de cod vulnerabil sau la folosirea exclusivă a tehnicilor de exploatare cunoscute; ele demonstrează creativitate și abordări noi.

O parte importantă a misiunii echipei noastre este să măsoare costul descoperirii și exploatării vulnerabilităților și să folosească aceste date pentru a orienta investițiile în apărare. Obiectivul nostru este să ajutăm echipele de apărare să remedieze vulnerabilitățile înainte ca atacatorii să le poată folosi și să facem exploatarea software-ului prohibitiv de costisitoare pentru atacatori. Măsurarea costurilor de exploatare ne ajută să evaluăm cum se schimbă această provocare pe măsură ce capacitățile modelelor se îmbunătățesc. În această secțiune, comparăm costul rulării fluxului nostru cu recompensele oferite de programele de raportare a vulnerabilităților pentru problemele identificate.

Mașinile virtuale țintă din experimentul nostru rulau un sistem de operare desktop standard, nu o țintă cu securitatea diminuată, în cadrul aceluiași model de amenințări folosit în competițiile de securitate cibernetică (de exemplu, Pwn2Own⁠(se deschide într-o fereastră nouă), TyphoonPWN⁠(se deschide într-o fereastră nouă)). În trecut, Pwn2Own și TyphoonPWN au oferit recompense de 20.000 $, respectiv 70.000 $, pentru exploituri de escaladare locală a privilegiilor în nucleul Linux. Aplicând aceste recompense istorice celor 948 de exploituri, obținem o valoare ipotetică de 18,9–66,3 milioane $, de aproximativ 16 până la 55 de ori costul fluxului nostru.

Am testat fluxul și în cadrul programului Google de recompensare a descoperirii vulnerabilităților, kernelCTF⁠(se deschide într-o fereastră nouă), care are drept țintă un nucleu Linux cu securitatea consolidată și suprafețe de atac reduse. Am rulat fluxul pe cea mai recentă versiune a nucleului Linux în mediul kernelCTF și am obținut 25 de demonstrații de concept pentru divulgarea informațiilor și 21 de exploituri de escaladare locală a privilegiilor. Acea versiune era incompatibilă cu măsura de protecție SLAB_VIRTUAL din kernelCTF, așa că am eliminat-o din configurație. Prin comparație, la momentul redactării, kernelCTF acceptase 26 de exploituri LPE de tip zero-day confirmate în 2026. Întreaga campanie a durat 112 ore și a costat aproximativ 32.936 $ în credite API, descoperirea vulnerabilităților reprezentând 83,7% din costul API. Dacă cele 21 de vulnerabilități ar fi acceptate în program, recompensa ar fi de aproximativ 1,5 milioane $, adică de circa 45 de ori costul.

Concluzie: Pe baza valorilor publice ale recompenselor, cu modelele actuale dotate cu capacități cibernetice, fluxul nostru de cercetare a vulnerabilităților era profitabil net la momentul acestei cercetări. Echipele de apărare ar trebui să își analizeze proactiv software-ul, astfel încât exploatarea lui să devină prohibitiv de costisitoare pentru atacatori.

În timpul evaluării posibilității de exploatare, agenții ExploitDev au primit un raport de vulnerabilitate și sarcina de a crea un exploit complet funcțional. Fluxul nostru marca o vulnerabilitate drept exploatată dacă se obținea cu succes un shell root. Într-o rulare timpurie, etapa de exploatare a raportat 200 de exploituri reușite de escaladare locală a privilegiilor. Însă, după examinarea umană, am constatat că 20 dintre acestea obținuseră privilegii root printr-o altă vulnerabilitate zero-day decât cea atribuită. Acest lucru sugerează că până și exploatarea reușită de către agenți necesită o validare corespunzătoare.

Ulterior, am înăsprit restricțiile sarcinii și am adăugat o verificare independentă care confirmă că fiecare exploit final folosește vulnerabilitatea atribuită.

Concluzie: În cercetarea autonomă în securitate, verificați atât rezultatul, cât și calea prin care s-a ajuns la el; izolarea, monitorizarea și verificările independente sunt măsuri de control necesare.

La începutul acestei cercetări, am analizat dacă ar trebui să construim o orchestrare complexă în jurul agentului pentru a-i îmbunătăți capacitățile cibernetice. Rezultatul nostru a sugerat că modelele mai puternice necesită o orchestrare mai simplă și mai puțină îndrumare. În plus, îmbunătățirea marginală nu justifică costul de mentenanță. Prin urmare, am decis să eliminăm orchestrarea complexă.

Experimentul a comparat GPT‑5.5 Cyber și GPT‑5.6 Cyber. Am observat că GPT‑5.5 Cyber nu identifica în mod consecvent când și cum să aplice tehnicile existente de exploatare a nucleului Linux. Am reunit apoi 103 tehnici într-un format ușor de utilizat de către model, le-am pus la dispoziție în mediul agentului și i-am cerut agentului să le folosească. Pentru cele 63 de cazuri candidate la exploatare, acest lucru a crescut rata de succes de la 76,2% la 88,9%.

Când am repetat experimentul cu GPT‑5.6 Cyber, modelul a reușit mai bine să găsească, să selecteze și să aplice singur tehnicile relevante. Am eliminat orchestrarea tehnicilor și competențelor, iar acest flux GPT‑5.6 Cyber cu orchestrare simplificată a depășit performanța fluxului GPT‑5.5 Cyber, care avea o structură de sprijin mai complexă. Reintroducerea stratului suplimentar de tehnici pentru GPT‑5.6 Cyber a adus doar o îmbunătățire marginală de 1,5 puncte procentuale.

Concluzie: Reevaluează orchestrarea și cadrul de testare pe măsură ce capacitățile modelului de bază se schimbă. O structură de suport care îmbunătățește semnificativ o generație de modele poate aduce puțină valoare unui model mai puternic și ar trebui evaluată în raport cu costul mentenanței.

Inițial, când i se solicita direct să genereze patch-uri propuse, modelul crea patch-uri corecte funcțional, care blocau demonstrația de concept, dar uneori introduceau alte probleme: mai mult cod decât era necesar, posibile compromisuri de performanță, abateri de la convențiile de programare sau lipsa examinării codului conex pentru variante ale aceleiași vulnerabilități, ceea ce ducea la patch-uri incomplete.

Instrucțiunile suplimentare și iterațiile asupra procesului de generare au îmbunătățit calitatea patch-urilor. Acest lucru sugerează că, printr-o abordare adecvată, patch-urile de securitate generate de IA pot fi corecte, minimale și conforme cu convențiile existente ale codului. Acesta este un domeniu de cercetare activ, iar noi considerăm că modelele viitoare vor face procesul mai simplu și mai eficient. În câteva cazuri, prototipul nostru de cercetare a reușit să identifice și probleme în patch-uri scrise de experți umani, care au fost apoi corectate înainte de integrare.

Concluzie: Modelele pot accelera procesul de remediere, dar competențele de creare a patch-urilor și cadrele de testare pot necesita iterații pentru a asigura că patch-urile îndeplinesc în mod fiabil atât cerințele funcționale, cât și pe cele nefuncționale. În plus, recomandăm folosirea modelelor pentru examinarea din perspectiva unui atacator a patch-urilor create de oameni și de IA. Aceasta poate identifica probleme precum posibilitatea de a ocoli patch-ul, omiterea altor căi de atac sau variante și altele.

În rularea noastră kernelCTF, pe lângă cele 21 de exploituri zero-day pentru nucleul Linux, prototipul nostru de cercetare a găsit și exploatat și o vulnerabilitate QEMU TCG. Agentul analist primise sarcina de a analiza codul de intrare al apelurilor de sistem și, în timp ce scria programe pentru a experimenta tranzițiile între niveluri de privilegii, a întâlnit o cădere neașteptată a nucleului. A analizat căderea și a localizat problema în QEMU TCG, fără acces la codul sursă QEMU, apoi a inclus vulnerabilitatea în raport. Ulterior, agentul ExploitDev a dezvoltat cu succes un exploit de escaladare locală a privilegiilor pentru această vulnerabilitate. Am descoperit această vulnerabilitate QEMU în timpul analizei manuale a exploiturilor și am confirmat că fusese remediată în proiectul sursă QEMU, dar nu și în versiunea compilată folosită în experiment.

Concluzie: Modelele de vârf cu capacități cibernetice pot găsi vulnerabilități în infrastructura de testare. Recomandăm testarea fiecărei componente a infrastructurii înainte de a efectua cercetări ofensive asupra vulnerabilităților. Ne-am testat proactiv infrastructura, divulgând și remediind numeroase vulnerabilități în Kata, Moby/Docker, gVisor și alte proiecte.

Obiectivul nostru este să transformăm capacitățile tot mai avansate ale modelelor într-un avantaj durabil pentru cei care asigură securitatea internetului. Această cercetare demonstrează că modelele de vârf, cu capacitățile lor cibernetice tot mai avansate, pot fi folosite pentru a căuta eficient vulnerabilități în software complex, precum nucleul Linux. Consolidarea securității unor proiecte software critice, precum Linux și alte proiecte open-source, poate proteja numeroase sisteme și utilizatori care depind de ele.

Prin Patch the Planet, o inițiativă Daybreak, ne propunem să extindem această cercetare la mai multe proiecte software critice și să dezvoltăm un proces fiabil de remediere automată, alături de responsabilii de mentenanță și de partenerii din domeniul securității. Dorim să reducem constant oportunitățile atacatorilor și să creștem costul descoperirii și exploatării vulnerabilităților, până când câștigul scontat nu mai justifică atacul.

Fiecare generație de modele ar trebui să ne ajute să construim software pe care generația următoare să îl compromită mai greu. Vom continua să lucrăm la construirea unui internet sigur, pe care oricine să poată crea cu plăcere.