Les petits modèles d’IA de Cisco révèlent un compromis de sécurité plus vaste

Cisco Foundation AI a publié en juillet deux modèles de sécurité à poids ouverts, alors même que les données montrent que les systèmes les plus avancés manquent encore la plupart des emplacements de code vulnérables. L’annonce est apparue dans Google News comme une nouvelle collection mensuelle de modèles, de benchmarks et de recherches sur la sécurité. Mais l’essentiel n’est pas le rythme de publication de Cisco.

Cisco cherche à déterminer si de petits modèles spécialisés peuvent prendre en charge les tâches de sécurité répétitives de manière plus économique que les systèmes généralistes de pointe. Antares-350M et Antares-1B parcourent les dépôts logiciels à la recherche de fichiers associés à des catégories de vulnérabilités connues. Ils peuvent fonctionner localement, en maintenant le code source sensible dans l’environnement de l’organisation.

Cette conception remet en question l’idée selon laquelle chaque tâche d’IA difficile exige le plus grand modèle disponible. Microsoft et Google ont présenté leurs propres systèmes spécialisés en cybersécurité au cours de la même période. La compétition émergente oppose désormais des modèles ciblés, déployables localement, à des services plus volumineux dotés de capacités de raisonnement plus étendues.

Les résultats de benchmark de Cisco étayent l’approche spécialisée, mais en révèlent aussi les limites. Le meilleur système du benchmark principal de Cisco a obtenu un score File F1 inférieur à 0,23. Près de deux tâches de benchmark sur cinq ont mis en échec tous les modèles évalués.

Il s’agit donc d’un compromis, pas d’un tour d’honneur. Les petits modèles imposent moins de contraintes opérationnelles, offrent un contrôle plus strict des données et permettent une analyse reproductible des dépôts. Leurs résultats incomplets exigent toujours des analystes expérimentés, des outils de sécurité éprouvés et une validation rigoureuse.

Ce que Cisco a réellement publié en juillet

Cisco a publié un système ciblé de recherche dans le code, pas un chasseur de vulnérabilités autonome.

Le 21 juillet 2026, Cisco a présenté Antares-350M et Antares-1B comme de petits modèles de langage à poids ouverts. Leur rôle est la localisation de vulnérabilités, c’est-à-dire l’identification des fichiers susceptibles de contenir une faiblesse décrite.

Cette distinction est importante, car la localisation ne représente qu’une étape de la gestion des vulnérabilités. Antares ne confirme pas de manière autonome l’exploitabilité, ne détermine pas la gravité, ne produit pas de correctif complet et n’approuve pas le code pour la production.

À la place, chaque modèle reçoit un dépôt et une description Common Weakness Enumeration. Un CWE est une catégorie normalisée décrivant une faiblesse logicielle récurrente, comme une validation incorrecte des entrées.

Le modèle explore un dépôt en lecture seule à l’aide de commandes de terminal. Il recherche des motifs pertinents, lit les fichiers candidats, évalue les éléments recueillis et change de direction lorsqu’une piste de recherche semble peu productive.

Cisco décrit ce comportement dans sa publication Antares. Le système renvoie une liste classée des fichiers les plus probables ainsi qu’une trace des commandes utilisées pendant l’exploration.

Cette trace est importante pour les opérations de sécurité. Un analyste peut examiner la manière dont le modèle est parvenu à sa réponse plutôt que de recevoir un verdict de vulnérabilité non étayé.

Antares-350M cible les environnements informatiques contraints et prend en charge une fenêtre de contexte de 32 000 tokens. Antares-1B prend en charge 128 000 tokens et est conçu pour fonctionner sur un seul processeur graphique.

L’exécution locale est une autre caractéristique déterminante. Une entreprise peut examiner du code propriétaire sans transmettre son dépôt à un fournisseur de modèles hébergés. Cette option répond aux préoccupations de confidentialité, de résidence des données et de contrats qui bloquent souvent l’analyse de sécurité dans le cloud.

