Anthropic a présenté en bêta le plugin Claude Security pour Claude Code. Claude Code est l’assistant de codage agentique en terminal d’Anthropic, et ce plugin l’étend au domaine de l’analyse de sécurité, traditionnellement occupé par des outils dédiés de test statique de sécurité applicative (SAST). Le plugin exécute une analyse de vulnérabilités multi-agent d’un dépôt directement dans une session Claude Code existante et convertit les résultats sélectionnés en fichiers de correctifs que l’utilisateur examine et applique manuellement. Lors du lancement, Anthropic a mis en avant la flexibilité de l’outil, en indiquant qu’il peut effectuer une analyse complète d’une base de code entière ou inspecter les changements depuis le terminal juste avant un commit.

Ce qu’ajoute le plugin

Le plugin introduit une seule commande, /claude-security, qui affiche un menu de trois tâches, selon la documentation officielle :

• Analyser la base de code — l’ensemble du dépôt ou un sous-ensemble délimité
• Analyser les changements — le diff d’une branche, le diff d’une pull request ou un commit individuel
• Suggérer des correctifs — convertir les résultats d’un rapport en fichiers .patch

L’installation nécessite deux commandes depuis la place de marché officielle d’Anthropic. Si la place de marché est introuvable, il faut d’abord exécuter /plugin marketplace add anthropics/claude-plugins-official. Le code source du plugin est disponible publiquement dans le dépôt claude-plugins-official, actuellement en version 0.10.0.

Structure du pipeline d’analyse

L’analyse est mise en œuvre sous forme de workflow dynamique — un script d’orchestration JavaScript qui répartit le travail entre des sous-agents. Le script définit six phases :

1. Inventory : partitionner le dépôt en composants. Chaque répertoire de premier niveau doit être soit analysé, soit explicitement ignoré avec une justification.
2. Threat model : un modélisateur par composant, produisant les points d’entrée, les puits, les frontières de confiance et les fichiers qu’un chercheur doit lire intégralement.
3. Research : un chercheur par cellule composant × catégorie.
4. Sweep : combler les lacunes dans les zones que la matrice n’a pas couvertes.
5. Panel : vérification contradictoire selon trois angles, avec un votant par angle.
6. Adversarial (uniquement au niveau d’effort maximal) : soumettre à nouveau au panel les cas limites conservés, puis effectuer un red teaming de chaque élément survivant.

La recherche s’effectue selon quatre catégories fixes : injection-and-input, auth-and-access, memory-and-unsafe, et crypto-and-secrets. L’angle memory-and-unsafe est omis pour les composants écrits entièrement dans des langages sûrs pour la mémoire, ce qui signifie qu’un composant exclusivement en Python ou en TypeScript reçoit trois angles au lieu de quatre.

L’échelle opérationnelle d’une exécution est régie par quatre niveaux d’effort distincts : low, medium, high et max. Selon le niveau sélectionné, des seuils spécifiques sont appliqués : le nombre maximal de composants est plafonné à 12 pour les niveaux low et medium, puis passe à 24 pour les niveaux high et max ; les cellules de la matrice se voient attribuer 1 chercheur aux niveaux inférieurs, puis 2 aux niveaux high et max ; et le nombre de passages de comblement des lacunes passe de 0 au niveau low, à 1 au niveau medium, puis à 2 aux niveaux high et max. Lorsqu’il s’agit d’un périmètre limité ou d’un petit diff, le processus se condense en une configuration à chercheur unique plutôt que de déployer toute la matrice. Cela garantit que l’évaluation reste strictement proportionnée à la cible tout en conservant le même standard de vérification.

Le système emploie des agents différenciés par niveau de modèle : l’orchestrateur fonctionne sur Opus, tandis que le cartographe du dépôt et l’explorateur de code en lecture seule fonctionnent sur Sonnet. Le modèle de la session est hérité par les chercheurs et les vérificateurs, et les agents d’analyse sont limités exclusivement à des outils en lecture seule.

Comment un résultat obtient sa place dans le rapport

Les faux positifs constituent depuis longtemps un défi persistant dans la détection automatisée des vulnérabilités, obligeant souvent les équipes de sécurité à trier des rapports bruyants. L’architecture du plugin répond à ce problème en exigeant qu’un résultat candidat n’entre pas dans le rapport uniquement parce qu’un chercheur l’a identifié. Il n’est inclus qu’après avoir survécu à un panel.

Chaque candidat est évalué par trois vérificateurs indépendants, un par angle : REACHABILITY, IMPACT et DEFENSES. Chacun renvoie un verdict structuré TRUE_POSITIVE ou FALSE_POSITIVE, accompagné d’une ou deux lignes indiquant le fichier:ligne décisif. Le quorum de conservation est de 2 sur 3. Si moins de trois votants répondent, le candidat ne peut pas être conservé du tout.

Le résultat du panel plafonne également le niveau de confiance déclaré pour le résultat. Un panel unanime à 3/3 permet un plafond de confiance élevé ; un quorum de 2/3 le plafonne à moyen. Un résultat ne peut pas revendiquer un niveau de confiance supérieur à celui que sa vérification a obtenu.

