Mille chemins de moins vers l’accès root

La recherche en sécurité, qui exigeait autrefois une enquête distincte et soutenue pour chaque résultat, peut de plus en plus être menée comme un processus systématique. Ce document présente l’un de nos efforts dans ce domaine.

Il devient plus facile de découvrir des vulnérabilités à grande échelle, mais la priorisation et la validation demeurent des goulots d’étranglement opérationnels. Nous avons créé un prototype pour rechercher des failles de sécurité dans le noyau Linux au sein d’un environnement de recherche contrôlé. Notre prototype a repéré et analysé 2 308 vulnérabilités potentielles du noyau Linux, reproduit dynamiquement 1 724 vulnérabilités et produit 948 codes d’exploitation d’élévation locale de privilèges (LPE) pouvant permettre à un utilisateur local sans privilèges d’obtenir un accès root.

Nous avons utilisé ces preuves pour prioriser les vulnérabilités à signaler et élaboré des correctifs proposés à l’examen des responsables de la maintenance. Conformément aux recommandations de la communauté du noyau Linux, nous avons commencé par les vulnérabilités critiques et travaillons avec les partenaires de Patch the Planet sur d’autres rapports et correctifs.

En juin, dans le cadre de notre initiative Patch the Planet, nous avons annoncé que GPT‑5.5 Cyber avait repéré des vulnérabilités du noyau Linux et développé 24 codes d’exploitation d’élévation locale de privilèges pour les valider et les signaler. Nous avons étendu ce travail à un pipeline, propulsé par un modèle de cybersécurité à venir, couvrant la découverte de vulnérabilités, la validation dynamique, l’évaluation de l’exploitabilité et la génération de correctifs. Une fois son exécution terminée, des chercheurs humains ont examiné les résultats et signalé les vulnérabilités découvertes en fournissant des correctifs.

Le noyau Linux est à la base des appareils Android, de l’infrastructure infonuagique, des superordinateurs et d’autres systèmes utilisés par des milliards de personnes. Avec plus de 40 millions de lignes de code, le noyau expose une vaste surface d’attaque par les appels système, la réseautique, les systèmes de fichiers et les pilotes de périphériques. Nous avons choisi Linux pour étudier l’efficacité avec laquelle les modèles de pointe peuvent trouver des vulnérabilités et démontrer leurs répercussions sur la sécurité dans une base de code de cette envergure et de cette importance.

L’étape initiale de découverte de vulnérabilités a produit des milliers de résultats potentiels, trop nombreux pour que les chercheurs en sécurité puissent les examiner et les trier manuellement. Le défi opérationnel de notre pipeline de découverte de vulnérabilités n’était pas la découverte elle-même, mais de déterminer quels résultats pouvaient être reproduits, quelle frontière de sécurité ils franchissaient et lesquels méritaient l’attention la plus rapide des responsables de la maintenance.

La mission de l’équipe Cyber d’OpenAI est d’aider à sécuriser les logiciels dont le monde dépend. Nous présentons les coûts de l’API pour chaque étape afin d’aider les chercheurs à évaluer les ressources nécessaires pour reproduire et prolonger ce travail. Ces coûts reflètent les modèles, les configurations cibles et le flux de travail utilisés dans cette évaluation. Notre objectif plus large est d’aider les défenseurs à trouver et à corriger les vulnérabilités, en réduisant les occasions offertes aux attaquants et en augmentant le coût de l’exploitation des logiciels pour eux.

Enfin, notons que cette recherche portait sur la méthodologie et la mesure des capacités des modèles, et non sur le coût. Nous estimons qu’un travail d’ingénierie suffisant sur le harnais pourrait réduire sensiblement le coût de chaque étape; les coûts présentés constituent donc plutôt une borne supérieure.

Notre prototype de recherche de vulnérabilités est un pipeline en cinq étapes qui repose sur un modèle de cybersécurité à venir :

• Découverte de vulnérabilités : Les agents repèrent les parties du code pertinentes pour la sécurité et les analysent pour détecter des vulnérabilités potentielles.

• Validation dynamique : Les agents tentent de reproduire chaque vulnérabilité potentielle dans un environnement isolé et conservent les preuves d’exécution. Cette étape produit les vulnérabilités reproduites et validées.

• Évaluation de l’exploitabilité : Les agents vérifient si les vulnérabilités validées pourraient permettre une divulgation d’information ou une élévation locale de privilèges.