Cisco a également présenté VLoc Bench pour mesurer les modèles. Le benchmark comprend 500 tâches tirées de 290 dépôts, de six écosystèmes de packages et de 147 catégories CWE distinctes.

Chaque tâche comprend un instantané de dépôt contenant une vulnérabilité connue. Les étiquettes de référence proviennent des fichiers modifiés par le correctif de sécurité correspondant.

Le benchmark sépare la localisation de la vérification. Lors de la localisation, un modèle doit trouver les fichiers associés à la faiblesse. Lors de la vérification, il examine le dépôt corrigé et doit éviter de signaler à tort le problème réparé.

Cette structure est plus étroite qu’un test d’intrusion complet. Elle est aussi plus exigeante que la récupération d’un extrait de code à partir d’une invite préparée.

Le modèle doit naviguer dans des dépôts inconnus tout en opérant avec des informations limitées. Cela rend le benchmark pertinent pour le triage des avis de sécurité, où les défenseurs connaissent souvent la catégorie de faiblesse avant d’en localiser l’implémentation.

Cisco positionne Antares aux côtés de l’analyse statique, de l’analyse de composition logicielle, de la détection de secrets, des tests dynamiques et de l’examen humain. L’entreprise ne présente pas les modèles comme des remplaçants de ces contrôles.

Le changement immédiat est donc pratique mais limité. Les équipes de sécurité ont obtenu deux modèles téléchargeables pour réduire un vaste dépôt à un ensemble plus restreint de fichiers candidats.

Cette première réduction peut faire gagner de l’attention lors d’enquêtes répétitives. Elle ne peut pas établir que les fichiers sélectionnés sont vulnérables, ni prouver que les fichiers omis sont sûrs.

Pourquoi Google News est passé à côté de l’enjeu réel

Le titre de Google News présentait juillet comme un flux de lancements, alors que le véritable changement concerne ceux qui peuvent se permettre une revue de code continue.

Les équipes de sécurité des applications n’inspectent pas un dépôt une seule fois. Le code évolue, les dépendances changent, les avis arrivent et des comportements auparavant acceptables deviennent dangereux avec de nouvelles techniques d’attaque.

Un modèle de pointe hébergé peut aider à ces revues. Toutefois, l’analyse répétée de dépôts à grande échelle consomme des ressources d’inférence considérables et peut exiger l’envoi de code sensible hors de l’infrastructure de l’entreprise.

Les petits modèles locaux modifient cette équation opérationnelle. Ils peuvent effectuer une tâche ciblée de manière répétée sans rendre chaque analyse dépendante d’un service externe haut de gamme.

Le compromis exerce une pression sur plusieurs groupes à la fois. Les fournisseurs de modèles de pointe doivent démontrer qu’un raisonnement plus large apporte suffisamment de valeur supplémentaire pour justifier des exigences opérationnelles plus élevées.

Les fournisseurs de sécurité doivent décider si les modèles spécialisés ont leur place dans les scanners existants, les consoles de triage et les pipelines d’intégration continue. Les équipes de sécurité internes doivent déterminer si les classements de fichiers générés par les modèles réduisent réellement la charge de travail des analystes.

L’approche de Cisco met également sous pression les organisations qui ont traité la sécurité de l’IA comme une décision d’achat de chatbot. La localisation des vulnérabilités est un problème de flux de travail impliquant l’accès aux dépôts, la collecte de preuves, les autorisations et l’escalade humaine.

Un déploiement utile connecterait Antares à un instantané de dépôt contrôlé. Il enregistrerait la trace de recherche, renverrait les fichiers candidats et transmettrait ces candidats à un analyste.

L’analyste comparerait la sortie avec les données de dépendances, les résultats statiques, les tests et l’avis d’origine. Ce n’est qu’alors que l’organisation déciderait si une correction est nécessaire.

Cette répartition du travail importe car le travail sur les vulnérabilités a des conséquences asymétriques. Un faux positif consomme du temps d’analyste, tandis qu’un faux négatif laisse du code dangereux non découvert.

