Projet Glasswing : ce que Mythos nous a révélé

Ces derniers mois, nous avons testé toute une gamme de LLM (Large Language Models, grands modèles linguistiques) orientés sécurité sur notre propre infrastructure. Ces LLMs nous aident à identifier les vulnérabilités potentiellement présentes au sein de nos propres systèmes afin que nous puissions les corriger, tout en nous révélant également ce que les acteurs malveillants pourront accomplir avec les derniers modèles.

Aucun de ces LLM n'a attiré plus d'attention que Mythos Preview d'Anthropic. Il y a quelques semaines, nous avons été invités à utiliser Mythos Preview dans le cadre du projet Glasswing. Nous l'avons bien vite fait pointer vers plus de cinquante de nos propres référentiels afin de voir ce qu'il y trouverait et de découvrir son fonctionnement.

Cet article a pour but de vous faire part de nos observations, des tâches que les modèles ont bien réalisées et de celles qu'elles n'ont pas correctement achevées, mais aussi des évolutions nécessaires de l'architecture et des processus à mettre en place autour de ces modèles pour qu'ils puissent être utilisés à plus grande échelle.

Le modèle Mythos Preview constitue une véritable avancée. Il convient de le dire clairement avant d'aborder quoi que ce soit d'autre. Nous exécutons des modèles sur notre code depuis un certain temps déjà et le passage de ce qui était possible avec les anciens modèles généralistes aux tâches effectuées aujourd'hui par Mythos Preview ne découle pas uniquement de l'affinage des modèles qui l'ont précédé.

C'est un type d'outil différent, qui effectue un travail différent. La comparaison directe avec les modèles antérieurs est donc particulièrement difficile. Plutôt que de tenter de comparer Mythos Preview aux modèles généralistes à la pointe du marché, il est plus utile de décrire ce qu'il peut réellement faire, de même que deux caractéristiques qui se sont distinguées dans les travaux que nous avons réalisés avec Mythos Preview :

• Construction de chaîne d'exploitation : une attaque réelle utilise rarement un seul bug. Elle enchaîne plusieurs petites primitives d'attaque afin de créer un exploit fonctionnel. Elle peut, par exemple, transformer un bug d'utilisation après libération en une primitive de lecture et d'écriture arbitraire, détourner le flux de contrôle et utiliser des chaînes de programmation orientée retour (ROP, Return-Oriented Programming) pour prendre le contrôle total d'un système. Mythos Preview peut prendre plusieurs de ces primitives et raisonner sur la manière de les combiner en une preuve fonctionnelle. Le raisonnement présenté tout au long du processus ressemble au travail d'un chercheur senior plutôt qu'à la sortie d'un scanner automatisé.

• Génération de preuves : le fait d'identifier un bug et de prouver qu'il est exploitable constitue deux éléments différents et Mythos Preview peut effectuer les deux tâches. Il rédige du code susceptible de déclencher le bug suspecté, compile ce code au sein d'un environnement d'essai et l'exécute. Si le programme produit ce que le modèle attendait, il en a désormais la preuve. S'il ne fonctionne pas, le modèle lit l'échec, ajuste son hypothèse et réessaie. Cette boucle est aussi importante que les bugs qu'elle détecte, car un défaut suspecté sans preuve concrète demeure une spéculation. Or, Mythos Preview comble cette lacune de manière autonome.

Certains des aspects que nous décrivons ci-dessus ne sont pas entièrement uniques à Mythos Preview. Les autres modèles de pointe que nous avons soumis au même outil ont identifié un nombre raisonnable des mêmes bugs sous-jacents et, dans certains cas, ont également progressé davantage que prévu sur le plan du raisonnement. Ils ne se sont toutefois pas comportés de manière optimum à l'étape de l'assemblage des pièces du puzzle. Un modèle pouvait ainsi identifier un bug intéressant, rédiger une description réfléchie de son importance, puis s'arrêter, en laissant la chaîne réelle inachevée et la question de l'exploitabilité ouverte. Ce qui diffère avec un LLM tel que Mythos Preview, c'est que ce modèle peut désormais prendre ces bugs de faible gravité (qui resteraient traditionnellement invisibles dans un backlog) et les enchaîner de manière à produire un exploit unique de plus grande sévérité. 

