ActualitésIA

Antares : les SLM open-weight détectent les fichiers CVE

Antares 350M/1B : des SLM open-weight localisent les fichiers CVE en local. Apache 2.0, VLoc Bench - tri des fichiers sans cloud.

Par Alec Chizhik 23 juillet 2026 7 min de lecture

Antares : les SLM open-weight détectent les fichiers CVE

Cisco Foundation AI présente avec Antares deux Security-SLMs open-weight qui résolvent une tâche étroite et coûteuse : Vulnerability Localization. À partir d’un Advisory et d’une Codebase, les Source-Files probables doivent en ressortir – localement, suffisamment compacts pour son propre GPU-Setup et mesurables face à un nouveau 500-Task-Benchmark.

L’essentiel en bref

Tâche spécifique plutôt que LLM polyvalent. Antares-350M et Antares-1B localisent les vulnérabilités connues dans le dépôt. Ils ne patchent pas et ne remplacent ni SAST ni SCA.
Poids ouverts, Apache 2.0, local. Poids disponibles sur Hugging Face (fdtn-ai/antares). Le code n’a pas besoin de quitter l’environnement local – un atout pour les pipelines réglementés et les équipes air-gapped.
Propre benchmark : VLoc Bench. 500 tâches agentiques. Antares-1B atteint un File F1 de 0,209 et surpasse, selon la Model Card, des modèles nettement plus grands ; 500 tâches traitées en environ 13 minutes sur une H100.

Lié :Hugging Face piraté : l’entrée s’est faite via un Dataset-Loader / Faille NGINX : Ingress et Gateway contraints au correctif

Pourquoi la localisation est la partie la plus coûteuse

L’avis de sécurité est disponible, la CVE est claire – et c’est alors que commence le travail le plus onéreux : dans un dépôt inconnu ou hérité, repérer les fichiers qui abritent la faille. Les analystes doivent naviguer entre conventions de nommage, chemins d’appels et listes de candidats. L’analyse statique apporte une aide, mais génère souvent du bruit. Les modèles de codage généralistes savent lire du code, sans être optimisés ni pour le triage de sécurité ni pour la navigation en terminal au sein de grands arbres.

C’est précisément cet entre-deux qu’Antares entend combler. Cisco présente ces modèles comme des Security-SLMs capables d’itérer à la manière d’un investigateur humain : partir de la description de la vulnérabilité, explorer des fichiers, changer de stratégie, revenir en arrière et resserrer progressivement le champ. Le résultat est une liste classée des fichiers sources les plus probables, accompagnée de la trace d’exploration. Ce matériau reste destiné au réviseur et sous contrôle expert.

Pour les équipes Cloud et Plateforme, la différence est nette entre « nous avons un LLM dans le chat » et « nous disposons d’une porte dans le pipeline qui réduit la première heure, la plus coûteuse, du triage ». La localisation intervient avant le correctif. Gagner du temps et des tokens à ce stade permet de mieux absorber les vagues d’avis et le code généré par les agents.

Antares-350M et 1B : petits, spécialisés, mesurables

Deux modèles open-weight sont disponibles en direct : Antares-350M et Antares-1B, sous licence Apache 2.0 sur Hugging Face. Antares-3B est annoncé. La base repose sur IBM Granite 4.0 avec un pipeline d’entraînement en deux étapes. La fiche modèle d’Antares-1B indique un File F1 de 0,209 sur le Vulnerability Localization Benchmark et liste des comparaisons avec des systèmes nettement plus grands, dont GLM-5.2, Gemini 3 Pro, GPT-5 Mini et Qwen3.5-122B. Le balayage complet des 500 tâches s’exécute dans l’environnement d’évaluation en environ 13 minutes sur une H100 avec 16 workers parallèles.

Les rapports sectoriels examinent de près le volet coûts : Help Net Security et SecurityWeek citent des ordres de grandeur jusqu’à 172× moins onéreux que GPT-5.5 et environ 15× moins chers que GLM-5.2 sur le même benchmark. Cisco lui-même souligne dans son blog « fraction of the cost » et montre dans la Figure 2 des coûts estimés et des temps d’exécution nettement inférieurs. Pour la mise en perspective éditoriale, la tendance est claire : un SLM spécialisé surpasse les modèles frontier polyvalents sur cette tâche précise. Les multiplicateurs absolus doivent toujours être vérifiés contre la Model Card et le papier avant d’être intégrés au budget.

Amin Karbasi, VP et Chief AI Scientist chez Cisco Foundation AI, présente la sortie ainsi : la communauté de la sécurité a besoin de briques accessibles pour la défense au niveau des dépôts. C’est précisément pour cela que les modèles sont open-weight et suffisamment compacts pour une inférence locale.

// Métrique

500 Tasks

VLoc Bench : localisation agentique de vulnérabilités sur des bases de code inconnues et des patterns CWE – l’étalon sur lequel Antares est mesuré.

// Source : Cisco Foundation AI / VLoc Bench, juillet 2026

VLoc Bench : pourquoi SWE-Bench ne suffit pas ici

