En bref
/security-review est une commande slash native de Claude Code qui déclenche un audit sécurité sur votre diff local avant un commit. Elle cible les développeurs sur plans Pro, Max ou API Console pay-as-you-go. Deux modes d'usage : interactif dans le terminal, ou en CI via la GitHub Action officielle anthropics/claude-code-security-review. La commande se tape sans argument obligatoire.
Éligibilité par plan
La disponibilité dépend de votre formule Anthropic. Au 2026-05-12, la doc officielle FR (centre d'aide Anthropic, article 11932705) liste explicitement trois plans compatibles.
| Plan | /security-review (CLI) | GitHub Action |
|---|---|---|
| Pro (individuel) | Oui | Oui via clé API |
| Max (individuel) | Oui | Oui via clé API |
| API Console (pay-as-you-go) | Oui | Oui |
| Plan gratuit (Free) | Non documenté comme éligible | Non |
| Team / Enterprise | Non précisé dans la doc FR au 2026-05-12 | À confirmer auprès du support |
Côté CI, la GitHub Action a besoin d'une clé API Claude valide stockée en secret du dépôt. Concrètement, cela veut dire un crédit API Console actif ou un plan compatible qui expose une clé utilisable depuis l'extérieur du CLI.
Pourquoi /security-review change la donne
La promesse d'Anthropic est claire dans le blog produit du 2025-08-06 : faire d'une revue de sécurité un geste de quelques secondes, intégré au workflow de code. Là où un scanner statique comme Semgrep ou Snyk applique un catalogue de règles (souvent calé sur l'OWASP Top 10), /security-review s'appuie sur le raisonnement du modèle pour analyser le code en contexte. Le README de la GitHub Action revendique une "analyse sémantique profonde" et un "filtrage avancé des faux positifs", deux promesses absentes des outils basés sur signatures.
Trois différences pratiques avec un scanner classique :
- La commande raisonne sur le diff en cours. Elle voit la fonction modifiée et son appelant, pas seulement la ligne suspecte.
- Elle est indépendante du langage. Le README de la GHA précise "language-agnostic", ce qui évite d'installer un parseur dédié à chaque stack.
- Elle propose un fix exploitable. Une fois le finding affiché, vous pouvez demander à Claude d'appliquer le patch dans la foulée, sans copier-coller manuel.
L'inverse est aussi vrai : /security-review ne remplace pas un scanner statique. La doc Anthropic insiste sur le mot "compléter", pas "remplacer". On y revient dans la section limites.
Utiliser la commande en local
Préparer une session Claude Code
Ouvrez votre terminal dans le dossier racine du projet et lancez claude. En cas de comportement inattendu, vérifiez votre version avec claude --version. La commande est disponible depuis le 2025-08-06.
cd ~/projects/mon-appclaude
Modifier du code sans committer
La commande analyse le diff en cours. Tant que vous n'avez pas committé, modifiez vos fichiers comme d'habitude. Pour un premier test, vous pouvez introduire une faille évidente : une requête SQL concaténée ou un secret hardcodé.
Lancer la commande
Dans la session Claude Code active, tapez la commande sans argument.
/security-review
Claude orchestre alors plusieurs agents internes : un premier identifie les vulnérabilités sur la diff, puis des agents secondaires filtrent les faux positifs par catégorie (SQL injection, hardcoded API key, etc.). Cette mécanique "FP filter" est documentée comme un atout de la commande native, et se voit directement dans la sortie console.

Une fois les agents terminés, Claude produit une liste de findings classés par sévérité. Chaque finding contient une description, une localisation, un scénario d'exploitation et une recommandation concrète.

Demander un fix
Si un finding vous paraît juste, demandez à Claude de l'appliquer dans la foulée. Un simple "applique le fix sur le finding 1" suffit. Le modèle réécrit le bloc concerné, vous validez le diff comme pour n'importe quelle édition de fichier.
Re-scanner avant le commit
Une fois les corrections appliquées, relancez /security-review pour confirmer qu'aucun finding ne reste. Cette boucle "scan, fix, re-scan" tient en quelques minutes pour un diff de taille moyenne.
La source primaire FR ne documente aucun flag ou argument pour la commande au 2026-05-12. Si Anthropic ajoute des options par la suite, la sortie /security-review --help dans le CLI devrait les exposer.
Automatiser via la GitHub Action
Le pendant CI de la commande est le repo open source anthropics/claude-code-security-review (ouvre un nouvel onglet), publié sous licence MIT. Au 2026-05-12, il cumule 4 573 étoiles, 432 forks et 69 issues ouvertes, dernier push le 11 février 2026. Le job s'exécute à chaque pull request et commente les findings inline sur la PR.
Workflow minimal
Voici la version exacte fournie par le README. Elle tient en quinze lignes, scanne le diff de la PR et poste les findings comme commentaires.
name: Security Reviewpermissions:pull-requests: write # Needed for leaving PR commentscontents: readon:pull_request:jobs:security:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4with:ref: ${{ github.event.pull_request.head.sha || github.sha }}fetch-depth: 2- uses: anthropics/claude-code-security-review@mainwith:comment-pr: trueclaude-api-key: ${{ secrets.CLAUDE_API_KEY }}
Deux points à retenir pour la mise en place :
- Secret
CLAUDE_API_KEY: créez-le dans les paramètres du repo sousSettings → Secrets and variables → Actions. La clé doit avoir accès à l'API Claude et à Claude Code. - Permissions GITHUB_TOKEN :
pull-requests: writepour poster les commentaires,contents: readpour lire le code. Pas besoin de plus.
Options de configuration
Les principales options exposées par l'Action sont documentées dans le README au 2026-05-12.
| Option | Défaut | Rôle |
|---|---|---|
claude-api-key (requis) | aucun | Clé API avec accès Claude API et Claude Code |
comment-pr | true | Poster les findings comme commentaires PR |
claude-model | claude-opus-4-1-20250805 | Modèle utilisé pour l'analyse |
claudecode-timeout | 20 minutes | Timeout maximal d'analyse |
exclude-directories | aucun | Dossiers exclus du scan (ex. fixtures de tests) |
Modèle par défaut
Au 2026-05-12, le README annonce claude-opus-4-1-20250805 comme modèle par défaut de l'Action. Ce modèle est antérieur aux générations Opus 4.x les plus récentes. Vérifiez le README avant de fixer un modèle dans votre workflow, le défaut peut évoluer.
L'Action est diff-aware : elle n'analyse que les fichiers modifiés par la PR, pas tout le repo. Cela évite l'explosion de coût qui surviendrait sur un projet de plus de quelques milliers de lignes.
Les 5 familles officielles détectées
La doc Anthropic FR formalise cinq familles de vulnérabilités. Le README de la GHA détaille des sous-types techniques plus granulaires. Les deux listes ne se contredisent pas, la seconde est plus fine.
| Famille officielle (doc Anthropic FR) | Sous-types concrets listés dans le README de la GHA |
|---|---|
| Risques d'injection SQL | Injection SQL, command injection, LDAP, XPath, NoSQL, XXE |
| Cross-site scripting (XSS) | XSS réfléchi, stocké, DOM-based |
| Failles d'authentification et d'autorisation | Broken auth, privilege escalation, IDOR, bypass logic, session flaws |
| Manipulation non sécurisée des données | Hardcoded secrets, sensitive data logging, information disclosure, PII violations |
| Vulnérabilités de dépendances | Packages vulnérables, risques de typosquatting |
Cette structure à cinq familles sert de grille de lecture. Sur le terrain, vous croiserez aussi des findings autour de la crypto faible ou des configurations par défaut non sécurisées : Anthropic les rattache à la famille "manipulation non sécurisée des données" ou aux "vulnérabilités de dépendances" selon le cas.
Limites et faux positifs
À lire avant de mettre l'Action en production
Le README de anthropics/claude-code-security-review est explicite : "This action is not hardened against prompt injection attacks and should only be used to review trusted PRs." Concrètement, un attaquant qui ouvre une PR depuis un fork peut injecter des instructions dans son code pour manipuler la revue. La recommandation officielle est d'exiger une approbation manuelle d'un mainteneur avant qu'un workflow ne se lance sur une PR de contributeur externe (option GitHub "Require approval for all external contributors").
Quatre autres limites à garder en tête :
- Code envoyé à l'API Anthropic. Chaque appel transmet votre diff aux serveurs d'Anthropic. Pour du code propriétaire sensible ou sous NDA, validez d'abord la politique data de votre organisation et celle d'Anthropic.
- Coût en tokens. La commande facture comme n'importe quel appel API. Sur un repo très actif (dizaines de PR par jour), surveillez la consommation, surtout si vous activez l'Action sur chaque push.
- Catégories filtrées par défaut. Pour réduire le bruit, la GHA exclut Denial of Service, rate limiting, exhaustion mémoire/CPU, validation d'entrées sans impact prouvé et open redirect. Si ces angles vous intéressent, ajustez les instructions personnalisées.
- Pas de garantie de couverture. Anthropic le dit dans la doc FR : "Bien que les examens de sécurité automatisés aident à identifier de nombreuses vulnérabilités courantes, ils doivent compléter, et non remplacer, vos pratiques de sécurité existantes." Aucun chiffre de précision ni de rappel n'est publié.
Intégrer la commande à un workflow DevSecOps
/security-review brille quand elle s'insère dans une chaîne d'outils, pas seule. Voici un combo défensif qu'on retrouve souvent sur les projets matures. À coupler avec la page bonnes pratiques de sécurité et le guide CI/CD et cybersécurité.
| Outil | Rôle | Complémentarité avec /security-review |
|---|---|---|
| gitleaks | Détection de secrets commités dans l'historique git | Couvre les leaks historiques que la commande ne voit pas (elle ne lit que le diff de la PR) |
| dependabot | Mises à jour de dépendances vulnérables | Adresse la famille "vulnérabilités de dépendances" en amont, libérant /security-review pour le code applicatif |
| CODEOWNERS | Revue humaine ciblée par chemin | Force un humain à valider les findings sur les chemins sensibles (auth, paiement) |
| Branch protection | Statuts requis avant merge | Le job GHA peut devenir un statut bloquant si vous voulez verrouiller le merge |
Côté CLI, vous pouvez aussi déclencher la commande automatiquement via un hook Claude Code de type PreToolUse sur git commit. Le mécanisme est décrit dans la page hooks et vous évite d'oublier la revue avant un push.
Si une fuite de clé API est passée entre les mailles, la procédure de remédiation est documentée dans Que faire en cas de fuite de clé API. Pour durcir les serveurs MCP que Claude appelle pendant la revue, voir Sécurité des MCP. Et pour des agents communautaires dédiés à l'audit sécurité (Security Reviewer, TDD Guide), la sélection est sur Meilleurs plugins sécurité.
Sur la question du modèle de menace, retenez que /security-review ne remplace ni un pentest manuel, ni un SAST commercial calibré sur votre stack. Elle attrape une part significative des erreurs récurrentes (concaténation SQL, secrets oubliés, contrôles d'accès manquants) avant qu'elles n'atteignent la prod, ce qui est déjà précieux.
Ne pas confondre avec le skill everything-claude-code:security-review
L'écosystème Claude Code héberge un skill communautaire homonyme dans le plugin everything-claude-code (ouvre un nouvel onglet) (180k+ étoiles GitHub, vérifié 2026-05-13). Quand ce plugin est installé, l'autocomplete /security-review propose les deux entrées côte à côte. Ce ne sont pas la même bête. Pour creuser le plugin lui-même et la collection de skills qu'il embarque, voir notre catalogue Awesome Skills et la comparaison des skills.
| Critère | /security-review natif Anthropic | /everything-claude-code:security-review (skill plugin) |
|---|---|---|
| Type | Commande slash native, intégrée au CLI | Skill markdown chargé dans le contexte de Claude |
| Mécanique | Architecture multi-agents : un agent identifie les vulnérabilités, des agents "FP filter" filtrent les faux positifs par catégorie | Charge une checklist OWASP statique dans le prompt, demande à Claude de l'appliquer |
| Diff analysé | Working tree non commité | git log origin/HEAD... (échoue sans remote origin configuré) |
| Sortie | Findings structurés (severity, category, exploit scenario, recommandation) | Texte libre selon le prompting général de Claude |
| Couverture | 5 familles officielles + sous-types (SQL, XSS, auth, validation, dépendances) | 10 catégories OWASP étendues (secrets, validation, SQL, auth, XSS, CSRF, rate limiting, exposition, blockchain Solana, dépendances) |
| Dépendances | Aucune (intégré au CLI) | Installation préalable du plugin everything-claude-code |
| Plans éligibles | Pro, Max, API Console pay-as-you-go | Tous (aucune restriction côté Anthropic, c'est juste un skill markdown) |
| Mise à jour | Géré par Anthropic | Versioné dans le repo disler/everything-claude-code |
En pratique : si vous avez accès à la native (plan compatible), prenez la native, elle a été conçue pour le job. Si vous êtes en plan Free ou si vous voulez un workflow communautaire forkable, le skill plugin reste valable, mais c'est un autre objet, un prompt enrichi, pas une commande dédiée.
Dans l'autocomplete : tapez /security-review, descendez avec ↓ pour voir l'entrée sans préfixe (native) et celle avec préfixe everything-claude-code: (skill). Choisissez selon ce que vous voulez faire.
Aller plus loin
Au-delà de la commande slash, Anthropic propose un produit web nommé "Claude Code Security". C'est une offre Enterprise pour le scan continu d'une codebase complète, avec dashboard et suggestions de patches groupées. Au 2026-05-12, ce produit reste distinct de /security-review : la commande slash s'adresse à tous les plans payants individuels, le produit web vise les équipes Enterprise. Si vous arrivez sur cette page en cherchant le produit web, consultez la doc officielle Anthropic plutôt que cet article.
Liens officiels à mettre en favori :
- Examens de sécurité automatisés dans Claude Code (ouvre un nouvel onglet) (doc FR, source primaire)
- Automate security reviews with Claude Code (ouvre un nouvel onglet) (annonce produit, 2025-08-06)
- anthropics/claude-code-security-review (ouvre un nouvel onglet) (repo GHA, MIT)
Prochaines étapes
- Activer
/security-reviewlocalement dès la prochaine session Claude Code, sur un diff réel - Brancher la GitHub Action sur un dépôt secondaire pour calibrer le coût et la pertinence des findings avant de l'imposer en CI sur les repos critiques
- Lire la page hooks pour automatiser le déclenchement de la commande avant chaque commit
- Compléter la défense avec les pratiques détaillées dans bonnes pratiques de sécurité et CI/CD et cybersécurité