Antares : Cisco publie deux modèles à poids ouverts dédiés à la détection de failles

Cisco Foundation AI lance Antares : des modèles ouverts de 350M et 1B qui localisent les vulnérabilités connues dans du code réel

Cisco Foundation AI a publié Antares, une famille de petits modèles de langage spécialisés (SLM) dédiés à une tâche unique en sécurité informatique : la localisation de vulnérabilités. À partir d'une description de faille et d'un dépôt de code, le modèle doit identifier les fichiers concernés. Deux versions sont disponibles en poids ouverts sur Hugging Face sous licence Apache 2.0, Antares-350M et Antares-1B, tandis qu'une troisième, Antares-3B, reste non publiée. Les trois modèles sont des transformeurs décodeurs initialisés à partir des checkpoints IBM Granite 4.0, partageant attention par groupes de requêtes, couches SwiGLU, normalisation RMSNorm et encodage RoPE. Cisco a également mis en ligne, sous la même licence, VLoc Bench, un benchmark agentique de 500 tâches issues de 290 dépôts réels couvrant six écosystèmes (npm, pip, Maven, Go, Rust, Composer) et 147 catégories CWE, dont 78% associées à un identifiant CVE officiel. Le résultat marquant n'est pas un record absolu mais un écart de performance à taille égale : Antares-1B atteint un score File F1 de 0,209, dépassant GLM-5.2, un modèle ouvert de 753 milliards de paramètres, plafonné à 0,186. Antares-3B grimpe à 0,223, juste sous GPT-5.5 en mode de raisonnement maximal à 0,229. Antares-1B affiche par ailleurs le meilleur rappel de tous les systèmes testés, à 0,224. Ce résultat illustre qu'un entraînement ciblé sur une tâche précise peut surpasser la simple augmentation du nombre de paramètres. Pour les équipes de sécurité, cela signifie qu'un modèle léger, peu coûteux à faire tourner, peut accélérer la première étape de triage lors d'une alerte de vulnérabilité, celle où un développeur doit fouiller un code source volumineux et mal connu pour localiser un fichier fautif. Les outils d'analyse statique classiques testés dans le même cadre restent nettement en retrait, avec 0,086 pour Semgrep, 0,023 pour CodeQL et seulement 0,020 pour Horusec, preuve que les scanners à base de règles peinent à s'adapter au contexte réel d'un dépôt. Cisco précise toutefois qu'Antares ne remplace aucun autre maillon de la chaîne de sécurité applicative : l'analyse des dépendances, la détection de secrets, les tests dynamiques ou la revue par des experts restent indispensables. Concrètement, Antares fonctionne comme un agent limité à 15 appels de terminal en lecture seule dans un bac à sable Docker sans accès réseau, ne recevant qu'une description de catégorie CWE, sans texte d'avis ni indice de fichier. Il conclut sa tâche en soumettant une liste classée de fichiers suspects ou en signalant l'absence de vulnérabilité. Le benchmark VLoc évalue aussi cette seconde capacité, en testant sur du code déjà corrigé si le modèle déclenche une fausse alerte. Cette approche s'inscrit dans une tendance plus large où l'industrie cherche à automatiser les tâches de sécurité répétitives et coûteuses en temps d'ingénieur, à mesure que le volume de vulnérabilités signalées dans les bases publiques continue de croître.

Microsoft officialise son utilisation intensive de l’IA pour la découverte des failles

Microsoft a publié un long billet de blog détaillant pour la première fois de façon approfondie l'usage intensif de l'intelligence artificielle générative dans la découverte des failles de sécurité de ses produits, Windows en tête. L'entreprise avait déjà évoqué brièvement le sujet en mai 2026, indiquant que ses équipes d'ingénieurs recouraient de plus en plus aux grands modèles de langage pour traquer les vulnérabilités. Le mois suivant, en juin, le traditionnel « Patch Tuesday », ce deuxième mardi du mois où Microsoft diffuse ses correctifs de sécurité, a marqué un record historique avec près de 200 failles colmatées en une seule fournée. Ce chiffre confirme que l'annonce de mai n'était pas un effet d'annonce isolé mais bien le signe d'un changement de méthode durable dans la manière dont l'éditeur traque et corrige les failles de ses logiciels. Cette bascule vers l'IA générative dans le cycle de sécurité a des conséquences concrètes pour les entreprises et les particuliers qui utilisent Windows et les autres produits Microsoft. L'éditeur explique avoir fait évoluer ses systèmes d'ingénierie et de validation afin de réduire le délai entre la découverte d'une vulnérabilité et la mise à disposition d'un correctif pour les clients, en concentrant l'effort sur les zones jugées les plus à risque. Les modèles sont désormais intégrés plus tôt dans le cycle de développement, ce qui permet de repérer des problèmes que les méthodes traditionnelles auraient mis plus de temps à révéler. Microsoft prévient toutefois d'ores et déjà ses clients qu'ils doivent s'attendre à un volume plus élevé de mises à jour de sécurité à chaque publication mensuelle, un changement d'échelle qui touchera directement les équipes informatiques chargées de déployer ces correctifs. Reste que l'automatisation de la recherche de failles par l'IA soulève une question de fond : l'expertise humaine garde-t-elle la main ? Microsoft insiste sur le fait que l'évaluation des vulnérabilités, l'arbitrage sur les risques et la vérification de la qualité des correctifs continuent de reposer sur des ingénieurs humains, l'IA n'intervenant qu'en amont pour accélérer la détection. L'éditeur tient aussi à couper court à une interprétation inverse de ces chiffres impressionnants : selon lui, ce déluge de correctifs ne traduit pas une dégradation de la sécurité de Windows, mais au contraire une meilleure capacité des équipes de défense à identifier et traiter les problèmes existants. Cette évolution s'inscrit dans un mouvement plus large de l'industrie, où l'IA devient un outil à double tranchant, aussi précieux pour les défenseurs qui cherchent à corriger les failles que pour des attaquants qui pourraient s'en servir pour les exploiter avant qu'elles ne soient corrigées.

