La couverture médiatique récente autour du dernier modèle d'Anthropic, Mythos, s'est presque exclusivement concentrée sur ce qu'il pourrait apporter aux pirates informatiques. Un brouillon de billet de blog qui a fuité, consulté par Fortune, décrit ce modèle comme capable d’« exploiter les vulnérabilités d’une manière qui dépasse de loin les efforts des défenseurs ». À tel point qu’Anthropic affirme vouloir faire preuve de prudence et bien comprendre les « risques à court terme dans le domaine de la cybersécurité » que présente ce modèle avant d’aller plus loin.
La suite était prévisible : des gros titres sur «le cauchemar cybernétique qui se profile avec l'IA », des fournisseurs de solutions de cybersécurité mettant en garde contre la démocratisation des cyberattaques, et un consensus général sur le fait que la balance a basculé.
C'est inquiétant, n'est-ce pas ?
C'est vrai, à première vue. Mais la balance n'a pas basculé. Ce scénario catastrophe repose sur l'hypothèse selon laquelle les capacités des modèles se traduisent directement par un avantage pour les pirates. Or, nos données indiquent le contraire.
Le postulat qui sous-tend le récit du Mythe
En effet, nous savons que les modèles d'IA permettront d'accélérer les processus d'attaque. Mais l'efficacité de cette approche dépend fortement d'une connaissance approfondie du contexte du système, ce dont les attaquants sont généralement dépourvus.
Les capacités en matière de cybersécurité attribuées à des modèles tels que Mythos recoupent largement ce que les systèmes d'IA accomplissent déjà dans des environnements de test de sécurité contrôlés : détection des vulnérabilités, analyse du code, attaques en plusieurs étapes. Notre propre expérience, acquise au cours de 1 000 tests d'intrusion réels menés par l'IA, nous permet de mieux comprendre comment les performances évoluent selon les conditions.
La tendance est constante. Les tests « white box », pour lesquels le code source de l'application cible est disponible, ont permis de détecter sept fois plus de problèmes critiques et de gravité élevée, et se sont révélés environ deux fois plus efficaces que les tests « grey box », qui ne disposent que d'un accès limité au code source. Cela suggère que l'efficacité de l'IA dépend fortement du contexte, et non pas uniquement de ses capacités intrinsèques.
Dans la pratique, ce contexte résulte de la combinaison de l'analyse statique et de l'analyse dynamique. L'examen isolé du code ou du comportement ne donne qu'une vision partielle. Lorsque ces deux approches sont disponibles, il est possible de relier le code écrit à son comportement lors de l'exécution, ce qui modifie la profondeur des résultats. Cela a également un impact sur les coûts : il faut moins de tentatives (et donc moins de jetons) pour mettre en évidence les problèmes significatifs.
Les réflexions actuelles autour de Mythos partent du principe que les attaquants tireront davantage profit des modèles de pointe. Mais dans la pratique, cela ne tient pas compte du fait que ce sont les attaquants qui disposent d'un contexte limité. Ils déduisent les détails du système depuis l'extérieur, tandis que les défenseurs ont déjà accès au fonctionnement réel de ces systèmes.
C'est le contexte qui constitue la contrainte, et non la capacité
En effet, on accorde beaucoup d'importance à la manière dont les développeurs de modèles décrivent eux-mêmes les capacités de ces derniers ; on a observé le même phénomène lorsque Anthropic a affirmé que Claude Opus 4.6 avait détecté plus de 500 vulnérabilités de gravité élevée dans des bibliothèques open source. Ces affirmations montrent ce dont les modèles sont capables dans des conditions idéales. Mais on parle peu de la manière dont les performances évoluent lorsqu'ils fonctionnent sans visibilité complète sur le système.
La variable principale ici est le contexte. L'accès au code source et à la logique interne de l'application détermine ce que les agents de test peuvent évaluer de manière pertinente. La capacité à elle seule ne se traduit pas en résultats. Sans un contexte de code statique et dynamique suffisant, même les modèles les plus avancés ne parviennent pas à surpasser les modèles open source légers, en raison d'une compréhension incomplète du système qu'ils analysent.
Prenons l'exemple de la récente compromission d'Axios, l'un des paquets les plus utilisés du registre NPM. L'attaquant n'a pas modifié le code source. Il a piraté le compte d'un responsable de maintenance, ajouté une nouvelle dépendance et publié une mise à jour. L'attaque a fonctionné car il n'existait aucun CVE connu auquel la comparer, aucun modèle de code malveillant à signaler, ni aucune signature qu'un scanner aurait pu détecter. L'attaque a abouti car aucun des outils de la chaîne ne disposait du contexte nécessaire pour identifier ce qui avait réellement changé.
Une organisation disposant d’une visibilité approfondie sur son arbre de dépendances – c’est-à-dire sachant non seulement quels paquets elle utilise, mais aussi ce que font ces paquets, comment ils se comportent et à quoi ressemble une mise à jour légitime – aurait eu les bases nécessaires pour remettre en question ce changement. Sans cela, aucune rapidité ni aucune capacité ne peut y faire quoi que ce soit. C’est pourquoi le discours actuel selon lequel « l’IA favorise les attaquants » passe à côté de l’essentiel. C’est là que l’approche des tests pilotés par l’IA commence à se démarquer. Grâce à une vision complète du code et du comportement en exécution, ces outils privilégiés identifient des problèmes que les tests superficiels ne détectent tout simplement pas.
Pour autant, cela ne signifie pas pour autant que l’avantage dont bénéficie le défenseur en matière de visibilité sur le code et l’exécution soit permanent. L’IA réduira bien sûr elle aussi le coût d’acquisition du contexte ; mais le discours actuel laisse entendre qu’un renversement de la balance s’est produit du jour au lendemain. Développer une véritable compréhension du système est un travail lent et complexe, et bien que les modèles d’IA soient de plus en plus capables de déduire certains aspects du contexte, ils ne pourront jamais égaler la clarté qui découle de l’accès au code source réel, aux API et aux identifiants/jetons d’application, ni de la capacité à analyser rapidement la logique métier interne à travers les composants d’application, les microservices et les intégrations dont dispose une organisation en interne.
Avec le recul, tout cela peut sembler évident, surtout compte tenu de la tendance à diffuser des prévisions catastrophistes en matière de sécurité. Mais il faut parfois examiner de plus près ce qui nous est présenté pour en évaluer réellement l’impact. Le discours dominant a toujours été que les nouveaux modèles d'IA allaient radicalement faire pencher la balance, ce qui est vrai dans une certaine mesure ; l'IA apportera rapidité, ampleur et capacités aux attaquants, et ceux qui défendent les applications, les systèmes et les infrastructures en subiront les conséquences néfastes.
Mais la nuance réside dans le fait que l'efficacité dépend largement du contexte, et que ce contexte est réparti de manière inégale. Heureusement pour nous, la balance penche en faveur des défenseurs. Ainsi, alors que les attaquants peuvent être les premiers à tirer parti des nouveaux modèles d'IA de pointe tels que Mythos et Capybara, les défenseurs disposent déjà d'un avantage grâce à leur connaissance approfondie et structurelle du fonctionnement réel de leur code. L'IA rend le contexte de la sécurité des applications plus précieux que jamais. La question est de savoir si les défenseurs sauront exploiter l'avantage dont ils disposent déjà.