Les lancements de juillet suggèrent qu’aucun modèle unique n’a besoin de posséder l’ensemble du processus. Un modèle pourrait localiser du code suspect tandis qu’un autre évalue l’exploitabilité ou rédige une correction.

Google DeepMind a exprimé un point de vue similaire lorsqu’il a présenté un modèle cyber spécialisé dans le cadre de son programme CodeMender. Microsoft a également annoncé un modèle de cybersécurité entraîné en interne et des agents de sécurité associés.

Une comparaison sectorielle a décrit les trois entreprises comme poursuivant des systèmes spécifiques à certaines tâches. Leur motivation commune comprend les contraintes d’accès et le coût d’exécution des modèles de pointe à grande échelle.

Cette convergence donne aux travaux de Cisco une importance supérieure à celle d’un simple lancement de produit. Les modèles de sécurité spécialisés deviennent une couche distincte entre les scanners déterministes et les assistants d’IA généralistes.

Les outils statiques restent efficaces lorsque les mainteneurs peuvent définir des règles fiables. Les modèles de pointe restent utiles lorsqu’une tâche exige un raisonnement étendu, la génération de correctifs ou une interaction entre de nombreux systèmes.

Un petit modèle de sécurité se situe entre les deux. Il peut apprendre des schémas de recherche d’investigation tout en restant suffisamment compact pour un déploiement contrôlé et fréquent.

La question concurrentielle n’est pas de savoir si Antares peut surpasser tous les modèles plus grands. Elle est de savoir si un portefeuille de systèmes spécialisés peut fournir une précision suffisante dans les flux de travail défensifs courants.

Si ce modèle fonctionne, les acheteurs évalueront l’IA selon l’économie des tâches et l’adéquation opérationnelle. Le prestige des benchmarks généralistes pèsera moins que des réductions mesurables du temps de triage.

Les petits modèles de sécurité remettent en cause l’économie des systèmes de pointe

Antares avance qu’un comportement de recherche entraîné peut compter davantage que le nombre de paramètres pour une tâche de sécurité étroitement définie.

Les modèles de programmation généralistes apprennent le travail sur les vulnérabilités parallèlement à de nombreuses capacités sans rapport. Ils doivent prendre en charge l’écriture, l’explication, la planification, la génération de code et un raisonnement logiciel étendu.

Antares resserre l’objectif. Il apprend à rechercher, examiner les preuves, réviser une piste et identifier les fichiers associés à une description de faiblesse donnée.

Cet objectif d’entraînement plus étroit permet à Cisco d’allouer la capacité du modèle à la navigation dans les dépôts. L’approche ressemble à celle d’un enquêteur formé qui opère au moyen d’outils plutôt qu’à un chatbot se rappelant de la terminologie de sécurité.

Le modèle commence avec des éléments limités. Il peut rechercher des noms de fichiers et des motifs de code, inspecter les fichiers pertinents et utiliser de nouveaux indices pour guider les commandes ultérieures.

Un agent utile doit aussi abandonner les hypothèses faibles. Sans ce comportement, l’exploration d’un dépôt peut devenir une séquence coûteuse de recherches redondantes.

Le benchmark de Cisco teste ce processus sous une limite de commandes. La structure du dépôt devient donc une partie de la tâche, plutôt qu’une information de contexte cachée dans une invite.

Les résultats soutiennent la thèse de spécialisation de Cisco. Antares-1B a enregistré un score File F1 de 0,209 sur VLoc Bench, selon les données de benchmark publiées.

Le modèle Antares-3B non publié a atteint 0,223. La meilleure configuration GPT-5.5 a obtenu 0,229, ne laissant qu’un faible écart numérique dans l’évaluation de Cisco.

Le nombre de paramètres seul n’a pas déterminé le classement. Cisco indique que son modèle 3B entraîné pour cet usage a égalé ou dépassé des systèmes généralistes contenant plus de 100 milliards de paramètres.

