L’intelligence artificielle offre aux chercheurs en sécurité de nouvelles façons d’examiner le code, de retracer les comportements inhabituels et d’identifier les failles que les outils conventionnels pourraient ignorer. La pression est particulièrement visible autour des vulnérabilités Zero-day. Une récente analyse Minimus examine comment la composition des conteneurs, les enregistrements de dépendances et la vitesse de reconstruction affectent la réponse après la découverte d’une faille inconnue. Une analyse plus rapide n’est utile que lorsque les organisations peuvent également déterminer où s’exécutent les logiciels vulnérables.
En mai 2026, le Google Threat Intelligence Group a signalé le premier cas dans lequel il pensait qu’un acteur malveillant avait utilisé l’IA pour aider à développer un exploit zero-day. L’exploit est apparu dans un script Python et a contourné l’authentification à deux facteurs sur un outil d’administration système open source largement utilisé alors que des informations d’identification valides étaient déjà disponibles.
Les chercheurs ont déclaré qu’ils étaient convaincus qu’un modèle d’IA contribuerait à la fois à la découverte et à la militarisation. Leur évaluation s’est appuyée sur les commentaires pédagogiques inhabituellement détaillés du script, un score de vulnérabilité fabriqué et un style de codage hautement structuré associé au résultat généré. Google n’a pas affirmé que l’opération au sens large était autonome ni attribué le code à un modèle particulier.
C’est le défaut lui-même qui rend l’affaire significative. Il s’agissait d’une hypothèse de confiance codée en dur plutôt que d’un crash, d’une erreur de mémoire ou d’une entrée non sécurisée. Les fuzzers et les outils d’analyse statique sont bien adaptés à la recherche de nombreux problèmes de mise en œuvre conventionnels. Un modèle de langage peut également examiner la façon dont les autorisations, les fonctions et le comportement attendu interagissent dans une base de code. Cela crée une autre voie pour trouver des contradictions logiques qui ne laissent aucune trace technique évidente.
Les données plus larges de Google suggèrent qu’il ne s’agissait pas d’une préoccupation isolée. Selon l’analyse 2025 de Google Threat Intelligence Group, les chercheurs ont recensé 90 failles Zero Day exploitées dans la nature en 2025, contre 78 en 2024. Les logiciels et appareils d’entreprise représentaient 43 cas, soit 48 % du total. Les deux chiffres étaient des enregistrements dans l’ensemble de données de Google.
Les conteneurs complexes rendent l’exposition plus difficile à retracer
Une fois qu’une faille devient publique, les équipes de sécurité doivent d’abord déterminer où elle se produit. Cela peut être difficile dans un environnement de conteneur. Une image peut contenir des packages de système d’exploitation, des bibliothèques d’applications et des dépendances héritées de son image de base, ainsi que des shells ou des utilitaires ayant peu de lien avec l’objectif visible de la charge de travail.
Un composant vulnérable peut donc se trouver plusieurs couches en dessous de l’application elle-même. Il peut apparaître sur de nombreuses images même si l’organisation ne l’a jamais ajouté directement.
Log4Shell a exposé ce problème à grande échelle en 2021. La bibliothèque Log4j concernée avait été intégrée à une large gamme de produits et services. Pour de nombreuses organisations, l’obtention du correctif n’était qu’un début. Ils devaient encore identifier chaque serveur, application et conteneur contenant une version vulnérable avant de pouvoir procéder à la correction.
Les nomenclatures des logiciels fournissent un enregistrement plus clair de ce que contient chaque image. Des images plus petites peuvent également réduire la recherche en excluant les packages dont la charge de travail n’a pas besoin. Minimus examine le problème via la réduction des packages, la visibilité des dépendances et la reconstruction des images après la divulgation d’un composant affecté.
L’avantage est plus simple que d’empêcher complètement le zéro jour. Une image minimale peut encore contenir un défaut inconnu. Cela donne aux équipes moins de packages à étudier, moins de points d’exposition possibles et moins de logiciels à remplacer ou à retester une fois le problème connu.
Les correctifs générés par l’IA nécessitent toujours un contexte logiciel
L’IA est également utilisée pour raccourcir le délai entre la divulgation et le développement des correctifs. Les modèles peuvent inspecter le code source, comparer les rapports de vulnérabilité avec les enregistrements de packages et proposer des modifications pour les versions concernées. Rien de tout cela n’est particulièrement utile lorsque les enregistrements de packages sont obsolètes ou que personne ne sait quelles images contiennent le composant vulnérable.
Une couverture antérieure d’un agent d’IA conçu pour automatiser les correctifs de vulnérabilités a détaillé comment CodeMender de Google DeepMind a apporté 72 correctifs de sécurité à des projets open source établis au cours de ses six premiers mois. Le système combine le raisonnement de modèle avec l’analyse statique, les tests d’exécution et le fuzzing pour produire et évaluer les correctifs proposés.
Ces correctifs n’étaient pas acceptés automatiquement. Des chercheurs humains ont examiné chaque changement avant de le soumettre, vérifiant les régressions et confirmant qu’il s’agissait de la cause sous-jacente plutôt que du seul symptôme visible.
Même un changement de code approuvé ne termine pas le travail. Les équipes doivent identifier les images concernées, les reconstruire avec la dépendance corrigée et tester le résultat avant le déploiement. Dans un environnement mal documenté, la localisation de chaque instance peut prendre plus de temps que la production du correctif lui-même.
Des inventaires précis donnent aux outils automatisés quelque chose de concret avec lequel travailler. Ils relient une faille récemment révélée à la version du package, à l’image et à la charge de travail qui nécessitent réellement une attention particulière.
Trouver la faille n’est peut-être plus l’étape la plus lente
L’IA accélère l’analyse du code tant pour les attaquants que pour les défenseurs, mais de nombreux retards surviennent encore après l’identification d’une vulnérabilité. Une équipe peut passer des heures à ouvrir des images et à vérifier manuellement les listes de packages. Un autre peut effectuer une recherche dans un inventaire actuel et voir presque immédiatement quelles charges de travail contiennent la version concernée.
Cette différence n’a pas grand-chose à voir avec la sophistication de l’outil de découverte. Cela découle de décisions prises précédemment concernant les inventaires de logiciels, la composition des images et la manière dont les conteneurs sont construits et remplacés. À mesure que la recherche sur les vulnérabilités progresse plus rapidement, l’avantage pratique revient aux organisations qui peuvent établir l’exposition et déployer une réparation testée sans essayer au préalable de reconstruire ce que contiennent leurs systèmes.