Point essentiel, le décompte est calculé en Python par le moteur de rendu du rapport, et non affirmé par le modèle ayant produit les résultats. Le champ verification.status du tampon de révision est défini sur verified uniquement lorsque l’enregistrement des votes prouve que le panel a été exécuté pour chaque résultat du rapport ; sinon, il est marqué unverified avec une raison indiquée. Cela rend le propre compte rendu de rigueur du rapport vérifiable, plutôt que simplement fondé sur la confiance.

Ce qu’une analyse écrit sur le disque

Chaque analyse crée dans le dépôt un répertoire horodaté CLAUDE-SECURITY-<timestamp>/ contenant trois artefacts :

• CLAUDE-SECURITY-RESULTS.md — le rapport lisible par l’humain. Chaque résultat comporte un identifiant tel que F1, ainsi qu’une sévérité (HIGH/MEDIUM/LOW), un niveau de confiance, un identifiant CWE, la ligne exacte du puits, l’impact, le scénario d’exploitation, les préconditions et une recommandation. L’utilisation des identifiants CWE (Common Weakness Enumeration) aligne les résultats sur le standard de classification MITRE largement adopté, rendant les résultats interopérables avec les workflows existants de suivi et de remédiation des vulnérabilités.
• CLAUDE-SECURITY-RESULTS.jsonl — les mêmes résultats, à raison d’un objet JSON par ligne.
• CLAUDE-SECURITY-REVISION-.json — le tampon de révision : quel commit a été analysé, avec quel niveau d’effort, les décomptes par sévérité et le degré de vérification de l’exécution. Le nom du fichier inclut -dirty lorsque des changements non commités faisaient partie de l’arborescence analysée.

Ce répertoire est le seul changement qu’une analyse apporte au checkout, et il est fourni avec son propre .gitignore afin qu’un git add accidentel ne puisse pas intégrer un rapport dans un commit. Supprimer ce .gitignore permet de committer le rapport afin de conserver une piste d’audit.

Correctifs et les trois affirmations que chacun doit satisfaire

La tâche de correction élabore chaque patch dans un clone temporaire du dépôt, ce qui garantit que l’arborescence de travail et l’index ne sont jamais touchés. Un agent indépendant de celui qui a écrit le patch examine ensuite le diff préparé et exécute la suite de tests propre au projet sur le changement.

Un fichier de correctif n’est écrit que si le vérificateur peut affirmer avec confiance les trois points suivants : le changement traite ce résultat précis, il n’introduit aucune nouvelle vulnérabilité et le comportement reste par ailleurs inchangé — un changement dans les entrées acceptées par le code comptant comme un changement de comportement. Toute modification qui affaiblit la sécurité tout en prétendant la corriger, par exemple un contrôle d’authentification assoupli ou un test désactivé, est automatiquement rejetée. Lorsque le vérificateur ne peut pas garantir ces trois critères, une courte note expliquant pourquoi est fournie à la place d’un patch.

Les correctifs sont placés dans le dossier patches/ du rapport sous la forme F<n>.patch. Rien n’est appliqué automatiquement. La note de patch indique explicitement si aucun test du dépôt ne couvre le code modifié, précisant alors que la vérification repose sur la revue de code plutôt que sur l’exécution des tests. Anthropic recommande d’appliquer chaque patch au moyen d’une pull request individuelle.

Exigences, coût et modèle de confiance

Le plugin nécessite un forfait payant avec Claude Code v2.1.154 ou version ultérieure, avec les workflows dynamiques activés dans /config. Il nécessite également Python 3.9.6 ou version ultérieure dans le PATH système sous le nom python3 (en utilisant uniquement la bibliothèque standard) et Git pour les analyses de changements et l’application de correctifs. Linux, macOS et Windows sont pris en charge, et les analyses sont décomptées des limites de tokens du forfait.

Exécutée dans la session de l’utilisateur avec ses permissions, l’analyse n’ajoute aucune isolation propre, ce qui signifie que les paramètres .claude/ commités, les hooks et CLAUDE.md continuent de s’appliquer. Bien qu’elle traite le contenu du dépôt comme des données plutôt que comme des instructions, cela ne constitue pas une défense contre les dépôts hostiles ; Anthropic recommande d’utiliser sandbox-runtime pour isoler les bases de code inconnues.

En outre, les analyses sont non déterministes et ne remplacent pas l’analyse statique traditionnelle, l’analyse des dépendances ni les revues de code. Le plugin arrive dans un paysage qui comprend des outils établis tels que Semgrep, Snyk et SonarQube, mais il se différencie par son pipeline multi-agent qui effectue une analyse sémantique des chemins de code plutôt que de s’appuyer principalement sur des règles de correspondance de motifs. En tant que produit bêta en version 0.10.0, son périmètre, sa précision et ses fonctionnalités peuvent évoluer.

Sources : documentation du plugin Claude Security, page produit Claude Security, code source du plugin, claude-plugins-official, annonce @claudeai et blog de la bêta publique de Claude Security