Le modèle Mythos Preview fourni par Anthropic dans le cadre du projet Glasswing ne disposait pas des mesures de sécurité supplémentaires présentes dans les modèles en disponibilité générale (comme Opus 4.7 ou GPT-5.5).

Le modèle rejetait toutefois certaines requêtes de manière organique (un peu comme les cyber-capacités qui le rendent utile pour la chasse aux vulnérabilités). Le modèle dispose de ses propres garde-fous émergents qui provoquent parfois un rejet des requêtes légitimes de recherche de la sécurité. Or, comme nous l'avons constaté, ces refus organiques ne sont pas cohérents. La même tâche, cadrée différemment ou présentée dans un autre contexte, pouvait produire des résultats complètement différents, comme illustré dans les exemples ci-dessous.

^{Exemple de Mythos Preview rejetant la création d'une validation de principe fonctionnelle} 

Le modèle a, par exemple, d'abord refusé d'accomplir une recherche de vulnérabilités pour un projet, puis accepté d'effectuer cette même recherche sur le même code après une modification de l'environnement du projet sans lien avec ce dernier. Rien dans le code analysé n'avait changé. Dans un autre cas, le modèle a trouvé et confirmé plusieurs bugs de mémoire graves au sein d'une base de code, puis refusé de rédiger une démonstration de cet exploit. La même requête, formulée différemment, a abouti sur un résultat différent. La même requête peut ainsi produire des résultats différents lors de différentes exécutions du fait de la nature probabiliste du modèle. Des tâches sémantiquement équivalentes peuvent produire des résultats opposés selon la manière et le moment où elles sont présentées au modèle.

Ce constat revêt une importance particulière, car si les refus organiques/garde-fous du modèle sont bien réels, ils ne sont toutefois pas suffisamment cohérents pour servir de limite de sécurité complète à eux seuls. C'est précisément pour cette raison que n'importe quel modèle à la pointe du marché du cyber qui sera proposé en disponibilité générale à l'avenir devra inclure des garde-fous supplémentaires, en plus de ce comportement de base, afin de convenir à une utilisation plus large en dehors d'un contexte de recherche contrôlé, comme le projet Glasswing.

L'un des éléments les plus difficiles de la hiérarchisation des vulnérabilités de la sécurité consiste à décider quels bugs sont réels, lesquels sont exploitables et lesquels nécessitent une correction immédiate. Il s'agissait déjà d'un problème difficile à résoudre dans le monde pré-IA. Les outils d'analyse des vulnérabilités assistés par IA et le code généré par AI ont aggravé la situation et Cloudflare a ainsi défini plusieurs étapes de post-validation pour y faire face.

Deux facteurs dominent le niveau de bruit :

• Langage de programmation : le C et le C++ vous donnent le contrôle direct de la mémoire et, grâce à cette fonctionnalité, des classes de bugs (attaques par débordement de tampon, lectures et écritures hors limites) que les langages sécurisés du point de vue de la mémoire (ou « memory-safe », comme Rust) éliminent lors de la phase de compilation. Nous avons systématiquement constaté davantage de faux positifs provenant de projets rédigés dans des langages non sécurisés pour la mémoire.

• Biais du modèle : un bon chercheur humain vous indiquera ce qu'il a découvert et avec quel degré de confiance. Pas les modèles. Un modèle auquel vous demanderez de trouver des bugs en trouvera, que le code en contienne ou non. Les constatations reviennent dès lors accompagnées de mots comme « possiblement », « potentiellement » ou « en théorie ». Or, ces observations prudentes surpassent largement les constatations bien établies. S'il s'agit là d'un biais raisonnable pour un outil d'exploration, il s'avérerait désastreux pour une file d'attente de triage, où chaque constatation spéculative consomme de l'attention humaine et des jetons pour être rejetée. Or, ce coût est multiplié par les milliers de constatations.

Mythos Preview représente une nette amélioration à ce niveau, notamment dans sa capacité à enchaîner des primitives, en combinant plusieurs vulnérabilités pour former une validation de principe (PoC, Proof of Concept) fonctionnelle plutôt que de les signaler de manière isolée. Une constatation accompagnée d'une PoC est une constatation sur laquelle vous pouvez agir et qui implique beaucoup moins de temps passé à se demander « Cette constatation est-elle même réelle ? »

Nos outils sont délibérément réglés pour sur-signaler les problèmes afin de nous permettre d'en voir davantage (et de moins en manquer). Or, cette approche entraîne beaucoup plus de bruit. La qualité des résultats de Mythos Preview se révèle toutefois nettement supérieure lors de la phase de triage : moins de constatations floues, des étapes de reproduction plus claires et moins de travail pour prendre une décision de correction ou de rejet.

Lorsque nous avons lancé notre processus de recherche de vulnérabilités assisté par IA l'année dernière, notre instinct était des plus évidents : faire pointer un agent de codage générique vers un référentiel arbitraire et lui demander d'identifier des vulnérabilités. Cette approche fonctionne, dans le sens où le modèle produira des résultats, mais elle n'est pas efficace pour assurer une couverture significative d'une véritable base de code et identifier des résultats de valeur. Cet état de fait s'explique par deux raisons principales :

• Contexte : les agents de codage sont optimisés pour exécuter un flux de travail précis (p. ex. développer une fonctionnalité, corriger un bug ou rédiger un remaniement). Ils ingèrent une grande quantité de code source, tiennent une seule hypothèse à la fois et itèrent sur celle-ci. Cette structure se révèle parfaitement inadéquate en ce qui concerne la recherche de vulnérabilités, par nature étroite et parallèle. Un chercheur humain choisit un aspect spécifique à examiner et l'étudie en profondeur. Cet élément unique peut être une fonctionnalité complexe, des transitions entre différentes limites de sécurité ou une classe de vulnérabilités spécifique, comme les injections de commandes, au sein desquelles les entrées d'un acteur malveillant sont exécutées sous forme de commande shell. Ils réitèrent ensuite ce processus pour une autre fonctionnalité, une limite de sécurité ou une classe de vulnérabilité, plusieurs milliers de fois sur l'ensemble du code. Une session d'agent unique (même de sous-agents) lancée sur un référentiel de cent mille lignes peut couvrir peut-être un dixième de pour cent de la surface de manière utile avant que la fenêtre de contexte du modèle ne se remplisse et que la compaction n'intervienne, potentiellement en éliminant des constatations antérieures qui se seraient révélées importantes.

• Débit : un agent monoflux effectue une tâche à la fois, mais les bases de code réelles nécessitent de nombreuses hypothèses sur de nombreux composants à la fois, avec la possibilité de se déployer davantage lorsqu'un élément intéressant est identifié. Vous pouvez pousser un agent unique plus loin, mais à un certain point, vous cessez d'être limité par le modèle et commencez à être limité par la nature même de l'interaction. L'utilisation du modèle approprié directement au sein d'un agent de codage s'avère adéquate pour une investigation manuelle lorsqu'un chercheur a déjà une piste et souhaite un second avis. Il s'agit toutefois d'un mauvais outil pour atteindre une couverture élevée. Une fois ce fait accepté, nous avons cessé d'essayer de faire accomplir à Mythos Preview une tâche qui ne lui convenait pas et avons plutôt commencé à bâtir l'outil autour de celui-ci.

Quatre leçons ont émergé de la gestion du travail à grande échelle et chacune a souligné la nécessité d'un cadre de gestion de l'exécution à l'échelle mondiale :

• Un champ d'application restreint produit de meilleures constatations : le fait de demander à un modèle de « trouver les vulnérabilités dans ce référentiel » entraîne son errance. Lui demander : « Recherche une injection de commande au sein de cette fonction spécifique, avec cette limite de confiance par-dessus. Voici le document d'architecture et la couverture précédente de cette zone » rapproche bien plus ce modèle du travail réel d'un chercheur.

• L'examen contradictoire réduit le bruit : l'ajout d'un second agent entre la constatation initiale et la file d'attente (avec une invite différente, un modèle différent et aucune capacité à générer ses propres constatations) capte une grande quantité du bruit à côté duquel le premier agent passerait s'il ne contrôlait que son propre travail. Le fait de mettre deux agents en désaccord délibéré s'avère bien plus efficace que de simplement demander à un agent de se montrer minutieux.

• La division de la chaîne entre les agents produit un meilleur raisonnement : les questions « Ce code est-il défectueux ? » et « Un acteur malveillant peut-il réellement atteindre ce bug depuis l'extérieur du système ? » sont toutes deux différentes et le modèle se révèle plus efficace à répondre à chacune d'elles lorsqu'elles sont posées de manière distincte, car chaque question est mieux ciblée que leur version combinée.

• Les tâches étroites en parallèle surpassent un agent exhaustif : la couverture s'améliore lorsque de nombreux agents travaillent sur des questions bien définies et que nous dédupliquons ensuite les résultats plutôt que de demander à un seul agent de se montrer exhaustif.

Chacune de ces observations porte sur le comportement du modèle et, ensemble, décrit un aspect qui ne constitue plus une interface de discussion. Il s'agit-là d'un outil qui vous aidera à obtenir les résultats finaux. Les premières étapes de la création d'un outil sont simples, car vous pouvez demander à votre modèle de vous aider (ce que nous avons d'ailleurs fait). Nous avons utilisé Mythos Preview pour développer, adapter et améliorer nos outils d'origine afin de tirer pleinement parti de ses points forts. L'exemple ci-dessous décrit ce à quoi ressemble ce type d'outil en pratique.

