Project Glasswing : ce que Mythos a montré
(blog.cloudflare.com)- Mythos Preview a construit des chaînes d’exploit en combinant plusieurs primitives à partir de plus de 50 dépôts de Cloudflare, au-delà de la simple détection de bugs isolés
- Il ne s’est pas arrêté à la détection de bugs suspects : il a aussi écrit du code de déclenchement, compilé et exécuté dans un environnement temporaire, puis révisé ses hypothèses après échec, de façon itérative, pour produire une preuve de fonctionnement
- Même dans le cadre d’une recherche légitime sur les vulnérabilités, des refus spontanés sont apparus, mais ils variaient selon le contexte et la formulation, ce qui les rendait trop peu cohérents pour servir de frontière de sécurité
- Les agents de code généralistes ont des limites en matière de couverture de grands dépôts et d’exploration en parallèle ; Cloudflare a donc construit un harnais exécutant en parallèle des tâches étroites
- Pour les équipes sécurité, il ne suffit plus de scanner et de patcher plus vite : l’architecture devient essentielle pour faire en sorte que, même en présence de bugs, l’exploitation ou l’accès restent difficiles
Comment Mythos Preview a changé la manière de faire de la recherche sur les vulnérabilités
- Ces derniers mois, Cloudflare a testé sur sa propre infrastructure des LLM centrés sur la sécurité, et a reçu Mythos Preview d’Anthropic dans le cadre de Project Glasswing, avant de l’appliquer à plus de 50 de ses dépôts internes
- Mythos Preview ressemblait moins à une simple amélioration incrémentale des modèles frontier généralistes existants qu’à un nouvel outil capable d’exécuter différentes étapes de la recherche sur les vulnérabilités
- Le changement clé tient au fait qu’il ne se contente pas d’énumérer des bugs individuels, mais assemble plusieurs primitives d’attaque pour construire une chaîne d’exploit
- Dans une attaque réelle, on n’utilise généralement pas un seul bug : on transforme par exemple un use-after-free en primitive de lecture/écriture arbitraire, on détourne le flux de contrôle, puis on obtient le contrôle du système avec une chaîne ROP
- Mythos Preview a relié ce type de primitives en preuves de fonctionnement effectives, avec un raisonnement plus proche de celui d’un chercheur expérimenté que d’un scanner automatisé
- Un autre changement important est sa capacité à produire lui-même une preuve de fonctionnement après avoir trouvé un bug suspect
- Il écrit du code de déclenchement, le compile dans un environnement temporaire, puis l’exécute
- Si le comportement attendu se produit, cela devient une preuve ; sinon, il lit l’échec, ajuste son hypothèse et réessaie
- Un défaut sans preuve de fonctionnement reste au stade de la supposition, mais Mythos Preview a réduit lui-même cet écart
- Avec le même harnais, d’autres modèles frontier ont eux aussi trouvé certains bugs de base et ont parfois raisonné plus loin qu’attendu, mais la différence s’est faite au moment d’assembler plusieurs éléments en une chaîne réelle
- Mythos Preview a su relier des bugs qui seraient traditionnellement restés dans le backlog avec une faible sévérité en un exploit unique plus grave
Des refus du modèle, même dans une recherche légitime sur les vulnérabilités
- Le Mythos Preview fourni pour Project Glasswing n’incluait pas les garde-fous supplémentaires présents dans des modèles grand public comme Opus 4.7 ou GPT-5.5
- Malgré cela, le modèle a manifesté une réticence spontanée face à certaines requêtes, révélant, en plus de capacités cyber utiles à la détection de vulnérabilités, des garde-fous émergents
- Ces refus spontanés n’étaient pas cohérents
- Pour une même tâche, une simple différence de formulation ou de contexte pouvait produire un résultat complètement différent
- Il a par exemple d’abord refusé une recherche sur les vulnérabilités d’un projet, puis accepté le même travail sur le même code après une modification sans rapport de l’environnement du projet
- Dans certains cas, après avoir trouvé et confirmé plusieurs bugs mémoire graves dans une base de code, il a refusé d’écrire un exploit de démonstration
- Une même requête pouvait aussi produire des résultats différents d’une exécution à l’autre en raison de la nature probabiliste du modèle
- Les refus spontanés et les garde-fous existent bel et bien, mais ils ne sont pas assez cohérents pour constituer à eux seuls une frontière de sécurité complète
- Pour rendre des modèles cyber frontier performants disponibles au grand public, il faut des protections supplémentaires afin qu’ils puissent être utilisés correctement hors d’un environnement de recherche contrôlé comme Project Glasswing
Le problème du signal et du bruit
- Dans le tri des vulnérabilités de sécurité, la chose la plus difficile est de déterminer quels bugs sont réels, exploitables et doivent être corrigés immédiatement
- Ce problème était déjà difficile avant l’IA ; les scanners de vulnérabilités dopés à l’IA et le code généré par IA l’ont aggravé, et Cloudflare a donc mis en place plusieurs étapes de post-validation
-
Langages de programmation
- Le C et le C++ donnent un contrôle direct sur la mémoire et créent des classes de bugs comme les buffer overflows et les lectures/écritures hors limites
- Les langages à mémoire sûre comme Rust éliminent ces classes au moment de la compilation
- Les projets écrits dans des langages non memory-safe ont montré de manière cohérente davantage de faux positifs
-
Biais du modèle
- Un bon chercheur humain indique ce qu’il a trouvé et à quel point il en est certain, mais un modèle a tendance à produire un résultat qu’il y ait ou non réellement un bug dans le code
- Les résultats reviennent atténués avec des formulations comme « possibly », « potentially » ou « could in theory », et ces résultats spéculatifs étaient bien plus nombreux que les résultats solides
- C’est un biais raisonnable pour un outil d’exploration, mais dans une file de triage, chaque résultat spéculatif consomme de l’attention humaine et des tokens, et le coût devient important lorsqu’ils s’accumulent par milliers
- Mythos Preview a montré une amélioration nette dans sa capacité de chaînage de primitives : au lieu de rapporter plusieurs vulnérabilités séparément, il les combinait en un PoC fonctionnel
- Les résultats accompagnés d’un PoC sont beaucoup plus proches de résultats immédiatement actionnables, ce qui réduit fortement le temps passé à vérifier « est-ce que c’est réel ? »
- Le harnais de Cloudflare est volontairement réglé pour rapporter davantage afin de manquer moins de choses, ce qui génère beaucoup de bruit ; malgré cela, les sorties de Mythos Preview contenaient moins de formulations atténuées et des étapes de reproduction plus claires, réduisant le travail nécessaire pour décider de corriger ou d’écarter un résultat
Les limites d’une application directe d’agents de code généralistes à des dépôts
- Au début de la recherche sur les vulnérabilités assistée par IA, il était naturel de prendre un agent de code généraliste, de lui donner un dépôt arbitraire et de lui demander d’y trouver des vulnérabilités
- Cette approche produit des résultats, mais elle n’était pas adaptée pour couvrir de manière significative une vraie base de code et trouver des résultats réellement utiles
-
Contexte
- Les agents de code sont conçus pour un flux de travail focalisé unique, comme l’implémentation d’une fonctionnalité, la correction d’un bug ou le refactoring
- La recherche sur les vulnérabilités ressemble davantage à une série de tâches étroites et parallèles : examiner en profondeur une fonctionnalité complexe unique, un changement de frontière de sécurité ou une injection de commande, puis répéter cela des milliers de fois à l’échelle de toute la base de code
- Même avec des sous-agents, une session d’agent unique sur un dépôt de 100 000 lignes ne peut couvrir utilement qu’environ 0,1 % de la surface avant que la fenêtre de contexte du modèle ne soit saturée et que la compression ne commence
- Lors du processus de compression, des résultats antérieurs potentiellement importants peuvent aussi être perdus
-
Débit
- Un agent mono-flux ne peut traiter qu’une seule tâche à la fois
- Une vraie base de code exige la capacité d’appliquer simultanément de nombreuses hypothèses à plusieurs composants, puis de bifurquer plus largement lorsque des points intéressants apparaissent
- Lorsqu’un chercheur a déjà un indice et a besoin d’un second regard, un agent de code peut convenir à une enquête manuelle
- En revanche, il est mal adapté comme outil de haute couverture, ce qui a poussé Cloudflare à construire un harnais autour de Mythos Preview
Ce que le harnais a permis de résoudre
- L’expérience acquise à grande échelle a conduit à la conclusion qu’il fallait un harnais pour piloter l’ensemble de l’exécution
-
Un périmètre étroit donne de meilleurs résultats
- Demander « trouve des vulnérabilités dans ce dépôt » fait errer le modèle
- Des requêtes du type « examine cette fonction précise pour détecter une injection de commande ; voici la frontière de confiance en amont, la documentation d’architecture et la couverture existante dans cette zone » produisent des résultats beaucoup plus proches du travail réel d’un chercheur
-
Une revue contradictoire réduit le bruit
- Placer un deuxième agent entre les résultats initiaux et la file d’attente permet de filtrer une grande partie du bruit que le premier agent laisserait passer lors d’une auto-relecture
- Le deuxième agent utilise un autre prompt et un autre modèle, mais n’a pas le droit de générer ses propres résultats
- Il s’est avéré bien plus efficace de placer volontairement deux agents en désaccord que de simplement dire à un seul agent d’être prudent
-
Diviser la chaîne par agent améliore le raisonnement
- « Y a-t-il un bug dans ce code ? » et « un attaquant peut-il réellement atteindre ce bug depuis l’extérieur du système ? » sont deux questions différentes
- En les séparant, chaque question devient plus étroite, et le modèle se montre meilleur sur chacune d’elles
-
Des tâches étroites parallèles battent un agent unique englobant
- La couverture est meilleure lorsqu’un grand nombre d’agents traitent des questions étroitement définies, puis que les résultats sont dédupliqués
- Cette approche s’est révélée plus efficace que de demander l’exhaustivité à un agent unique
- Cloudflare a utilisé Mythos Preview pour étendre, ajuster et améliorer son harnais existant en fonction de ses points forts
Le harnais de découverte de vulnérabilités de Cloudflare
- Ce harnais sert à scanner du code réel dans le runtime de Cloudflare, le chemin de données edge, les piles de protocoles, le control plane et les projets open source dont l’entreprise dépend
-
Recon
- Un agent lit le dépôt de haut en bas, puis se divise en sous-agents, chacun responsable d’un sous-système
- Il génère une documentation d’architecture contenant les commandes de build, les frontières de confiance, les points d’entrée et la surface d’attaque attendue
- Il crée aussi une file initiale de tâches à transmettre à l’étape suivante, fournissant à tous les agents suivants un contexte partagé qui limite les dérives du modèle
-
Hunt
- Chaque tâche se compose d’une classe d’attaque et d’indices de périmètre
- Les agents chasseurs qui trouvent les vrais bugs s’exécutent généralement par groupes d’environ 50 en parallèle, et chacun se divise à son tour en quelques sous-agents d’exploration
- Chaque chasseur a accès à des outils permettant de compiler et d’exécuter du code PoC dans un répertoire temporaire propre à la tâche
- La plupart des travaux reposent sur l’exécution parallèle de nombreuses tâches étroites, et non sur un agent unique englobant
-
Validate
- Un agent indépendant relit le code et tente de réfuter le résultat d’origine
- Il utilise un autre prompt et ne peut pas produire de nouveaux résultats par lui-même
- Il capte une part significative du bruit que le chasseur laisse passer lorsqu’il revoit son propre travail
-
Gapfill
- Le système marque les zones que les chasseurs ont touchées sans les couvrir suffisamment
- Ces zones sont réinjectées dans la file pour un autre passage
- Cela compense la tendance du modèle à se concentrer sur les classes d’attaque où il a déjà réussi
-
Dedupe
- Les résultats qui partagent la même cause racine sont fusionnés en un seul enregistrement
- L’analyse des variantes est une fonctionnalité, pas une manière de gonfler la file avec des doublons
-
Trace
- Pour chaque résultat confirmé dans une bibliothèque partagée, un agent traceur se divise en un agent par dépôt consommateur
- Il utilise un index inter-dépôts des symboles pour déterminer si une entrée contrôlée par l’attaquant peut réellement atteindre le bug depuis l’extérieur du système
- C’était l’étape la plus importante pour transformer « il y a un défaut » en « il y a une vulnérabilité atteignable »
-
Feedback
- Les résultats traçables et atteignables deviennent de nouvelles tâches de chasse dans les dépôts consommateurs où le bug est réellement exposé
- Cela ferme une boucle qui améliore le pipeline au fil des exécutions
-
Report
- Les agents rédigent des rapports structurés selon un schéma prédéfini
- Ils corrigent eux-mêmes les erreurs de validation du schéma et soumettent le tout à l’API d’ingestion
- La sortie n’est pas une prose libre, mais une donnée interrogeable
Ce que cela signifie pour les équipes sécurité
- D’autres responsables sécurité ayant vu Mythos Preview ont cherché à compresser leur cycle de réponse en scannant plus vite et en patchant plus vite
- Au moins une des équipes avec lesquelles Cloudflare a échangé fonctionnait avec un SLA de 2 heures entre la publication d’une CVE et le patch en production
- Si le calendrier des attaquants se raccourcit, celui des défenseurs doit lui aussi se raccourcir, mais la vitesse seule ne suffit pas
- Patcher plus vite ne change pas la forme du pipeline qui produit les correctifs
- Si les tests de régression prennent une journée, on ne peut pas atteindre un SLA de 2 heures sans les contourner
- Et un bug déployé en contournant les tests de régression peut être pire que le bug que l’on cherchait à corriger au départ
- Lorsque des modèles ont directement rédigé des patchs, certains correctifs ont bien supprimé le bug d’origine tout en cassant silencieusement d’autres parties dont le code dépendait
- La question la plus difficile est plutôt de savoir comment concevoir l’architecture autour des vulnérabilités
- Même lorsqu’un bug existe, il faut rendre son exploitation difficile pour l’attaquant
- Il faut faire en sorte que l’intervalle entre la publication d’une vulnérabilité et son correctif soit moins critique
- Il faut des défenses capables de bloquer l’accès au bug en amont de l’application
- Il faut concevoir l’application de sorte qu’un défaut dans une partie du code ne donne pas à un attaquant un accès à d’autres parties
- Il faut pouvoir déployer simultanément des correctifs partout où le code s’exécute, sans attendre le déploiement de chaque équipe individuellement
- Ces capacités ont aussi une dimension à double tranchant
- La capacité à trouver des bugs dans son propre code peut, entre de mauvaises mains, accélérer aussi les attaques contre toutes les applications sur Internet
- Cloudflare indique être placée devant des millions d’applications et affirme que ses produits ont été conçus pour appliquer, au nom des clients, les principes architecturaux décrits ci-dessus
- La recherche sur Mythos Preview a été menée dans un environnement contrôlé sur le propre code de Cloudflare, et toutes les vulnérabilités découvertes ont été triées et validées selon le processus officiel de gestion des vulnérabilités de Cloudflare, puis corrigées si nécessaire
2 commentaires
Je pensais que c’était un rapport d’analyse des erreurs corrigées, comme
curl, mais en fait c’est juste un pur article promotionnel, non ?Même Cloudflare s’est emballé en sortant un paywall réservé aux agents IA et un endpoint de résumé, et maintenant ils ont complètement perdu le nord.
Avis Hacker News
Je ne comprends pas ce que veut dire « c’est un type d’outil différent pour un type de travail différent, donc il est difficile de faire une comparaison propre, de pomme à pomme, avec les modèles précédents »
On parle d’un type d’outil différent, mais au final son mode d’utilisation est décrit exactement comme celui des autres modèles. C’était bien moins bon qu’un billet Cloudflare moyen, et j’ai surtout eu l’impression d’une redite de la présentation de Mythos, qui insistait sur le chaining et la création d’exemples comme éléments centraux
Oui, tout le monde l’utilise avec un harnais, et la manière générale de donner un harnais à un modèle ne devrait pas beaucoup changer à l’avenir. Les humains aussi ont parfois besoin d’un harnais pour accomplir certaines tâches
Dans la lecture la plus charitable, il est possible qu’ils restent volontairement vagues sur ce qui est réellement différent à cause d’un NDA
Ces derniers temps, presque toutes les productions de Cloudflare ont une forte odeur d’IA
Il est surprenant qu’un modèle conçu pour la recherche en sécurité et ouvert uniquement aux experts refuse des requêtes légitimes
Je m’attendais à des chiffres plus précis et à des résultats frappants, mais cela ressemble juste à un texte promotionnel bien équilibré, probablement écrit par un LLM
[1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...
La vraie question, c’est de savoir si ce texte a été écrit par Mythos ou par Opus
Des formules comme « pourquoi c’est important » n’ont en réalité rien d’important. Les blogs d’entreprise ont rarement eu une voix d’auteur unique, mais voir même de grandes organisations sous-traiter leurs blogs à des LLM reste intéressant
J’ai maintenant envie de faire passer « pourquoi c’est important » au niveau de « les sorties d’IA deviennent une partie des données d’entraînement ». Un jour, ce style IA poli et verbeux deviendra probablement la norme, au point qu’en dehors des générations précédentes, il sera difficile de faire la différence. C’est un peu comme regretter certains aspects d’Usenet
C’est un peu comme regarder dans le canon d’une arme tout en plaisantant sur le type de papier utilisé pour imprimer le dépliant publicitaire
C’est sans doute aussi pour cela que Claude Code a autant de bugs étranges, et que le support annonce parfois un remboursement qui, en réalité, n’arrive pas
J’ai trouvé amusantes les « quatre leçons » censées provenir de l’exécution de ce travail à grande échelle. Trois sur quatre disent pratiquement la même chose et relèvent de l’évidence
En résumé, des demandes spécifiques et étroites fonctionnent mieux que « trouve des vulnérabilités », ce qui n’a rien de surprenant. Cela dit, même si la revue adversariale n’a rien de nouveau et a déjà été beaucoup discutée sur HN, c’est au moins un aspect intéressant et distinctif. Il faut que j’essaie de l’intégrer davantage à mon workflow, et cela pourrait aussi être utile pour des tâches non liées au code
https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...
Le passage « la réaction principale des responsables sécurité face à Mythos Preview a été la vitesse : scanner plus vite, corriger plus vite, compresser les cycles de réponse. Parmi les équipes à qui nous avons parlé, au moins deux fonctionnent avec un SLA de 2 heures entre la divulgation d’un CVE et le correctif en production [...] Si les tests de régression prennent une journée, il est impossible d’atteindre un SLA de 2 heures sans les sauter, et si on les saute, on risque facilement de déployer un bug pire que celui qu’on essayait initialement de corriger » m’a marqué
Je me demande si, avec le temps, ce type de modèle pourra effectuer des tests d’exploitabilité avant la fusion du code et ainsi produire par défaut du code plus sûr
*par « eux », j’entends tous les fournisseurs de modèles de base, car OpenAI semble aussi aller dans cette direction
D’accord, c’est sans doute bien, mais j’aimerais savoir à quel point la vulnérabilité la plus grave qu’ils ont trouvée était réellement sérieuse
Ils ne veulent probablement pas le révéler, mais c’est de loin la partie la plus intéressante et importante
Beaucoup voient Mythos comme une campagne d’opérations psychologiques, mais je comprends mal ce scepticisme. Il semble surtout venir d’une méfiance générale envers ce qui n’est pas accessible publiquement. Quelques employés d’Anthropic ont présenté Mythos comme une amélioration de modèle généraliste, mais ce point n’est pas encore largement étayé, donc je reste sceptique là-dessus. En revanche, pour le domaine de la recherche en sécurité, je peux accepter ce récit
Vu sous cet angle, fermer des vulnérabilités n’est pas la même chose que trouver des exploits. Il s’agit plutôt de laisser moins de petites brèches, de sorte qu’il devienne de plus en plus difficile d’assembler un exploit fonctionnel
Donc, même si ses « hard skills » ne se sont pas énormément améliorées, il peut les combiner bien plus efficacement. Aujourd’hui déjà, une bonne partie de ces vulnérabilités peut être identifiée avec Opus, mais pour arriver à des exploits complexes, il faut encore un humain au milieu, et plutôt un humain compétent. Si l’on n’a plus besoin d’intervention humaine, il devient bien plus facile pour une personne moyenne de trouver et d’exploiter des vulnérabilités
https://security.paloaltonetworks.com
Très bien, mais je ne comprends pas pourquoi ils ne partagent pas les données sur le nombre réel de vulnérabilités de sécurité trouvées, combien étaient vraies, et combien étaient des faux positifs
Je comprends qu’ils veuillent traiter cela avant publication, mais quand on voit sans cesse des affirmations avec si peu de données, je ne vois pas comment ils peuvent espérer que les gens ne restent pas sceptiques. Les professionnels de la sécurité sont littéralement payés pour être sceptiques
Je me demande s’ils ont comparé avec d’autres modèles. Une grande partie de ce texte donne l’impression qu’ils appliquent l’IA à la sécurité pour la première fois et découvrent avec étonnement les performances absurdes d’une machine de reconnaissance de motifs
Or, c’est justement une machine qui reconnaît des motifs, donc rien d’étonnant
La partie où il se braque est assez drôle. Quand je l’ai essayé moi-même, il a exigé avant d’aller plus loin une preuve que j’avais le droit d’accéder légalement à la base de code en question
La phrase « ce qui a changé avec Mythos Preview, c’est que le modèle est désormais capable de chaîner des bugs de faible gravité, qui seraient traditionnellement restés invisibles dans le backlog, en un exploit plus grave » semble assez cohérente avec d’autres tests indépendants sur Mythos
Il s’est montré très bon sur les longues tâches agentiques, et c’est probablement ce pour quoi il a été entraîné. Pour cela, il faut être capable de repérer des connexions périphériques entre des sujets vaguement liés à l’intérieur de la fenêtre de contexte
[1] Je parle surtout de https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...