• Génération de correctifs : Les agents génèrent des correctifs pour chaque vulnérabilité repérée.

• Révision humaine : Les chercheurs en sécurité examinent le code d’exploitation, le correctif et le niveau de gravité proposé avant de transmettre le rapport aux responsables de la maintenance.

À la fin du pipeline, le système regroupe une analyse de la cause racine, une preuve de concept minimale provoquant un plantage, un correctif proposé et un code d’exploitation complet pour aider les chercheurs humains à évaluer la gravité de la vulnérabilité et à faire intégrer les correctifs en amont.

Toutes les lignes de code du noyau Linux ne sont pas pertinentes pour la sécurité. Notre pipeline a utilisé une équipe d’agents éclaireurs pour repérer les cibles d’audit à forte valeur, qui ont ensuite été transmises aux agents analystes pour la recherche de vulnérabilités.

Les agents éclaireurs parcourent chaque dossier et fichier et déterminent les cibles à auditer selon leur accessibilité aux utilisateurs dotés de faibles privilèges et leur pertinence pour la sécurité.

Cette étape a permis de repérer 5 034 cibles d’audit, soit environ 2,8 millions de lignes de code représentant environ 7 % de l’ensemble du code du noyau Linux, ce qui réduit considérablement le coût de l’audit de sécurité par rapport à une analyse complète du code. Cette étape a coûté 3 426 $ en crédits API.

Ensuite, les agents analystes ont analysé chaque cible d’audit et produit des résultats potentiels à l’aide d’un flux de travail semblable à celui du plugiciel Codex Security⁠(s'ouvre dans une nouvelle fenêtre). Dans les grandes lignes, les agents analystes lisent le code de la cible d’audit assignée pour en comprendre le fonctionnement, déterminer son modèle de menace et y rechercher des vulnérabilités.

En 12 heures, les agents analystes ont produit 2 308 résultats potentiels après déduplication. Cette étape a coûté 316 549 $ en crédits API.

Un résultat potentiel n’équivaut pas à une vulnérabilité validée. À cette échelle, notre équipe de recherche ne peut pas examiner manuellement chaque rapport.

Nous avons donc concentré la validation sur les résultats qui a) étaient accessibles à un utilisateur doté de faibles privilèges, b) ne nécessitaient aucune capacité spéciale et c) produisaient des preuves mesurables de corruption de la mémoire.

Pour chaque résultat potentiel, un agent de triage a généré une preuve de concept et l’a exécutée dans une machine virtuelle isolée utilisant un noyau Linux avec Kernel Address Sanitizer (KASAN). L’agent a observé la sortie du programme et la console système, puis affiné la preuve de concept de façon itérative jusqu’à reproduire le comportement signalé ou à épuiser les moyens possibles de le déclencher.

En 30 heures, notre système a reproduit 1 724 vulnérabilités, soit environ 74,7 % des 2 308 résultats potentiels. La revue statique du code à elle seule peut produire des faux positifs. Nous avons donc été impressionnés par la précision des agents analystes et par l’efficacité des agents de triage à créer de manière autonome des preuves de concept fonctionnelles pour près des trois quarts des résultats potentiels.

La plupart des résultats restants nécessitaient des privilèges élevés ou n’ont pas pu être reproduits dans le temps imparti en raison de conditions de concurrence difficiles, de conditions de déclenchement précises (p. ex. un échec d’allocation nécessaire à une ligne précise) ou d’une validation longue (p. ex. un bouclage du compteur de références). Seuls 3,1 % résultaient d’une analyse incorrecte du modèle, où la vulnérabilité signalée reposait sur une condition impossible.

L’étape de validation a coûté au total 73 330 $ en crédits API. Nous avons constaté que, dans notre pipeline de validation, qui devait générer une preuve de concept pour confirmer qu’un résultat potentiel était une véritable vulnérabilité, ce processus coûtait plus cher qu’une recommandation fondée uniquement sur une analyse statique, et que les tentatives de validation d’un vrai positif et d’un faux positif avaient des coûts similaires. Éliminer les faux positifs plus tôt dans le pipeline rend donc le processus nettement plus rentable.