Le point essentiel n’est pas qu’un modèle 3B est devenu globalement équivalent à un système de pointe. Ce n’est pas le cas. La comparaison couvre une tâche contrainte, un seul environnement de test et une seule méthode de notation.

Cisco a ensuite testé les mêmes poids sur la localisation CyberGym et une reconstruction publique de l’évaluation de sécurité de Cognition. Cette étape est importante, car les modèles semblent souvent les plus performants sur les benchmarks créés par leurs développeurs.

CyberGym comprend environ 1 500 vulnérabilités provenant de 188 projets open source. Son benchmark complet évalue la génération d’exploits, mais Cisco a isolé l’étape antérieure de localisation.

Antares-1B a atteint 67,2 % de rappel dans ce test de localisation. Le modèle 3B non publié a atteint 73,7 %, tandis que le principal modèle de pointe a atteint 89,1 %.

Ces chiffres montrent à la fois le transfert et un écart de capacités persistant. Les petits modèles ont conservé un comportement utile sur une tâche externe, mais n’ont pas atteint le meilleur résultat de pointe.

Les tests de benchmark externes de Cisco comprenaient également une reconstruction communautaire de l’évaluation de sécurité de Cognition. Seuls 34 des 50 cas de test d’origine étaient publiquement disponibles.

Cisco a estimé les résultats de cette comparaison en extrapolant à partir du sous-ensemble public. L’entreprise a explicitement précisé que ces chiffres étaient indicatifs, et non une véritable évaluation en face-à-face.

Cette réserve est essentielle. Différents agents peuvent utiliser des prompts, des limites de commandes, des infrastructures, des méthodes de gestion du contexte et des règles d’arrêt différents.

Même lorsque deux systèmes reçoivent le même dépôt, l’environnement d’exécution qui les entoure peut sensiblement affecter leurs résultats. Les benchmarks d’agents mesurent une combinaison modèle-système, et non une intelligence isolée.

L’argument économique reste néanmoins crédible. Un modèle local évite la consommation de tokens facturés à l’usage et permet des analyses répétées sans exporter le code source.

Cette approche rend la spécialisation attrayante pour le filtrage à haut volume. Un modèle plus vaste peut ensuite traiter le groupe plus restreint de dépôts ou de fichiers nécessitant une investigation approfondie.

L’architecture probable est donc hiérarchique. Des modèles spécialisés peu coûteux assurent une large localisation, tandis que des systèmes onéreux et des experts humains examinent les cas ambigus.

Cette approche reflète les pratiques établies des opérations de sécurité. Les organisations utilisent déjà des contrôles automatisés peu coûteux pour filtrer l’activité avant d’escalader les résultats incertains.

Antares n’élimine pas les modèles de pointe du processus. Il modifie les situations dans lesquelles les équipes pourraient leur réserver l’intervention.

La victoire au benchmark s’accompagne d’un avertissement

Les preuves les plus solides de Cisco montrent aussi pourquoi Antares ne peut pas devenir une barrière de sécurité sans une validation locale substantielle.

La comparaison phare entre Antares-3B et GPT-5.5 paraît impressionnante. Les scores absolus racontent une histoire moins rassurante.

Le système le plus performant sur VLoc Bench n’a atteint que 0.229 en File F1. Le File F1 combine précision et rappel lorsqu’il compare les fichiers prédits avec ceux modifiés par un correctif connu.

Un score faible peut refléter des fichiers pertinents manqués, des suggestions non pertinentes, ou les deux. Chacun de ces échecs crée du travail ou un risque pour l’équipe de sécurité qui reçoit le résultat.

Les résultats publiés du benchmark montrent que 190 tâches sur 500 sont restées non résolues par tous les modèles évalués. Cela représente 38 pour cent de l’ensemble.

Les performances ont également chuté d’un facteur treize entre les plus petits dépôts et les plus grands. Cisco a conclu que la complexité structurelle prédisait davantage la difficulté que la catégorie de vulnérabilité.

