L’IA agit désormais comme un accélérateur mais à double tranchant.
D’un côté, elle augmente sensiblement la surface d’attaque du code en facilitant l’introduction et la propagation de vulnérabilités à grande échelle. De l’autre, elle transforme radicalement les cycles de développement en fluidifiant la génération de code, les tests et les déploiements à une vitesse inédite.
Cette accélération change la donne. La sécurité logicielle ne peut plus fonctionner selon une logique de correction a posteriori, déconnectée du rythme réel de production mais s’intégrer directement dans les workflows de développement et devenir un mécanisme continu, capable d’accompagner le code tout au long du cycle de vie applicatif.
En 2026, la disruption est impossible à ignorer. L’IA s’est imposée au cœur des outils et des workflows de développement, accélérant considérablement la production de code… mais aussi l’exposition aux vulnérabilités.
Dans le même temps, les attaquants exploitent exactement les mêmes capacités pour détecter et industrialiser l’exploitation des failles à une vitesse inédite. En 2018, il s’écoulait en moyenne 840 jours entre la divulgation d’une vulnérabilité et son exploitation. En 2026, ce délai est tombé à 1,6 jour et les chercheurs projettent même une minute d’ici 2028 !
Le risque a aussi changé d’échelle. Des vulnérabilités autrefois jugées secondaires peuvent désormais être transformées quasi instantanément en chaînes d’attaque opérationnelles générées par IA.
Claude Mythos d’Anthropic illustre cette rupture de manière spectaculaire. Selon des tests indépendants, le modèle serait capable d’identifier des vulnérabilités connues et de générer des exploits fonctionnels en dix à quinze minutes, pour un coût inférieur à un dollar.
Son taux de réussite atteindrait même 72,4 % sur l’exploitation de failles connues, contre 14,4 % pour Opus 4.6 et 4,4 % pour Sonnet 4.6. Un modèle initialement conçu pour le raisonnement et la sécurité figure désormais parmi les outils offensifs les plus efficaces jamais évalués.
Sécurité adaptée à l’IA : la fin du CVSS comme unique arbitre
Une faille non corrigée n’est plus un simple élément de backlog : elle constitue désormais une surface d’attaque potentielle directement exploitable.
Historiquement, la gestion des vulnérabilités reposait sur une logique de priorisation relativement stable, distinguant les failles critiques des failles secondaires. Ce modèle fonctionnait dans un contexte où l’exploitation d’une vulnérabilité restait coûteuse, lente et dépendante de compétences avancées.
Cette équation est désormais fragilisée par les capacités des modèles d’IA générative, capables d’analyser du code, d’identifier des vecteurs d’attaque et d’accélérer fortement la recherche de scénarios d’exploitation. Dans ce cadre, le CVSS, fondé sur la complexité d’exploitation, les privilèges requis ou l’impact, ne suffit plus à refléter le risque réel.
Le point central devient l’exploitabilité en environnement de production, c’est-à-dire la reachability dans le code actif, le niveau d’exposition réel et la capacité d’automatisation de l’attaque. Une gestion des vulnérabilités reposant uniquement sur des équipes humaines est ici limitée et les organisations s’orientent progressivement vers des approches de remédiation agentique, capables de prioriser et de corriger automatiquement certaines failles.
Le pilotage de la sécurité bascule ainsi d’un modèle statique basé sur la sévérité vers un modèle dynamique centré sur l’exploitabilité opérationnelle, combinant scoring d’attaquabilité, automatisation des correctifs au niveau des pull requests et intégration continue de l’AppSec dans le cycle de développement.
Une sécurité « agile » en miroir
Dans un environnement de développement désormais alimenté par l’IA, la sécurité ne peut plus en effet intervenir uniquement en bout de chaîne. Elle doit s’intégrer nativement à chaque étape du cycle applicatif et évoluer au même rythme que les workflows de développement.
Le « shift left » devient ainsi une nécessité opérationnelle. Mais le périmètre à sécuriser dépasse désormais le seul code produit. IDE enrichis par l’IA, pull requests générées automatiquement, pipelines CI/CD pilotés par des agents ou composants IA tiers deviennent autant de nouvelles surfaces d’exposition.
Les serveurs MCP utilisés par les agents pour accéder à des outils externes, les agents autonomes capables d’ouvrir des PR ou de déclencher des déploiements avec peu de supervision humaine, ainsi que les dépendances fictives générées par certains modèles, créent des risques largement invisibles pour des scanners traditionnels conçus pour analyser uniquement le code source.
Dans ce contexte, un AI Bill of Materials (AI-BOM), capable de cartographier l’ensemble des composants IA présents dans les workflows de développement, devient aussi indispensable qu’un SBOM pour les dépendances logicielles classiques. Cette visibilité est essentielle pour assurer gouvernance, traçabilité et conformité avec des référentiels comme le cadre AI RMF du National Institute of Standards and Technology, l’European Union AI Act, l’ISO 42001 ou l’OWASP LLM Top 10.<
La sécurité applicative doit désormais être pilotée comme une capacité industrielle continue, centrée non plus sur le volume brut d’alertes, mais sur l’exploitabilité réelle des vulnérabilités.
Cela implique de réduire le bruit par une analyse contextualisée, de prioriser les risques selon leur capacité d’exploitation, d’automatiser les corrections au niveau des pull requests et d’assurer une supervision continue des pipelines de développement et de livraison. Car une IA ne peut pas s’auto-auditer efficacement sur le code qu’elle produit elle-même.
*Frédéric Malo est Solutions Engineer Professional Lead chez Checkmarx
The post IA contre IA : sécuriser le code dans un cycle de menaces auto-accéléré appeared first on Silicon.fr.
