Anthropic Mythos et la fin de l'insouciance en sécurité
Mike Codeur
![]()
Pourquoi cette annonce d'Anthropic change vraiment la lecture du sujet
On parle souvent d'IA pour générer du code plus vite, écrire des tests, faire du refactor ou accélérer une revue de PR.
Le document publié par Anthropic autour de Project Glasswing et de Claude Mythos Preview montre un changement plus profond : les modèles ne servent plus seulement à produire du code, ils commencent aussi à trouver et exploiter des vulnérabilités réelles dans du code critique.
Et là, on ne parle pas d'un petit benchmark marketing.
Anthropic documente des cas concrets :
- une faille OpenBSD vieille de 27 ans
- une faille FFmpeg vieille de 16 ans
- des chaînes d'exploitation dans le kernel Linux
- des résultats très au-dessus d'Opus 4.6 sur plusieurs tests orientés sécurité
La vidéo complète est ici : https://mkc.sh/anthropic-mythos?utm_source=blog
Ce que Claude Mythos a montré
Anthropic présente Mythos comme un modèle frontier non public, testé dans un cadre défensif avec des partenaires majeurs via Project Glasswing.
Le point important n'est pas seulement la puissance brute. C'est le fait que les résultats remontés sont vérifiables et qu'ils touchent du code que tout le monde pensait déjà largement exploré.
Quelques chiffres à retenir
| Signal | Ce que ça montre |
|---|---|
| CyberGym : 83.1% | Un saut net par rapport à Opus 4.6 |
| Firefox : 181 exploits fonctionnels | Une capacité d'exploitation autonome d'un autre niveau |
| OSS-Fuzz : plusieurs résultats niveau 5 | Des scénarios de contrôle beaucoup plus sérieux |
Pourquoi les cas OpenBSD et FFmpeg sont si importants
Ce sont les exemples les plus parlants pour les développeurs.
OpenBSD : 27 ans
OpenBSD a une réputation historique de rigueur en sécurité. Quand un modèle trouve une faille liée à une base de code aussi ancienne, ça envoie un signal très fort : certaines vulnérabilités peuvent rester invisibles pendant des décennies, même dans des projets maintenus sérieusement.
FFmpeg : 16 ans
FFmpeg est partout. Si une faille critique survit aussi longtemps dans une brique aussi utilisée, cela veut dire que les outils automatisés classiques et les revues humaines n'épuisent pas tout l'espace de recherche.
Linux kernel
Quand on commence à voir des chaînes d'exploitation dans Linux, le sujet sort du cadre théorique. On touche directement aux infrastructures, aux serveurs, aux appliances réseau et à tout l'écosystème qui repose sur du code legacy critique.
Ce que ça change pour les équipes dev
La vraie leçon, c'est que le coût de découverte des failles est en train de baisser.
Et quand ce coût baisse, plusieurs choses deviennent vraies en même temps :
- Le legacy devient plus risqué
- Les dépendances historiques deviennent plus sensibles
- Les zones de code mal documentées deviennent plus dangereuses
- La sécurité ne peut plus rester un sujet séparé du développement
Ce que je ferais concrètement
- cartographier les zones critiques du code
- revisiter les modules C/C++ ou les briques anciennes peu retouchées
- revoir les hypothèses de confiance sur les dépendances
- mieux documenter les parties sensibles
- utiliser l'IA aussi côté défense, pas seulement pour générer des fonctionnalités
Le vrai enjeu
L'IA ne rend pas le métier de développeur moins sérieux. Elle le rend probablement plus exigeant.
- Regarder la vidéo : https://mkc.sh/anthropic-mythos?utm_source=blog
- Rejoindre la newsletter The Agentic Dev : https://mkc.sh/the-agentic-dev?utm_source=blog