La validation établit qu’une vulnérabilité est réelle, mais pas l’urgence avec laquelle elle doit être corrigée. Une vulnérabilité pouvant permettre une élévation locale de privilèges, par exemple, mérite une priorité plus élevée qu’une autre pouvant seulement causer un déni de service local. Avec 1 724 vulnérabilités validées, la tâche suivante consistait à repérer les résultats ayant les répercussions potentielles les plus importantes sur la sécurité.

Un agent de filtrage initial a examiné chaque rapport, journal de plantage et extrait de code source pertinent par analyse statique. Il était délibérément permissif pour éviter d’écarter des résultats potentiellement graves, tout en filtrant les cas sans piste d’exploitation plausible. Ce filtrage a retenu 313 vulnérabilités susceptibles d’entraîner une fuite d’information et 1 238 susceptibles de permettre une élévation locale de privilèges.

Des agents de développement de codes d’exploitation (ExploitDev) ont ensuite testé ces vulnérabilités potentielles dans des machines virtuelles isolées configurées avec les protections activées par une distribution Linux standard, notamment Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) et HARDENED_USERCOPY. Cela a permis d’éviter des évaluations irréalistes reposant sur la désactivation des protections.

Les agents ont produit 291 preuves de concept de fuite d’information et 1 169 codes d’exploitation fonctionnels d’élévation locale de privilèges pouvant donner un accès root à des utilisateurs locaux sans privilèges.

Nous avons effectué une analyse des variantes et développé 948 correctifs distincts pour les vulnérabilités à l’origine de ces codes d’exploitation. Nous utilisons ce nombre pour déterminer le nombre total de vulnérabilités LPE uniques. Le développement des codes d’exploitation réussis a coûté en moyenne 359 $ en crédits. Il est donc relativement peu coûteux pour les défenseurs de tester l’exploitabilité des vulnérabilités découvertes.

L’agent de filtrage initial des vulnérabilités a coûté 44 194 $ en crédits API. L’étape d’exploitation a coûté au total 775 929 $ en crédits API, soit 84 929 $ pour le traitement des fuites d’information potentielles et 691 000 $ pour les élévations locales de privilèges potentielles.

En moyenne, le traitement d’une vulnérabilité susceptible de permettre une élévation locale de privilèges (558 $) coûtait environ deux fois plus cher que celui d’une vulnérabilité susceptible d’entraîner une fuite d’information (271 $). Cela s’explique par le fait que les PoC de fuite d’information provenaient de l’étape de validation et nécessitaient moins de modifications pour devenir utilisables dans un code d’exploitation. En revanche, le développement d’un code d’exploitation à partir d’une vulnérabilité LPE potentielle exigeait de nombreuses étapes supplémentaires, comme la planification de la stratégie d’exploitation, le repérage des objets vulnérables à utiliser et le contournement des mesures d’atténuation. Nous avons aussi constaté que les tentatives d’exploitation infructueuses coûtaient beaucoup plus cher que les tentatives réussies, soit en moyenne 3 922 $ par cas pour les 69 échecs contre 360 $ par cas pour les 1 169 réussites. Cela était dû à quelques vulnérabilités difficiles à exploiter (p. ex. des conditions de concurrence). Définir un critère d’arrêt raisonnable, comme interrompre la tentative après une heure sans progrès, aurait considérablement réduit le coût d’ExploitDev.

Pour chaque vulnérabilité validée, le système génère aussi un correctif. Nous fournissons au modèle le code source pertinent et lui donnons des instructions sur les bonnes pratiques de rédaction de correctifs, comme effectuer des vérifications statiques du correctif, suivre les pratiques de développement logiciel utilisées dans le code voisin et réaliser une analyse des variantes pour s’assurer que le correctif est complet.

À la suggestion de la communauté du noyau Linux, nous avons déjà envoyé des centaines de rapports et de correctifs pour des vulnérabilités critiques et travaillons avec les partenaires de Patch the Planet pour envoyer progressivement les correctifs restants. Ce travail s’inscrit dans notre engagement plus large Daybreak à soutenir les projets à code source ouvert.

Dans cette section, nous présentons les leçons tirées, les réflexions et les analyses supplémentaires issues de cette recherche.

Au cours de cette recherche, nous avons constaté que les responsables de la maintenance de Linux agissaient rapidement pour corriger les vulnérabilités et protéger les utilisateurs. L’analyse a été réalisée sur la dernière version du noyau Linux à la mi-octobre 2026. Lorsque l’analyse autonome et l’analyse manuelle se sont terminées après 10 jours, 61 vulnérabilités LPE avaient déjà été corrigées en amont, 43 disposaient de correctifs en attente d’intégration et 299 faisaient l’objet de signalements et de discussions publics.

