L’entreprise spécialisée dans l’intelligence artificielle Anthropic affirme que son dernier grand modèle de langage, Claude Opus 4.6, a identifié plus de 500 vulnérabilités critiques jusqu’alors inconnues dans des bibliothèques open source largement utilisées.
Il « lit et raisonne sur le code comme le ferait un chercheur humain : il examine les correctifs passés pour trouver des bogues similaires qui n’ont pas été corrigés, repère les schémas qui causent généralement des problèmes ou comprend suffisamment bien une portion de logique pour savoir exactement quelle entrée la ferait planter », a déclaré Anthropic dans son article.
Analyser le code open source avec l’IA
Les logiciels open source sous-tendent les applications modernes : les vulnérabilités présentes dans des bibliothèques largement utilisées peuvent donc toucher de nombreux produits en aval.
Anthropic a indiqué que les projets concernés — Ghostscript, OpenSC et CGIF — sont largement utilisés dans les systèmes d’entreprise, les outils pour développeurs et les environnements d’exploitation, ce qui accroît la portée de toute faille sous-jacente.
Selon Anthropic, Claude Opus 4.6 a démontré une capacité inhabituelle à découvrir des vulnérabilités graves sans s’appuyer sur des invites personnalisées ni sur des outils de sécurité conçus pour une tâche précise.
Le modèle a plutôt examiné le code source et l’historique des commits pour repérer des schémas de programmation risqués, des contrôles de limites manquants et de subtiles erreurs logiques susceptibles d’entraîner une corruption de mémoire.
Dans un cas, le modèle a découvert une faille provoquant un plantage dans Ghostscript en mettant en corrélation des problèmes déjà corrigés avec des chemins logiques similaires qui n’avaient pas été traités.
Dans un autre cas, il a signalé un dépassement de tampon dans OpenSC en analysant des routines de manipulation de chaînes non sûres.
Anthropic a cité un dépassement de tampon sur le tas dans CGIF comme exemple illustrant les capacités du modèle.
Pour identifier la faille avec succès, il fallait comprendre conceptuellement l’algorithme de compression LZW et son interaction avec le format de fichier GIF.
L’entreprise a souligné que même une couverture complète des lignes et des branches pouvait ne pas détecter ces failles, ce qui illustre les limites du fuzzing lorsque les exploits dépendent d’une logique précise plutôt que d’entrées aléatoires.
La Frontier Red Team d’Anthropic a validé chaque découverte dans un environnement contrôlé et virtualisé afin d’écarter les faux positifs et les hallucinations.
Le modèle a également servi à établir des priorités parmi les problèmes les plus critiques, en se concentrant sur les bogues de corruption de mémoire qui pourraient plausiblement permettre des attaques par déni de service ou, dans certaines conditions, l’exécution de code arbitraire.
Anthropic n’a signalé aucune preuve d’exploitation active liée à ces failles précises, mais a souligné que leur gravité justifiait une correction immédiate afin de réduire les risques en aval dans toute la chaîne logistique logicielle.
Renforcer la chaîne logistique logicielle
À mesure que les chaînes logistiques logicielles gagnent en complexité et que l’IA accélère l’exploitation, les organisations ont besoin de contrôles qui vont au-delà de l’application de correctifs aux vulnérabilités individuelles.
De nombreux problèmes proviennent de dépendances imbriquées, de pratiques non sûres en matière de mémoire ou de chemins logiques difficiles à détecter avec les tests traditionnels.
La gestion de ces risques repose sur une meilleure visibilité, une priorisation plus efficace en production et la capacité à réagir lorsqu’une exploitation survient.
- Adoptez des inventaires des composants logiciels (SBOM) pour conserver une visibilité continue sur les dépendances transitives et évaluer rapidement l’exposition lorsqu’une nouvelle faille est divulguée.
- Privilégiez des paramètres par défaut garantissant la sûreté mémoire, par exemple en préférant des langages à sûreté mémoire ou des options de renforcement du compilateur (ASLR, canaris de pile, sanitizers) pour les composants à haut risque.
- Mettez en place une priorisation tenant compte de l’exploitabilité, en combinant CVSS avec des facteurs contextuels comme l’accessibilité, l’exposition à l’exécution et le niveau de privilèges afin de cibler les efforts de correction.
- En continu, surveillez le comportement à l’exécution en utilisant la télémétrie des applications et la détection des anomalies pour repérer les tentatives d’exploitation qui échappent aux contrôles préventifs.
- Segmentez et isolez les composants à haut risque, en particulier les bibliothèques qui traitent des entrées non fiables (par exemple les analyseurs de fichiers et les codecs d’image), afin de limiter l’ampleur des dégâts si une faille est déclenchée.
- Effectuez des tests adverses et des exercices de red team sur les dépendances critiques, notamment des cas d’abus fondés sur la logique que le fuzzing traditionnel pourrait ne pas détecter.
- Testez les plans de réponse aux incidents pour les scénarios liés à la chaîne logistique, en veillant à ce que les équipes puissent rapidement isoler les composants vulnérables, restaurer une version antérieure des builds, renouveler les identifiants et déployer des correctifs d’urgence lorsqu’une dépendance est compromise.
Ensemble, ces mesures contribuent à limiter l’ampleur des dégâts tout en renforçant la résilience de la chaîne logistique logicielle.
Les découvertes d’Anthropic montrent comment l’analyse assistée par l’IA transforme à la fois la découverte et la gestion des risques liés à la chaîne logistique logicielle.
Des modèles comme Claude Opus 4.6 peuvent mettre au jour des catégories de vulnérabilités que les outils traditionnels peinent à détecter, notamment celles qui trouvent leur origine dans une logique complexe et la gestion de la mémoire.
Ces découvertes soulignent l’importance de sécuriser à la fois les vulnérabilités individuelles et la chaîne logistique logicielle plus large dans laquelle elles se propagent.