Cisco n’a pas construit ce benchmark par simple envie marketing. Les benchmarks de codage généraux comme SWE-Bench mesurent la résolution d’issues et la recherche de correctifs – pas si un agent, à partir d’une description CWE ou d’un advisory, identifie les fichiers vulnérables. CodeScout s’en rapproche (agents en terminal, recherche de code), mais cible des tâches d’ingénierie logicielle, pas la localisation de failles de sécurité.

VLoc Bench exige les deux simultanément : une navigation efficace dans des dépôts inconnus et la reconnaissance de motifs de vulnérabilités selon des catégories CWE concrètes. 500 tâches, de manière agentique. C’est l’étalon avec lequel Cisco positionne Antares face à des modèles plus grands, fermés ou à poids ouverts – et le levier permettant aux équipes de comparer leurs propres harnesses.

Concrètement, cela signifie pour l’AppSec et le Platform Engineering : si vous déployez Antares ou un concurrent, vous mesurez la qualité de la localisation et le coût par advisory – pas l’Elo du chat. Sans cette mesure, « l’IA dans les outils de sécurité » reste une slide de démonstration.

Exécution locale : la résidence des données comme fonctionnalité

L’angle cloud n’est pas une simple formule ici. De nombreuses équipes sécurité ne sont pas autorisées à transmettre du code propriétaire à des API d’inférence externes. Les modèles compacts à poids ouverts, exécutés on-prem ou dans leur propre VPC, modifient la donne en matière d’approbation : le triage des advisories et les vérifications CI restent derrière la trust boundary de l’entreprise.

Cisco positionne Antares explicitement pour les universités, le secteur public et les petites équipes qui ne peuvent absorber les budgets Frontier-Token. Des voix académiques relayées sur le blog (NUS, Stanford) rappellent le même constat : la sécurité ne doit pas être un produit de luxe et les petits modèles sont assez rapides pour filtrer les sorties d’agents avant le merge.

Les limites restent strictes : Antares ne remplace ni le scan des dépendances, ni la détection des secrets, le DAST, les vérifications de conteneurs ou la modélisation des menaces. Il réduit simplement le périmètre de la coûteuse recherche de fichiers. L’humain et le reste de la chaîne d’outils restent dans la boucle, comme le souligne Cisco lui-même.

Ce que les équipes Cloud et Platform doivent vérifier maintenant

Quiconque prend Antares au sérieux intègre un slot mesurable dans la pipeline :

Use-Case découper : Uniquement la localisation (Advisory → File-Rank). Aucun mélange d’attentes avec l’auto-remédiation.
Lieu de déploiement : On-prem / GPU privé versus Managed Endpoint. La conformité et la résidence du code priment sur les débats de précision.
Conception du CI-Gate : Pour les advisories de haute sévérité, classer les fichiers dans une file de revue, conserver la trace et imposer un Human-in-the-Loop.
Benchmark interne : 20-50 CVE historiques propres comme Goldset. Mesurer le F1 par fichier ainsi que le temps et le coût par rapport au statu quo (manuel + SAST).
Chaîne d’approvisionnement des poids : Vérifier les modèles HF (signatures, hachages, miroir interne). L’incident du HF-Dataset-Loader le montre : les entrées de pipeline constituent une surface d’attaque.

Parallèlement, il est utile d’examiner l’offre plus large de Cisco : Foundry Security Spec (harnais et garde-fous pour la sécurité agentique), CodeGuard (règles de codage sécurisé pour les agents de code) et le benchmark ouvert VLoc. Antares n’est que le composant de localisation, pas l’ensemble de la serrure.

Questions fréquentes

Qu’est-ce qu’Antares exactement ?

Une famille de Security-SLMs de Cisco Foundation AI dédiée à la localisation de vulnérabilités : à partir d’une description de faille et d’une base de code, le modèle renvoie les fichiers source classés par pertinence ainsi qu’une trace d’exploration. Versions open-weight actuelles : 350M et 1B (Apache 2.0), 3B annoncé.

Antares remplace-t-il les outils SAST ou SCA ?

Non. Cisco le positionne comme un accélérateur pour le coûteux triage des fichiers. Les analyses de dépendances, le scan de secrets, le DAST et la revue par des experts restent indispensables.

Pourquoi open-weight et de petite taille ?

L’inférence locale permet de conserver le code dans son propre environnement, réduit les coûts et rend l’outil accessible aux équipes sans budget frontier. La spécialisation sur la localisation permet d’obtenir des performances élevées malgré un nombre réduit de paramètres.

Que mesure VLoc Bench ?

500 tâches agentiques : les modèles naviguent dans des dépôts inconnus et doivent identifier les fichiers correspondant aux patterns CWE ou de vulnérabilités. C’est plus ciblé et spécifique à la sécurité que SWE-Bench.

Où trouver les modèles ?

Sur Hugging Face, dans la collection fdtn-ai/antares (notamment antares-350m, antares-1b). Le benchmark et l’article sont accessibles via Cisco Foundation AI.