Nous remercions sincèrement les responsables de la maintenance de Linux, qui travaillent d’urgence à corriger les problèmes repérés, ainsi que l’ensemble de la communauté de la sécurité, qui contribue aussi ses découvertes. Cette réponse collective est indispensable pour sécuriser les logiciels du monde entier. Le rythme rapide de divulgation et de correction des vulnérabilités souligne aussi à quel point il est essentiel pour les utilisateurs et les entreprises de tenir leurs logiciels à jour.

À retenir : Le triage automatisé devrait tenir compte du cycle rapide de correction. Revalider les résultats par rapport au code le plus récent, y compris le nouveau code fusionné après l’analyse initiale, aide à éviter les rapports en double ou obsolètes. Cela concentre l’attention sur les vulnérabilités non résolues et fournit aux responsables de la maintenance des preuves exploitables sans alourdir inutilement la charge de révision.

Pendant le développement du pipeline, à la fin de juillet 2026, GPT‑5.6 Sol a trouvé et exploité 166 vulnérabilités LPE uniques, pour un coût total de 513 690 $ en crédits API.

Lors de la deuxième analyse, à la mi-octobre 2026, le nouveau modèle de cybersécurité a trouvé et exploité 948 vulnérabilités LPE uniques, pour un coût total de 1 213 430 $ en crédits API. Pour les deux campagnes, nous avons analysé la version la plus récente de la branche master du noyau Linux à ce moment-là.

À retenir : Analysez de nouveau le code déjà audité à mesure que les capacités des modèles s’améliorent. Un modèle plus performant peut découvrir des vulnérabilités que les modèles précédents ont manquées, même avec le même harnais de recherche.

Nous avons échantillonné 166 codes d’exploitation développés par les agents et analysé les techniques d’exploitation qu’ils utilisaient. À notre connaissance, les agents ont utilisé 10 nouvelles techniques d’exploitation dans les codes échantillonnés. Nous avons présenté ces techniques à des experts externes en exploitation du noyau, pour qui elles étaient également nouvelles.

Parmi les 10 techniques, deux sont de nouveaux objets élastiques persistants que le modèle a utilisés pour disperser des objets dans le cache cible du noyau; deux sont de nouvelles techniques d’agencement des pages mémoire pour améliorer la fiabilité de l’exploitation; cinq sont de nouvelles techniques fondées uniquement sur les données pour obtenir une élévation de privilèges directement ou au moyen d’une écriture arbitraire; la dernière repose sur une confusion de type arbitraire. Pour des raisons de sécurité, nous ne présentons pas tous les détails techniques de ces nouvelles techniques d’exploitation dans cet article.

À retenir : Les modèles de pointe ne se contentent pas de reconnaître des motifs connus de code vulnérable ni d’utiliser uniquement des techniques d’exploitation connues; ils font preuve de créativité et d’approches inédites.

Une partie importante de la mission de notre équipe consiste à mesurer le coût de la découverte et de l’exploitation des vulnérabilités, puis à utiliser ces données pour orienter les investissements défensifs. Notre objectif est d’aider les défenseurs à corriger les vulnérabilités avant que les attaquants puissent les utiliser, et de rendre le coût d’exploitation des logiciels prohibitif pour les attaquants. Mesurer les coûts d’exploitation nous aide à évaluer l’évolution de ce défi à mesure que les capacités des modèles s’améliorent. Dans cette section, nous comparons le coût d’exécution de notre pipeline aux primes des programmes de récompenses pour les vulnérabilités repérées.

Les machines virtuelles cibles de notre expérience utilisaient un système d’exploitation de bureau standard, et non une cible affaiblie, selon le même modèle de menace que les compétitions de cybersécurité (p. ex. Pwn2Own⁠(s'ouvre dans une nouvelle fenêtre), TyphoonPWN⁠(s'ouvre dans une nouvelle fenêtre)). Par le passé, Pwn2Own et TyphoonPWN offraient respectivement des primes de 20 000 $ et de 70 000 $ pour les codes d’exploitation d’élévation locale de privilèges du noyau Linux. L’application de ces montants historiques aux 948 codes d’exploitation donne une valeur hypothétique de 18,9 à 66,3 M$, soit environ 16 à 55 fois le coût de notre pipeline.