Cette conclusion crée le renversement central du récit. La spécialisation aide les petits modèles à rivaliser avec des modèles bien plus grands, mais elle ne rend pas fiable la détection de vulnérabilités à l’échelle d’un dépôt.

La même limite apparaît dans la frontière du produit. Antares identifie des fichiers candidats, mais les analystes doivent toujours déterminer si la faiblesse existe et si elle est exploitable.

Un dépôt peut contenir plusieurs implémentations d’un même motif. Le code généré, les wrappers, les tests, les dépendances intégrées et les couches de compatibilité peuvent perturber la recherche.

Un correctif de sécurité fournit aussi une forme imparfaite de vérité terrain. Les mainteneurs modifient parfois des fichiers de support qui ne sont pas directement vulnérables, ou omettent des emplacements connexes lors de la réparation initiale.

Les benchmarks peuvent donc récompenser la concordance avec un correctif historique sans mesurer pleinement la compréhension de la sécurité. Ils restent utiles, mais leurs scores ne doivent pas être considérés comme des taux de détection universels.

Les tests externes de Cisco réduisent les préoccupations liées à un surapprentissage complet du benchmark. Ils ne suppriment pas la nécessité d’une réplication indépendante sur des dépôts d’entreprise.

Une organisation qui adopte Antares devrait commencer par des cas rétrospectifs. Les équipes peuvent fournir des vulnérabilités déjà corrigées et mesurer si le modèle identifie les fichiers connus.

Elles devraient également consigner les suggestions non pertinentes, les fichiers manqués, l’utilisation des commandes, le temps d’exécution et le temps de revue des analystes. Différentes bases de code produiront différents schémas d’erreurs.

La fenêtre de contexte du modèle ne garantit pas une compréhension complète du dépôt. Antares navigue à l’aide de commandes de terminal ; sa réussite dépend donc de sa capacité à sélectionner les bonnes recherches et les bons éléments de preuve.

Les grands monodépôts posent des difficultés particulières. La description d’une faiblesse peut s’appliquer à plusieurs services, clients générés, bibliothèques partagées et langages d’implémentation.

Le benchmark confirme ce problème lié à la taille des dépôts. Il suggère également qu’une simple augmentation du nombre de paramètres ne supprimera pas tous les obstacles structurels.

Les responsables de la sécurité devraient résister à la tentation de convertir la confiance du modèle en autorité décisionnelle. Antares ne devrait pas bloquer seul une mise en production, clôturer un ticket de vulnérabilité ou certifier un correctif.

Une implémentation prudente traiterait sa sortie comme un avis. Les fichiers les mieux classés recevraient plus tôt l’attention humaine, tandis que les contrôles conventionnels continueraient d’examiner l’ensemble de la base de code.

Des reportages indépendants sont parvenus à une conclusion similaire. Une évaluation de déploiement a noté que les modèles ne confirment ni les vulnérabilités, ni leur gravité, ni ne génèrent de correctifs.

Le rapport a également souligné la nécessité d’isoler l’environnement d’analyse. L’exécution locale conserve le code sur site, mais ne sécurise pas automatiquement le système environnant.

Un modèle disposant d’un accès au terminal interagit toujours avec des dépôts sensibles et des dépendances d’inférence. Les administrateurs ont besoin d’un accès au moindre privilège, de restrictions réseau, de journaux et d’artefacts de modèle vérifiés.

Les poids ouverts offrent des options d’inspection et de déploiement. Ils ne garantissent pas l’absence de falsification, d’intégrations dangereuses ou d’autorisations inappropriées.

Des poids ouverts ne signifient pas une confiance sans restriction

Cisco cherche à équilibrer un accès défensif plus large avec la possibilité que les modèles de sécurité puissent aider des attaquants.

L’entreprise qualifie Antares d’open weight, car les utilisateurs qualifiés peuvent obtenir les paramètres entraînés. Le comportement du modèle peut alors s’exécuter sur une infrastructure située hors des services hébergés par Cisco.

