Arm a open-sourcé Metis le 30 mai, un framework de sécurité IA agentique qui utilise du raisonnement sémantique LLM-driven pour découvrir de manière autonome des vulnérabilités logicielles à travers les dépendances de composants. La licence est Apache 2.0 ; le code est sur GitHub. Benchmark principal, de l'évaluation interne d'Arm utilisant GPT-5.5-Cyber comme modèle de base : 98 pour cent de précision à identifier les vulnérabilités versus 6 pour cent pour les outils SAST traditionnels basés sur des patterns, avec jusqu'à dix fois plus de taux de détection de vrais positifs et environ 50 pour cent de moins de faux positifs. Metis marche avec n'importe quel LLM OpenAI-compatible, supporte C, C++, Python, Go, TypeScript, Rust et plus, et peut opérer aux côtés d'outils SAST existants pour valider leurs findings et élaguer les faux positifs. Au sein d'Arm, Metis roule déjà sur plus de 130 projets logiciels, avec des plans d'adoption Arm-wide d'ici fin 2026.

L'architecture est la substance du move. Le SAST traditionnel c'est du pattern-matching sur syntaxe et signatures de taint connues, ce qui est pourquoi il a le problème précision-rappel bien connu : jette de larges filets pour attraper de vrais bugs et tu te noies dans les faux positifs ; resserre les patterns et tu manques les classes de bugs qui nécessitent de comprendre ce que le code fait vraiment à travers les fichiers. Metis applique du raisonnement LLM-driven aux relations entre composants, qui est le niveau où vivent la plupart des vulnérabilités de niveau production (auth bypass via mismatch d'assumption cross-module, gadgets de deserialization à travers les frontières de dépendances, fenêtres time-of-check-time-of-use qui span de multiples call sites). Les explications en langage naturel que Metis génère pour les findings sont aussi la chose que SAST ne t'a jamais donnée : un rapport SAST c'est une liste de numéros de ligne et d'IDs de règles ; un rapport LLM-reasoned est une hypothèse sur comment un attaquant atteindrait l'état unsafe. Ça change le coût de triage par finding plus que les chiffres bruts de détection ne le suggèrent.

Deux fils d'écosystème. Premièrement, le gap benchmark est réel mais vendor-published. Le chiffre 98 versus 6 d'Arm vient de leur eval interne, et comme chaque claim "on bat le truc d'avant par 16x," il a besoin de reproduction indépendante sur des charges qui matchent les tiennes avant de parier ton infra. Le signal prometteur c'est qu'Arm déploie Metis à l'échelle interne déjà (130+ projets, adoption full-company planifiée), ce qui est un signal dogfood fort même si les benchmarks externes n'ont pas encore atterri. Deuxièmement, le mode "valide les findings SAST externes" est le path d'intégration que la plupart des équipes production vont vraiment vouloir en premier. Les outils SAST existants (CodeQL, Semgrep, Snyk Code) génèrent beaucoup de noise ; utiliser Metis comme verifier downstream pour élaguer les faux positifs est une adoption à plus faible risque que de remplacer SAST entièrement. Cette posture hybride est ce qui fait de Metis un complément aux pipelines existants plutôt qu'un rip-and-replace forcé.

Lundi matin, si tu ships du code qui passe par n'importe quel gate SAST : Metis vaut le test comme couche de réduction-de-faux-positifs au-dessus de ton outil existant, vu la licence Apache 2.0 et le backend LLM OpenAI-compatible. Si tu construis avec C, C++, Rust ou Go, le support de langage est là. Roule Metis contre tes 100 derniers findings SAST, compte combien il drop correctement comme faux positifs versus combien de vrais positifs il escalade correctement, et décide sur ce signal plutôt que sur le headline 98 pour cent. Si t'as pas de pipeline SAST existant, Metis est aussi une option green-field, quoique le path new-deployment soit le plus risqué vu le manque de reproduction benchmark tierce yet. Et si t'es un vendor d'outils de sécurité, le pattern agentic-LLM-on-top-of-existing-rules est le design move qui vaut l'étude.