Voici à quoi ressemble notre outil d'identification des vulnérabilités, étape par étape. Nous nous en sommes servis pour analyser le code en direct sur l'ensemble de notre environnement d'exécution, du chemin de données à l'edge, de notre pile de protocoles, de notre interface et des projets open source dont nous dépendons.

Étape	Ses actions	Son importance
Reconnaissance	Un agent lit le référentiel de haut en bas, se déploie aux sous-agents responsables de chaque sous-système et produit un document architectural couvrant les commandes de construction, les limites de confiance, les points d'entrée et la surface d'attaque probable. Il génère également la file d'attente initiale des tâches pour l'étape suivante.	Cette étape assure un contexte partagé à chaque agent situé en aval. Elle résout également le problème d'errance.
Traque	Chaque tâche se présente comme une classe d'attaque associée à un indice de portée. Les traqueurs (c.-à-d. les agents qui recherchent effectivement les bugs) fonctionnent de manière simultanée, généralement une cinquantaine à la fois, chacun se déployant vers une poignée de sous-agents d'exploration. Chaque traqueur a accès à des outils permettant de compiler et d'exécuter le code d'une validation de principe au sein d'un répertoire temporaire par tâche.	La plus grosse partie du travail s'effectue ici. Déploiement de nombreuses tâches étroites en parallèle, pas d'un agent exhaustif.
Validation	Un agent indépendant relit le code et tente de réfuter la constatation initiale. Il utilise une invite différente et n'a pas la capacité de produire de nouvelles constatations par lui-même.	Cette étape capture une fraction significative du bruit que le traqueur ne remarquerait pas en révisant son propre travail.
Comblement des lacunes	Les traqueurs signalent les zones qu'ils ont touchées, mais qu'ils n'ont pas complètement couvertes. Ces secteurs sont replacés en file d'attente pour un autre passage.	Cette étape contrebalance la tendance du modèle à se diriger vers les classes d'attaque avec lesquelles il a déjà obtenu des résultats.
Déduplication	Les constatations qui partagent la même cause racine entraînent leur réduction sous un seul enregistrement.	L'analyse des variantes est une fonctionnalité, pas un moyen de gonfler la file d'attente par des doublons.
Traçage	Pour chaque constatation confirmée au sein d'une bibliothèque partagée, un agent traceur se déploie (une instance par référentiel consommateur), utilise un index de symboles inter-référentiels et détermine si une entrée contrôlée par un acteur malveillant peut effectivement entrer en contact avec le bug depuis l'extérieur du système.	Cette étape transforme la constatation « Une faille est présente » en « Une vulnérabilité est accessible ». C'est l'étape qui compte le plus.
Retour d'expérience	Les traces atteignables deviennent de nouvelles tâches de traque au sein des référentiels consommateurs dans lesquels le bug est effectivement exposé.	Cette étape ferme la boucle. Le pipeline s'améliore au fur et à mesure de son exécution.
Rapport	Un agent rédige un rapport structuré selon un schéma prédéfini, corrige toute erreur de validation selon ce même schéma et envoie le rapport à une API d'ingestion.	La sortie se présente sous la forme de données interrogeables, pas d'un texte en prose libre.