Toutefois, le téléchargement des modèles publiés exige des coordonnées et une approbation. Cisco a indiqué qu’il vérifie les accès afin de réduire le risque que des criminels obtiennent ces outils.

Cette distribution contrôlée complique le débat habituel entre ouvert et fermé. Antares offre un déploiement local et des poids inspectables sans permettre un accès anonyme et immédiat.

Cisco aurait consulté des agences gouvernementales américaines au sujet de la sécurité des modèles et des décisions de publication. Cela reflète la nature à double usage de la recherche sur les vulnérabilités.

Un modèle de localisation peut aider les défenseurs à trouver du code exposé. Cette même capacité peut aider un attaquant à restreindre sa recherche d’une faiblesse connue dans un dépôt disponible.

Les modèles de Cisco s’arrêtent avant la génération d’exploits, mais cette limite n’élimine pas les usages abusifs. Trouver le fichier pertinent constitue souvent une première étape importante dans le développement d’un exploit.

Le reportage sur la publication présente Antares comme faisant partie d’un mouvement plus large vers des outils de sécurité ouverts. Capital One a publié un agent distinct axé sur les vulnérabilités durant la même période.

La recherche ouverte en sécurité présente des avantages de longue date. Des règles, benchmarks et cas de test partagés permettent aux défenseurs de reproduire les résultats et de comparer les systèmes.

Elle accroît aussi la vigilance. Les chercheurs peuvent identifier des erreurs d’évaluation, des hypothèses cachées et des configurations par défaut dangereuses qu’un service fermé pourrait dissimuler.

Le risque augmente lorsque les outils gagnent en autonomie. Un modèle qui ne fait que classer des fichiers a moins d’autorité qu’un agent autorisé à exécuter du code, atteindre des réseaux ou modifier des dépôts.

Les équipes de déploiement devraient préserver cette autorité limitée. L’accès en lecture seule aux dépôts, l’exécution en environnement isolé, les commandes bornées et les traces vérifiables devraient rester des contrôles par défaut.

Les recherches plus larges de Cisco renforcent cette prudence. Son évaluation de 15 modèles de pointe propriétaires a constaté de grandes différences entre les attaques à un seul tour et les attaques adaptatives à plusieurs tours.

Les taux de réussite des attaques à plusieurs tours allaient de 7.89 pour cent à 88.30 pour cent. Les taux à un seul tour, pour la même cohorte, allaient de 2.19 pour cent à 64.91 pour cent.

La recherche sur les interactions à plusieurs tours soutient que les tests de sécurité à un seul prompt ne représentent pas les attaquants qui s’adaptent après chaque refus. Cette leçon s’applique également aux agents défensifs.

Un agent de recherche dans les dépôts fonctionne à travers une séquence d’observations et d’actions. Tester une sortie isolée ne peut révéler toutes les trajectoires dangereuses ou défaillances d’autorisations.

Cela rend la stratégie de benchmark d’Antares plus intéressante que la seule publication du modèle. Cisco construit des modèles, des évaluations spécifiques aux tâches et des spécifications pour des systèmes d’agents contrôlés.

Ces éléments forment un argument sur la manière dont la sécurité par IA devrait être achetée. Les acheteurs ont besoin de preuves concernant des flux de travail définis, des conditions d’attaque, des autorisations et des taux d’échec.

Une fiche de modèle ou un classement généraliste ne peut répondre à ces questions opérationnelles. Un titre favorable dans Google News ne le peut pas davantage.

Les équipes de sécurité ont besoin d’artefacts d’évaluation qui ressemblent à leurs dépôts et à leurs contraintes. Elles ont aussi besoin de traces indiquant quand le modèle a changé de direction et pourquoi il a sélectionné un fichier.

Ces éléments peuvent soutenir les audits et les revues d’incidents. Ils peuvent également révéler quand un modèle s’est fondé sur des noms superficiels plutôt que sur des relations significatives dans le code.

Les poids ouverts facilitent ce type de tests locaux. L’accès contrôlé limite toutefois la participation de la communauté et peut ralentir la réplication indépendante.