💬 Microsoft assume publiquement l'IA dans sa chasse aux failles, et 200 correctifs en un seul Patch Tuesday, ça change la donne pour toutes les DSI qui déploient Windows. Bonne nouvelle sur le papier, ça veut dire des trous détectés plus vite, mais ça veut aussi dire plus de charge de déploiement chaque mois pour les équipes. Retiens ça : quand l'IA accélère la détection côté défenseurs, elle raccourcit aussi la fenêtre de tir pour les attaquants qui scannent les mêmes correctifs.

Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle

En 2025, la base de données nationale des vulnérabilités américaine (NVD) a enregistré plus de 48 000 nouvelles failles de sécurité référencées (CVE), un volume rendu possible en grande partie par la prolifération des outils automatisés de détection. Face à cette explosion, Amazon Web Services a développé RuleForge, un système d'intelligence artificielle agentique conçu pour générer automatiquement des règles de détection à partir d'exemples de code d'exploitation de vulnérabilités. Déployé en production chez AWS, RuleForge affiche une productivité supérieure de 336 % à la création manuelle, tout en conservant le niveau de précision exigé pour des systèmes de sécurité industriels. Les règles produites sont au format JSON et alimentent directement MadPot, le système mondial de "honeypot" d'Amazon qui capture le comportement des attaquants, ainsi que Sonaris, le moteur interne de détection d'exploits suspects. Avant RuleForge, transformer une CVE en règle de détection opérationnelle était un processus entièrement manuel : un analyste téléchargeait le code de preuve de concept, étudiait le mécanisme d'attaque, rédigeait la logique de détection, la validait par itérations successives contre les journaux de trafic, puis soumettait le tout à une revue par un second ingénieur avant déploiement. Ce cycle, rigoureux mais lent, obligeait les équipes à prioriser strictement les vulnérabilités traitées, laissant potentiellement des failles critiques sans couverture. RuleForge comprime ce délai de façon drastique : le système ingère automatiquement le code d'exploitation public, attribue un score de priorité via une analyse de contenu croisée avec des sources de threat intelligence, puis génère en parallèle plusieurs règles candidates via un agent tournant sur AWS Fargate avec Amazon Bedrock. Chaque candidate est évaluée non pas par le modèle qui l'a produite, mais par un agent "juge" distinct, évitant ainsi l'auto-validation biaisée. Les humains restent dans la boucle pour l'approbation finale avant mise en production. Cette architecture reflète une tendance profonde dans la sécurité offensive et défensive : l'automatisation par IA ne remplace pas les experts, elle leur permet de travailler à une échelle autrement inaccessible. AWS anticipe une croissance continue du nombre de CVE à haute sévérité publiées, portée par les mêmes outils d'IA qui accélèrent la découverte de failles côté attaquants. RuleForge représente la réponse symétrique côté défense, en industrialisant la réactivité. L'approche modulaire, avec des agents spécialisés pour la génération, l'évaluation et le raffinement, plutôt qu'un seul modèle monolithique, s'inscrit dans la lignée des architectures multi-agents qui émergent comme standard pour les tâches complexes nécessitant fiabilité et auditabilité. D'autres grands acteurs du cloud font face aux mêmes défis, et la publication par Amazon des détails de RuleForge suggère une volonté de positionner cette approche comme référence sectorielle.

Empoisonnement de modèles ML : fonctionnement et détection

L'empoisonnement des données constitue l'une des menaces les plus insidieuses pour les systèmes d'intelligence artificielle modernes. Dans une analyse publiée par Igor Maljkovic, quatre techniques principales sont décrites : le retournement de labels (label flipping), qui consiste à corrompre les annotations d'entraînement pour induire des erreurs systématiques ; l'injection de backdoors, qui implante des comportements cachés déclenchables à la demande ; le clean-label poisoning, qui manipule les données sans modifier les étiquettes pour échapper aux vérifications ; et la manipulation de gradients, qui perturbe directement le processus d'optimisation du modèle. Ces attaques représentent un risque concret pour toute organisation qui déploie des modèles en production. Un modèle empoisonné peut classer incorrectement des contenus, ignorer des anomalies critiques dans des systèmes de détection de fraude ou de sécurité, ou exécuter des comportements malveillants sur commande. La difficulté majeure réside dans la détection : les données corrompues peuvent paraître parfaitement légitimes lors des audits visuels ou statistiques habituels, rendant la compromission quasi invisible jusqu'au déploiement. L'article s'inscrit dans un contexte où les pipelines d'entraînement ML s'appuient de plus en plus sur des données externes, des dépôts publics et des contributions tierces, multipliant les surfaces d'attaque. Maljkovic présente des outils de défense pratiques ainsi que des pratiques opérationnelles pour sécuriser ces pipelines, notamment la surveillance des distributions de données, la validation croisée des sources et l'isolation des lots d'entraînement suspects. La sécurisation du cycle de vie des modèles devient ainsi un enjeu structurel pour les équipes MLOps.