Anthropic lance la version bêta du plugin de sécurité « Claude Security » pour Claude Code : un scanner de vulnérabilités multi-agents qui s'exécute dans votre terminal

Le secteur technologique continue de livrer des avancées remarquables.

Anthropic lance la version bêta du plugin de sécurité « Claude Security » pour Claude Code : un scanner de vulnérabilités multi-agents qui s’exécute dans votre terminal

Anthropic a lancé le plugin Claude Security pour Claude Code en version bêta. Ce plugin effectue une analyse multi-agents des vulnérabilités d’un dépôt depuis une session Claude Code existante, puis transforme les résultats que vous sélectionnez en fichiers de correctifs que vous pouvez vérifier et appliquer vous-même. Lors de l’annonce, Anthropic a mis l’accent sur la polyvalence de l’outil, soulignant sa capacité à effectuer soit une analyse complète de l’ensemble du code source, soit à inspecter les modifications depuis le terminal juste avant un commit.

Le plugin ajoute une seule commande, /claude-security, qui ouvre un menu proposant trois tâches, comme l’indique la documentation officielle :

L’installation se fait à l’aide de deux commandes disponibles sur la boutique officielle d’Anthropic :

Si vous ne trouvez pas le plugin sur la marketplace, exécutez d’abord la commande /plugin marketplace add anthropics/claude-plugins-official. Le code source du plugin est accessible au public dans le dépôt « theclaude-plugins-official » ; il est actuellement à la version 0.10.0.

D’un autre côté, l’analyse est mise en œuvre sous la forme d’un workflow dynamique, c’est-à-dire un script d’orchestration JavaScript qui répartit les tâches entre les sous-agents. Le script définit six phases :

Dans la foulée, la recherche s’articule autour de quatre catégories fixes : « injection et entrée », « authentification et accès », « mémoire et sécurité » et « cryptographie et secrets ». Le critère « mémoire et sécurité » n’est pas pris en compte pour les composants écrits entièrement dans des langages garantissant la sécurité de la mémoire ; de ce fait, un composant écrit exclusivement en Python ou en TypeScript est évalué selon trois critères au lieu de quatre.

L’ampleur opérationnelle d’une session est déterminée par quatre niveaux d’effort distincts : faible, moyen, élevé et maximal. En fonction du niveau sélectionné, des seuils spécifiques s’appliquent : le nombre maximal de composants est plafonné à 12 pour les niveaux « faible » et « moyen », et passe à 24 pour les niveaux « élevé » et « maximal » ; chaque cellule de la matrice se voit attribuer 1 chercheur, ce nombre passant à 2 pour les niveaux « élevé » et « maximal » ; et le nombre de passages de remplissage des lacunes varie de 0 au niveau « bas », à 1 au niveau « moyen », jusqu’à 2 pour les niveaux « élevé » et « maximal ». Lorsque le champ d’application est limité ou que les différences sont minimes, le processus se résume à une configuration à chercheur unique, au lieu de déployer l’ensemble de la matrice. Cela garantit que l’évaluation reste strictement proportionnée à la cible, tout en conservant la même norme de vérification.

Autre élément, le mécanisme utilise des agents organisés par niveaux de système : l’orchestrateur s’exécute sur Opus, tandis que le cartographe de référentiel et l’explorateur de code en lecture seule s’exécutent sur Sonnet. De plus, le modèle d’IA de session est partagé par les scientifiques et les vérificateurs, et les agents d’analyse sont exclusivement limités aux outils en lecture seule.

Une affaire qui méritera assurément d’être suivie de près.

Dans le même ordre d’idées :

Reportage initial : MarkTechPost : MarkTechPost