Nous avons aussi testé notre pipeline dans l’environnement du programme de récompenses pour les vulnérabilités ⟦1⟧kernelCTF⟦1⟧ de Google, dont la cible est un noyau Linux renforcé aux surfaces d’attaque réduites.⟦2⟧ ⟦2⟧Nous avons exécuté le pipeline sur la dernière version du noyau Linux dans l’environnement kernelCTF. Comme cette version était incompatible avec la mesure d’atténuation SLAB_VIRTUAL de kernelCTF, nous avons retiré cette mesure de la configuration. Nous avons obtenu 25 preuves de concept de fuite d’information et 21 codes d’exploitation d’élévation locale de privilèges. À titre de comparaison, au moment de la rédaction, kernelCTF avait accepté en 2026 26 codes d’exploitation LPE de vulnérabilités de type jour zéro confirmées. La campagne a duré 112 heures au total et coûté environ 32 936 $ en crédits API, la découverte de vulnérabilités représentant 83,7 % du coût de l’API. Si les 21 vulnérabilités étaient acceptées par le programme, elles donneraient droit à une prime d’environ 1,5 M$, soit environ 45 fois le coût.

À retenir : Selon les montants des primes rendus publics, avec les modèles actuels dotés de capacités en cybersécurité, notre pipeline de recherche de vulnérabilités dégageait un bénéfice net au moment de cette recherche. Les défenseurs devraient analyser leurs logiciels de façon proactive pour rendre leur exploitation prohibitive pour les attaquants.

Pendant l’évaluation de l’exploitabilité, les agents ExploitDev recevaient un rapport de vulnérabilité et avaient pour tâche de créer un code d’exploitation entièrement fonctionnel. Notre pipeline indiquait qu’une vulnérabilité avait été exploitée lorsqu’un interpréteur de commandes root avait été obtenu. Lors d’une première exécution, l’étape d’exploitation a signalé 200 codes d’exploitation réussis d’élévation locale de privilèges. Cependant, après une révision humaine, nous avons constaté que 20 d’entre eux avaient obtenu les privilèges root au moyen d’une autre vulnérabilité de type jour zéro que celle assignée. Cela laisse penser que même une exploitation réussie par des agents nécessite une validation adéquate.

Nous avons ensuite resserré les contraintes de la tâche et ajouté une vérification indépendante confirmant que chaque code d’exploitation final utilisait bien la vulnérabilité assignée.

À retenir : Pour la recherche autonome en sécurité, vérifiez le chemin menant au résultat en plus du résultat lui-même; l’isolation, la surveillance et les vérifications indépendantes sont des contrôles nécessaires.

Au début de cette recherche, nous avons envisagé de bâtir une orchestration lourde autour de l’agent pour améliorer ses capacités en cybersécurité. Notre résultat indiquait que les modèles plus performants nécessitent moins d’orchestration et d’accompagnement. Et l’amélioration marginale ne justifie pas le coût de maintenance. Nous avons donc décidé de supprimer l’orchestration lourde.

L’expérience comparait GPT‑5.5 Cyber et GPT‑5.6 Cyber. Selon nos observations, GPT‑5.5 Cyber ne déterminait pas systématiquement quand et comment appliquer les techniques existantes d’exploitation du noyau Linux. Nous avons alors rassemblé 103 techniques dans un format adapté au modèle, les avons rendues accessibles dans l’environnement de l’agent et lui avons demandé de les utiliser. Sur 63 vulnérabilités candidates à l’exploitation, cela a fait passer le taux de réussite de 76,2 % à 88,9 %.

Lorsque nous avons répété l’expérience avec GPT‑5.6 Cyber, le modèle était mieux à même de trouver, de sélectionner et d’appliquer lui-même les techniques pertinentes. Nous avons retiré l’orchestration des techniques et des compétences, et ce flux de travail GPT‑5.6 Cyber à orchestration légère a surpassé le flux de travail GPT‑5.5 Cyber plus lourdement encadré. Le rétablissement de la couche de techniques supplémentaire pour GPT‑5.6 Cyber n’a apporté qu’une amélioration marginale de 1,5 point de pourcentage.