Cisco devra démontrer que son processus de validation accorde aux chercheurs légitimes un accès concret. Faute de quoi, ses affirmations d’ouverture resteront plus limitées que ne le suggère l’étiquette.

Ce que les équipes de sécurité doivent surveiller ensuite

Les trois prochains signaux détermineront si les modèles de sécurité spécialisés deviennent une infrastructure ou restent d’impressionnantes démonstrations de recherche.

Le premier signal est la réplication indépendante des benchmarks. Les chercheurs devraient exécuter Antares sur des dépôts, langages et classes de vulnérabilités que Cisco n’a pas sélectionnés.

Les résultats CyberGym hors distribution fournissent déjà des éléments utiles. Des tests plus larges devraient mesurer la précision, les faux négatifs, le temps d’exécution et l’effort des analystes avec des environnements d’exécution cohérents.

Un résultat favorable renforcerait la thèse de spécialisation de Cisco. D’importantes baisses de performance suggéreraient que les modèles ont appris des schémas de recherche propres au benchmark plutôt que des compétences d’investigation transférables.

Le deuxième signal est l’intégration en production. Antares devient opérationnellement significatif lorsque les plateformes de sécurité peuvent placer ses fichiers classés dans les flux de travail existants d’investigation et de remédiation.

Les équipes devraient surveiller les intégrations avec les systèmes d’intégration continue, les scanners statiques, les plateformes de gestion des avis de sécurité et les résultats SARIF standardisés. SARIF est un format courant d’échange de résultats d’analyse statique.

L’intégration ne constitue pas à elle seule une adoption. Cisco ou ses partenaires doivent montrer que les analystes clôturent les investigations plus rapidement sans accepter davantage de vulnérabilités manquées.

Les preuves les plus utiles compareraient le temps des analystes avant et après le déploiement. Les études de cas devraient également divulguer la taille des dépôts, la couverture linguistique et le processus de revue humaine.

Les organisations menant des pilotes devraient conserver leurs propres notes d’évaluation, le contexte du code, les avis de sécurité et les décisions des réviseurs. Une base de connaissances consultable peut aider les équipes à conserver ces éléments au fil de tests répétés.

Le troisième signal est la réponse de la concurrence. Microsoft, Google, OpenAI, les fournisseurs de sécurité et les chercheurs open source explorent tous des modèles ou agents cyber spécialisés.

Observez s’ils publient des benchmarks au niveau des tâches avec des environnements d’exécution reproductibles. Observez également si leurs systèmes séparent la localisation, la vérification, l’exploitation et la remédiation.

Une séparation claire soutiendrait la vision modulaire des agents de sécurité défendue par Cisco. Des systèmes intégrés présentant des résultats de bout en bout systématiquement plus solides affaibliraient l’argument en faveur d’un modèle de localisation dédié.

Antares-3B constitue un autre test concret au sein de ce signal. Cisco a inclus ses résultats, mais n’avait pas publié ses poids lors de la publication des évaluations de juillet.

Une fois disponibles, des chercheurs indépendants pourront vérifier si ses performances proches de la frontière sur VLoc Bench se transfèrent à différents dépôts. Ils pourront également comparer son comportement avec les variantes 350M et 1B publiées.

Les responsables des achats en sécurité ne devraient pas attendre un gagnant universel. Les éléments disponibles suggèrent déjà que le choix du modèle dépendra du périmètre de la tâche, des exigences de confidentialité, de la complexité du dépôt et de la capacité de revue.

Google News continuera de condenser ces publications en annonces de modèles et en classements de benchmarks. Les praticiens devraient poser une question plus exigeante : le système réduit-il le travail de sécurité vérifié sans masquer de nouveaux modes de défaillance ?

Menez un pilote à périmètre limité sur des cas historiques, conservez chaque trace de recherche et comparez les résultats à vos contrôles existants. Ces éléments permettront de déterminer si une IA spécialisée a sa place dans votre pipeline de sécurité.