La réaction la plus forte à Mythos Preview des autres responsables de la sécurité portait sur la vitesse : analyser plus vite, appliquer les correctifs plus rapidement, compresser le cycle de réponse. Plus d'une équipe avec laquelle nous avons parlé fonctionne désormais sous un SLA de deux heures entre la publication d'une CVE et la mise en production du correctif. La réponse instinctive est compréhensible : lorsque la chronologie de l'acteur malveillant se raccourcit, la chronologie de l'entreprise en défense doit également se raccourcir en conséquence. Il ne suffira pas de se montrer plus rapide et nous pensons que de nombreuses équipes sont sur le point de consacrer beaucoup de temps, d'efforts et d'argent à comprendre ce fait à leurs dépens.

L'accélération du déploiement des correctifs ne modifie pas la structure du pipeline qui les produit. Si les tests de régression demandent une journée, vous ne pouvez pas proposer un SLA de deux heures sans ignorer ce délai. De même, les bugs que vous transmettez lorsque vous sautez l'étape des tests de régression ont tendance à se révéler pires que ceux que vous essayez de corriger. Nous avons appris une version de ce principe lorsque nous avons tenté de laisser le modèle rédiger ses propres correctifs et observé certains de ces correctifs corriger le bug initial, tout en brisant discrètement un autre élément sur lequel le code dépendait.