À retenir : Réévaluez votre orchestration et votre harnais à mesure que les capacités du modèle de base évoluent. Un encadrement qui améliore nettement une génération de modèles peut apporter peu de valeur à un modèle plus performant et devrait être évalué au regard des coûts de maintenance.

Au départ, lorsqu’on lui demandait directement de générer des correctifs proposés, le modèle créait des correctifs fonctionnellement corrects qui neutralisaient la preuve de concept, mais introduisaient parfois d’autres problèmes : plus de code que nécessaire, des compromis potentiels sur les performances, des écarts par rapport aux conventions de programmation ou l’absence d’examen du code connexe pour y rechercher des variantes de la même vulnérabilité, ce qui menait à des correctifs incomplets.

Des instructions supplémentaires et des itérations sur le processus de génération ont amélioré la qualité des correctifs, ce qui laisse penser qu’avec un encadrement adéquat, les correctifs de sécurité générés par l’IA peuvent être corrects, minimaux et conformes aux conventions du code existant. Il s’agit d’un domaine de recherche actif, et nous pensons que les futurs modèles rendront ce processus plus facile et plus efficace. Dans quelques cas, notre prototype de recherche a aussi pu repérer des problèmes dans des correctifs rédigés par des experts humains. Ces problèmes ont été résolus avant la fusion des correctifs.

À retenir : Les modèles peuvent accélérer le processus de correction, mais il peut falloir affiner les compétences et les cadres d’exécution utilisés pour produire les correctifs afin que ceux-ci répondent de façon fiable aux exigences fonctionnelles et non fonctionnelles. Nous recommandons aussi d’utiliser des modèles pour examiner les correctifs produits par des humains ou par l’IA du point de vue d’un attaquant. Cet examen peut notamment révéler qu’un correctif peut être contourné ou qu’il laisse d’autres voies d’attaque ou variantes de la vulnérabilité sans protection.

Lors de notre exécution kernelCTF, en plus des 21 codes d’exploitation de vulnérabilités de type jour zéro du noyau Linux, notre prototype de recherche a aussi trouvé et exploité une vulnérabilité de QEMU TCG. L’agent analyste était chargé d’analyser le code d’entrée des appels système et, en écrivant des programmes pour expérimenter les transitions de privilèges, il a rencontré un plantage inattendu du noyau. Il a effectué le triage du plantage et retracé le problème jusqu’à QEMU TCG, sans accès au code source de QEMU, puis a inclus la vulnérabilité dans le rapport. L’agent ExploitDev a ensuite réussi à développer un code d’exploitation d’élévation locale de privilèges pour cette vulnérabilité. Nous avons découvert cette vulnérabilité de QEMU lors de l’analyse manuelle des codes d’exploitation et confirmé qu’elle avait été corrigée dans QEMU en amont, mais pas dans la version distribuée utilisée pendant l’expérience.

À retenir : Les modèles de pointe dotés de capacités en cybersécurité peuvent trouver des vulnérabilités dans l’infrastructure de test. Nous recommandons de tester chaque partie de l’infrastructure avant de mener des recherches offensives sur les vulnérabilités. Nous avons testé notre infrastructure de façon proactive, divulguant et corrigeant de nombreuses vulnérabilités dans Kata, Moby/Docker, gVisor et d’autres projets.

Notre objectif est de transformer les capacités croissantes des modèles en un avantage durable pour les personnes qui sécurisent Internet. Cette recherche montre que les capacités croissantes des modèles de pointe en cybersécurité peuvent servir à rechercher efficacement des vulnérabilités dans des logiciels complexes, comme le noyau Linux. Renforcer la sécurité de projets logiciels critiques comme Linux et d’autres projets à code source ouvert peut protéger de nombreux systèmes et utilisateurs en aval.

Avec Patch the Planet, une initiative Daybreak, nous visons à étendre cette recherche à davantage de projets logiciels critiques et à développer des méthodes fiables de correction automatisée avec les responsables de la maintenance et les partenaires en sécurité. Nous voulons réduire progressivement les occasions offertes aux attaquants et augmenter le coût de la découverte et de l’exploitation des vulnérabilités, jusqu’à ce que le gain attendu ne justifie plus l’attaque.

Chaque génération de modèles devrait nous aider à créer des logiciels que la génération suivante aura plus de mal à compromettre. Nous continuerons à bâtir un Internet sécurisé sur lequel tout le monde pourra créer avec plaisir.