- Après qu’Anthropic Claude Mythos a automatiquement détecté des vulnérabilités zero-day à grande échelle, des petits modèles open source ont eux aussi réussi à détecter les mêmes vulnérabilités
- Des modèles de 3.6B à 5.1B de paramètres ont reproduit des bugs de FreeBSD et OpenBSD, certains proposant même des voies d’exploitation créatives différentes de celles de Mythos
- Les expériences montrent que la taille du modèle et les performances évoluent de manière non linéaire, et que sur certaines tâches, de petits modèles sont plus précis que de grands modèles
- Les capacités de sécurité de l’IA ne progressent pas de façon fluide mais de manière “irrégulière” ; le véritable avantage concurrentiel réside non pas dans le modèle, mais dans la conception du système et la pipeline de validation
- En conséquence, le fossé défensif en sécurité ne se situe pas dans le modèle, mais dans le système, et une orchestration intégrant l’expertise métier est au cœur de la sécurité par l’IA
Le fossé défensif, c’est le système, pas le modèle
- Le 7 avril 2026, Anthropic a dévoilé Claude Mythos Preview et Project Glasswing, et mis en place un consortium utilisant le modèle Mythos pour détecter et corriger automatiquement des failles de sécurité dans des logiciels majeurs
- Promesse de 100 millions de dollars de crédits d’usage et de 4 millions de dollars de dons à des organisations de sécurité open source
- Mythos a découvert des milliers de vulnérabilités zero-day et a détecté de façon autonome des failles telles qu’un bug OpenBSD vieux de 27 ans, un bug FFmpeg vieux de 16 ans et une vulnérabilité d’exécution de code à distance sur FreeBSD, tout en générant les exploits associés
- AISLE a reproduit les mêmes vulnérabilités avec des modèles compacts, peu coûteux et à poids ouverts
- 8 modèles sur 8 ont détecté l’exploit FreeBSD
- Un modèle de 3.6B de paramètres (0,11 $ par token) a lui aussi réussi la détection
- Un modèle 5.1B a reconstitué la chaîne centrale du bug OpenBSD
- Sur certaines tâches, de petits modèles ouverts ont surpassé de grands modèles
- En résultat, les capacités de sécurité de l’IA sont non linéaires et irrégulières (jagged)
- Aucun modèle n’est supérieur sur toutes les tâches
- Le cœur de la compétitivité en sécurité n’est pas le modèle mais le système, avec au centre une orchestration intégrant l’expertise métier
Où en est aujourd’hui la sécurité par l’IA
- Depuis mi-2025, AISLE applique en conditions réelles des systèmes de détection et de correction de vulnérabilités basés sur l’IA
- 15 CVE trouvées dans OpenSSL, 5 dans curl, et plus de 180 CVE validées par des tiers au total
- Le CTO d’OpenSSL a salué « la qualité des rapports et l’excellence de la collaboration »
- Divers modèles ont été utilisés, mais les modèles Anthropic ne sont pas systématiquement les meilleurs
- Le meilleur modèle varie selon la tâche, d’où l’adoption d’une approche agnostique vis-à-vis des modèles
Décomposer la pipeline de sécurité par l’IA
- En pratique, la sécurité par l’IA repose sur une pipeline en plusieurs étapes, et non sur un modèle unique
- Scan à grande échelle, détection de vulnérabilités, validation et classification, génération de correctifs, construction d’exploits : chaque étape présente des propriétés de montée en charge différentes
- Là où Anthropic maximise la première composante (l’intelligence du modèle), AISLE accorde une importance égale à d’autres facteurs comme le coût par token, la vitesse et l’expertise sécurité
Conclusion : le fossé défensif est dans le système
- Les éléments mentionnés dans le billet technique de Mythos — exécution en conteneur, scan de fichiers, validation ASan, évaluation des priorités — ressemblent à l’architecture du système d’AISLE
- La valeur centrale ne réside pas dans le modèle mais dans le ciblage, la validation et la construction de la confiance
- Déployer en parallèle un grand nombre de petits modèles pour explorer largement l’ensemble du code permet de concilier efficacité économique et efficacité de détection
- Mythos a validé la catégorie, mais le passage à l’échelle opérationnel et la fiabilité restent encore à établir
Résultats expérimentaux : des capacités de sécurité irrégulières
- Des expériences ont été menées sur les vulnérabilités emblématiques de l’annonce Mythos avec des modèles petits et peu coûteux
-
Bug NFS de FreeBSD, bug SACK d’OpenBSD, test de faux positifs OWASP
- Au final, la taille, la génération et le prix des modèles présentent une relation non linéaire avec les performances
- Tous les modèles ont réussi sur FreeBSD, seuls certains sur OpenBSD, et sur OWASP, les petits modèles étaient plus précis que les grands
- Détection FreeBSD : les 8 modèles ont détecté le débordement de tampon
- Le modèle 3.6B a lui aussi réalisé les calculs correctement et évalué la possibilité d’une RCE
- DeepSeek R1 a produit des calculs cohérents avec la structure réelle de la pile
- Côté logique d’exploit également, tous les modèles ont proposé une stratégie de chaîne ROP
- Certains modèles ont suggéré des solutions créatives différentes de Mythos (par ex. une élévation de privilèges depuis l’espace utilisateur plutôt qu’en mode noyau)
- Bug SACK d’OpenBSD : un modèle 5.1B a reconstitué toute la chaîne et proposé le bon correctif
- Qwen3 32B était parfait sur FreeBSD, mais a ici conclu à tort que c’était « sûr »
- Le classement des performances par modèle s’inverse complètement selon la tâche
-
-
Test de faux positifs OWASP : sur un simple code Java, de petits modèles sont plus précis que de grands modèles
- GPT-OSS-20b, DeepSeek R1 et OpenAI o3 ont correctement jugé que « c’est sûr en l’état, mais potentiellement vulnérable »
- De nombreux modèles Anthropic et de la famille GPT-4.x ont détecté à tort une injection SQL
Test de reconnaissance des correctifs (mise à jour du 9 avril 2026)
- Comparaison de la détection du bug et de la reconnaissance du correctif sur la version patchée du code FreeBSD
- Tous les modèles ont détecté le bug non corrigé, mais de nombreux faux positifs sont apparus après correctif
- Seul GPT-OSS-120b était exact dans les deux sens
- La plupart des modèles ont affirmé à tort l’existence d’une vulnérabilité à cause d’une mauvaise interprétation du signe de
oa_length
- Cela montre une forte sensibilité (capacité de détection) mais une faible spécificité (précision),
ce qui souligne le caractère indispensable de systèmes de validation et de triage externes au modèle
La limite de la construction d’exploits
- Les cas mis en avant par Mythos — évasion de sandbox navigateur en plusieurs étapes, chaîne ROP noyau — sont des exemples extrêmement sophistiqués
- Les modèles ouverts peuvent expliquer de façon logique la faisabilité d’un exploit, les techniques et les stratégies de contournement, mais
ils restent encore limités sur les mécanismes de livraison créatifs dans des environnements contraints - Toutefois, dans les workflows défensifs, la fiabilité de la détection et du correctif importe davantage qu’un exploit complet
Perspective macro
- L’annonce de Mythos démontre le réalisme et l’importance industrielle de la sécurité par l’IA
- Les financements et l’attention accordés à la sécurité open source augmentent
- En revanche, affirmer que « cette capacité n’existe que dans un modèle fermé spécifique » est exagéré
- En pratique, les phases de détection et d’analyse sont déjà largement accessibles
- Le vrai goulet d’étranglement réside dans l’expertise sécurité, la conception système et la construction de la confiance
-
Ce qu’il faut aujourd’hui, ce n’est pas un modèle mais la construction d’un système
- Scaffold, pipeline, cadre de collaboration, intégration dans les workflows de développement
- Les modèles sont déjà suffisamment prêts
Limites et points d’attention
- Portée limitée des tests : les fonctions vulnérables et des indices ont été directement fournis aux modèles ; il ne s’agit pas d’une exploration entièrement autonome
- Pas d’accès aux outils : pas d’exécution de code, pas de boucle, pas d’usage d’environnement sandbox
- Prise en compte des mises à jour des modèles : certains modèles Anthropic récents ont été améliorés depuis
- Clarification de la portée des affirmations : il ne s’agit pas de nier les capacités de Mythos,
mais de souligner que l’exclusivité de ses capacités de détection a été exagérée
Résumé de l’annexe
-
Citations sur la détection FreeBSD
- Kimi K2 : «
oa_lengthest copié sans validation, ce qui peut entraîner un débordement » - Gemma 4 : « dépassement possible d’un tampon de pile de 128 octets »
- Kimi K2 : «
-
Tableau comparatif des performances par tâche
- Tous les modèles réussissent la détection FreeBSD, seuls certains celle d’OpenBSD, et sur OWASP les petits modèles dominent
-
Test sur le code patché
- La plupart des modèles produisent un faux positif à cause d’une erreur de signe sur
oa_length - Seul GPT-OSS-120b est entièrement exact
- Conclusion :
- Le véritable avantage concurrentiel de la sécurité par l’IA ne réside ni dans la taille du modèle ni dans son caractère propriétaire,
- mais dans une conception systémique intégrant l’expertise métier et une structure opérationnelle fiable.
- Même de petits modèles sont déjà suffisamment puissants, et la construction de systèmes défensifs automatisés à grande échelle est d’ores et déjà possible.
- La plupart des modèles produisent un faux positif à cause d’une erreur de signe sur
1 commentaires
Réactions sur Hacker News
D’après l’article d’Anthropic sur Mythos Preview, ils auraient découvert la vulnérabilité la plus critique d’OpenBSD
Le coût total pour mille exécutions était inférieur à 20 000 dollars, et l’une de ces exécutions aurait trouvé le bug pour moins de 50 dollars
Mais il est souligné que ce chiffre n’a de sens qu’a posteriori, puisqu’on ne peut pas savoir à l’avance quelle exécution réussira réellement
En comparant Mythos à quelqu’un qui fouille tout un continent comme une ruée vers l’or, on estime qu’en répétant la même expérience sur l’ensemble de la base de code de FreeBSD, il y aurait bien trop de bruit
On se demande si Anthropic a publié le taux de faux positifs
Sur Xitter, on a vu des gens faire des essais avec d’autres modèles publics et ne reproduire qu’une partie de ce que Mythos avait trouvé
Mythos semble avoir apporté une amélioration progressive mais importante par rapport aux modèles précédents, tout en augmentant la complexité
Le marketing du type « trop puissant pour être rendu public » ressemble surtout à un habillage de la réalité suivante : « faire tourner ça sur toute une base de code coûte 20 000 dollars »
La présentation de Nicholas Carlini utilisait aussi Opus, et la sécurité est depuis longtemps un domaine sur lequel Anthropic se concentre
La vraie question est de savoir si de petits modèles peuvent eux aussi effectuer cette étape de validation, et à moindre coût
Elle a isolé les fonctions vulnérables pour les donner directement au modèle, ce qui revient à « lui indiquer directement la pièce où l’or est caché »
En pratique, la difficulté est surtout de trouver cette pièce à l’échelle de tout le continent
Mythos est traité comme un trophée, mais certains pensent qu’il vaudrait mieux donner cet argent à la fondation OpenBSD
Une étude affirmait que de petits modèles open source avaient détecté les 8 vulnérabilités sur 8 trouvées par Mythos dans FreeBSD
Mais comme le test portait sur le code concerné isolé du reste, cela semble différent d’un usage réel
La vraie valeur, c’est de pouvoir jeter toute la base de code dans le système et la scanner
Puisqu’elle donnait directement au modèle la fonction vulnérable et des indices, cela ne représente qu’une borne supérieure de l’exploration totalement autonome
Cela dit, un scaffolding bien conçu peut générer automatiquement ce contexte, donc l’essentiel est le système (la moat) plutôt que le modèle
Autrement dit, c’est surtout le framework (le harness) qui fait le gros du travail, et le modèle serait interchangeable
Il suffit ensuite de faire reverifier par un grand modèle uniquement les éléments signalés de façon récurrente comme vulnérables
Au final, ce qui compte, ce n’est pas le modèle mais le harness
Comme dans l’exemple de Heartbleed, si on ne montre que le code vulnérable, n’importe qui peut trouver le bug
Mais ce qui est réellement difficile, c’est d’identifier cette portion dans une base de code massive
Qu’Aisle ait publié un tel article surprend
La difficulté à conserver le contexte est l’une des causes profondes des bugs
En revanche, les machines peuvent continuer à passer du code au peigne fin sans jamais se lasser
Le dicton « avec assez d’yeux, tous les bugs sont superficiels » ne correspond pas à la réalité
On peut créer un outil qui parcourt toute la base de code et répète au LLM : « s’il y a une vulnérabilité dans ce code, trouve-la »
Autrement dit, c’est l’outil (le harness) qui rend le LLM intelligent
C’est un peu comme dire : « si on t’avait donné directement la factorisation, casser la PKI serait facile »
Beaucoup pensent que la méthodologie de cet article constitue une comparaison totalement erronée
Fournir directement la fonction vulnérable et des indices revient à poser une question totalement différente
En pratique, même en découpant le code en morceaux pour les donner à de petits modèles, on n’obtiendrait pas des résultats au niveau des grands modèles
J’ai trouvé beaucoup de bugs dans Redis avec un simple pipeline de scripts shell
Ça ne marchait pas avec des modèles faibles. Il suffit de tester soi-même pour voir la différence
Et même si un petit modèle en trouvait 80 %, il faudrait toujours un modèle plus puissant pour les 20 % restants
Il serait intéressant de donner à des modèles open source un ancien environnement Linux et de voir ce qu’ils trouvent
Les petits modèles filtraient bien les faux positifs et, avec un harness adapté, pouvaient obtenir des résultats proches de ceux des grands modèles
Comme ils sont rapides et peu coûteux, un utilisateur expérimenté peut les exploiter bien plus efficacement
On pense que ces combinaisons modèles légers + harness vont devenir dominantes
Beaucoup de commentaires disent que « puisque le code a été séparé, l’étude est invalide », mais Anthropic procédait aussi de cette manière en faisant tourner le modèle fichier par fichier
Le harness de Mythos attribuait un score d’importance à chaque fichier, puis créait une instance de Claude Code pour se concentrer sur ce fichier
Donc, le fait de séparer le code n’invalide pas en soi les résultats
La vidéo de présentation de Nicholas Carlini montre la même technique
Faire relire intensivement un seul fichier à la fois par un LLM semble très efficace
La « révolution » de Mythos était en réalité cette simple automatisation du prompting fichier par fichier
C’est probablement pour cette raison que le coût a pu grimper jusqu’à 20 000 dollars
J’ai moi-même essayé la même méthode avec Opus 4.6 et GPT 5.4, et ils examinaient le code bien plus minutieusement
En d’autres termes, quand on concentre une session sur un seul fichier, le modèle l’analyse beaucoup plus en profondeur
Dire que « de petits modèles ont reconstruit la même analyse » est difficile à croire, car ce n’est pas quantifié
La validation des vulnérabilités peut être mesurée clairement avec des PoC, donc il faudrait ce type de preuves
De plus, le fait d’avoir « fourni à l’avance le code pertinent » ne constitue pas une comparaison équitable
Sans publication du taux de faux positifs, l’analyse n’a aucun sens
Si l’on affirme qu’il y a un bug sur chaque ligne, on obtient 100 % de détection, mais cela ne sert à rien
Comme Anthropic et OpenAI ne publient pas non plus ce genre de chiffres, il est difficile de leur faire confiance
En revanche, ils ne sont pas allés jusqu’au niveau de validation par exploit atteint par Mythos
Les résultats de Deepseek R1 semblaient assez convaincants, sans qu’on sache clairement s’ils fonctionnaient réellement
Le point essentiel est le fait d’avoir isolé le code pertinent
Les zero-days complexes naissent des interactions entre plusieurs fichiers, donc cette approche a des limites
Mythos évaluait l’ensemble de la base de code, tandis que cette étude testait uniquement le code vulnérable isolé
C’est la différence entre « un chien qui trouve une balle dans une jungle » et « un chien à qui l’on indique uniquement la zone où se trouve la balle »
Au final, ce qui compte, ce n’est pas le modèle mais le harness (l’ensemble d’outils)