La question la plus difficile repose sur le fait de savoir à quoi l'architecture autour d'une vulnérabilité devrait ressembler. Le principe ici consiste à compliquer l'exploitation d'une vulnérabilité plus difficile par un acteur malveillant même lorsqu'un bug existe, de sorte que l'écart entre le moment de la divulgation d'une vulnérabilité et le déploiement de son correctif importe moins. Cette approche implique la mise en place de mesures de défense qui se placent devant l'application afin d'empêcher les cybercriminels d'entrer en contact avec le bug. Elle implique aussi de concevoir l'application de manière à ce qu'une faille dans une partie du code ne puisse pas permettre à un acteur malveillant d'accéder à d'autres parties du réseau. Elle implique enfin de pouvoir déployer un correctif partout où le code est exécuté en simultané plutôt que d'attendre que les différentes équipes le déploient. 

Nous reconnaissons également que ce sujet s'avère à double tranchant. Entre de mauvaises mains, les mêmes capacités que celles qui nous ont aidés à identifier les bugs dans notre propre code pourraient accélérer les attaques contre chaque application située sur Internet. Cloudflare se place devant des millions de ces applications et les principes architecturaux décrits ci-dessus sont exactement ceux que nos produits sont conçus pour appliquer au nom de nos clients. Nous partagerons davantage d'informations sur les implications pour nos clients dans les semaines à venir.

N'hésitez pas à nous contacter sur security-ai-research@cloudflare.com si votre équipe effectue un travail similaire et souhaite comparer ses notes de recherche.

Nos recherches sur Mythos Preview ont été conduites au sein d'un environnement contrôlé et sur notre propre code. Chaque vulnérabilité identifiée a été triée, validée et corrigée lorsque l'opération s'avérait nécessaire dans le cadre du processus formel de gestion des vulnérabilités en vigueur chez Cloudflare.

Ce travail fut avant tout un effort d'équipe. Merci à Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl et Rohit Chenna Reddy pour leurs contributions à la recherche, à l'ingénierie et à l'analyse qui nous ont permis d'élaborer cet article.