# Audit de sécurité Claude Code : /security-review et GitHub Action > Comment vérifier la sécurité d’un projet vibe avec /security-review dans Claude Code. Étapes de configuration, modèle de GitHub Action, 6 types de vulnérabilités et limites en toute transparence. Source: https://ailoot.ai/blog/fr/claude-code-security-review/ Canonical: https://ailoot.ai/blog/fr/claude-code-security-review/ Language: fr Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-6b7bfec7360063a69b3c2e258438bfa74db82be6874f8565f596149c1c158351 L’auteur du contenu d’origine décrit son expérience : « Je viens de lancer security-review sur mon propre projet vibe, et l’équipe a trouvé plusieurs vrais problèmes en 4 minutes, qui ont déjà été corrigés. » C’est le même travail qui prenait autrefois une journée à un consultant externe. Pour en savoir plus sur la configuration des outils, consultez la [documentation Ailoot](https://ailoot.ai/docs/).
[Guides Ailoot](https://ailoot.ai/docs/)
## Qu’est-ce que /security-review dans Claude Code ?
Points clés de la section `/security-review` est une commande intégrée à Claude Code qui analyse la sécurité de l’ensemble du projet ou des modifications en cours directement depuis le terminal. Anthropic l’a lancée le 20 février 2026 dans le cadre de Claude Code Security et l’a rendue accessible à tous les utilisateurs Pro, Max et API Console. La requête est facturée sur votre solde habituel d’API Claude.
La commande fonctionne selon deux modes. En local : lancez `/security-review` dans le terminal, et Claude lit le dépôt et produit un rapport. Côté serveur : le même moteur est installé sous forme de GitHub Action et publie automatiquement des commentaires en ligne sur chaque Pull Request. Contrairement aux scanners SAST classiques (Snyk Code, Semgrep, SonarQube), `/security-review` ne s’appuie pas sur des règles prédéfinies. Il lit le code comme le ferait un ingénieur en activité : il suit les flux de données, comprend le framework utilisé et repère les limites de confiance, et détecte des vulnérabilités qu’aucune règle ne décrit.

Claude Code Security lit et analyse votre code comme le ferait un chercheur en sécurité humain : il comprend les interactions entre les composants, suit la circulation des données dans l’application et détecte des vulnérabilités complexes que les outils fondés sur des règles ne repèrent pas.

— Anthropic, https://www.anthropic.com/news/claude-code-security
Cela ne signifie pas que `/security-review` remplace un pentest externe ou des tests en conditions réelles dans un environnement de staging. La commande peut automatiser une partie de la revue initiale, sans fraction mesurée de couverture dans cet article. Voici comment l’exécuter correctement et ce que Claude trouvera dans votre projet. ## Comment lancer /security-review en 5 étapes ?
Points clés de la section Mettez Claude Code à jour, ouvrez le projet dans un terminal, lancez `/security-review`, attendez le rapport (1 à 5 minutes pour un projet moyen), lisez les niveaux de gravité et demandez à Claude d’appliquer les corrections. La commande fonctionne avec n’importe quelle stack : Next.js, Django, FastAPI, Rails, Go, Rust. Aucune configuration particulière n’est nécessaire.
**Étape 1. Mettre Claude Code à jour.** La commande fonctionne à partir de la version publiée le 20 février 2026. ```bash claude update ``` Si vous avez installé Claude Code avec npm, vous pouvez aussi exécuter : ```bash npm install -g @anthropic-ai/claude-code@latest ``` Vérifiez que `/security-review` est disponible : ```bash claude /help | grep security ``` **Étape 2. Ouvrir le projet et se connecter à Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Étape 3. Lancer la commande.** Dans Claude Code, saisissez simplement : ``` /security-review ``` Claude passe automatiquement par 3 phases d’analyse : 1. **Recherche du contexte du dépôt** - lit la structure et identifie la stack, les routes et les requêtes à la base de données. 2. **Analyse comparative** - compare l’état actuel aux schémas de vulnérabilité courants pour cette stack. 3. **Évaluation des vulnérabilités** - répertorie chaque suspicion avec un niveau de confiance sur une échelle de 1-10. Seuls les résultats dont le niveau de confiance est ≥ 8 figurent dans le rapport. **Étape 4. Lire le rapport.** Le résultat est présenté sous forme de tableau Markdown. Pour chaque problème, Claude fournit : - **Fichier et numéro de ligne** (par exemple, `src/auth/login.ts:42`) - **Gravité** (HIGH / MEDIUM / LOW) - **Catégorie** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Description** - ce qui pose problème - **Scénario d’exploitation** - comment un attaquant pourrait exploiter le problème - **Recommandation** - comment le corriger **Étape 5. Lui demander d’appliquer les corrections.** Ensuite, vous pouvez travailler avec Claude comme avec un agent classique : > « Applique les corrections de gravité HIGH du rapport, une par une, avec une description de PR. » Claude ouvre chaque fichier et propose une modification ; vous la confirmez. Sur un vrai projet, j’ai résolu 5 problèmes en 40 minutes, au lieu des 3 heures prévues.
[Guides Ailoot](https://ailoot.ai/docs/)
## Quelles vulnérabilités /security-review détecte-t-il ?
Points clés de la section Claude détecte 6 catégories : l’injection SQL et les injections en général, les XSS, les problèmes d’authentification et d’autorisation, les fuites de données sensibles, les failles dans les dépendances tierces et les secrets codés en dur. La commande peut aussi analyser une logique d’authentification répartie sur plusieurs fichiers, ce que les scanners fondés sur des règles ne savent pas faire.
La liste complète des éléments inclus par défaut dans l’analyse figure dans la [documentation officielle d’Anthropic](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) : | Catégorie | Éléments recherchés | |----|----| | **Injection SQL** | Concaténation directe de chaînes en SQL, appels ORM non sécurisés (`raw()` sans paramètres), Prisma `$queryRawUnsafe` | | **XSS** | Affichage avec `dangerouslySetInnerHTML` sans assainissement, systèmes de templates sans échappement automatique, `innerHTML` provenant d’une entrée utilisateur | | **Failles d’authentification** | Jetons réutilisables, absence de vérification des autorisations dans les routes API, JWT sans date d’expiration, fixation de session | | **Traitement non sécurisé des données** | Validation côté client uniquement, réponses contenant des champs supplémentaires (sur-récupération), redirection ouverte | | **Vulnérabilités des dépendances** | Versions vulnérables de paquets npm/pip/cargo, vérifiées avec `npm audit` et les outils équivalents | | **Secrets** | Clés API codées en dur, jetons dans `.env.example`, mots de passe dans le code | En outre, la commande couvre des catégories rarement prises en compte par les scanners automatisés : - **Injection de commande** - exécution d’une entrée utilisateur dans un shell (`child_process.exec(userInput)`) - **Traversal de chemin** - chargement d’un fichier via `../../etc/passwd` - **XXE** - XML avec entités externes - **Injection de template** - SSTI dans Jinja/Handlebars/EJS - **Injection NoSQL** - opérateurs `$ne`, `$gt` dans les requêtes MongoDB - **Mauvaise utilisation de la cryptographie** - utilisation de MD5, du mode ECB ou d’un IV statique Claude attribue un niveau de gravité à chaque résultat. L’échelle est simple : - **HIGH** - exploitation à distance sans authentification, fuite de données touchant tous les utilisateurs - **MEDIUM** - exploitation nécessitant des conditions supplémentaires (une session est requise / une entrée spécifique est nécessaire) - **LOW** - vecteur potentiel, pas critique pour l’instant, mais à corriger À savoir : dans sa configuration standard, Claude **ne signale pas** les DoS, les problèmes de limitation du débit, l’épuisement de la mémoire, les redirections ouvertes sans impact démontré, l’injection de regex / ReDoS ou l’usurpation de journaux. C’est intentionnel afin d’éviter de vous submerger de bruit. Si ces catégories sont importantes, complétez les règles (voir la section sur le filtrage des faux positifs ci-dessous). ## Comment configurer une GitHub Action pour automatiser les revues ?
Points clés de la section Anthropic a publié l’action officielle `anthropics/claude-code-security-review@main`. Elle s’intègre avec un seul fichier de workflow et publie automatiquement des commentaires en ligne sur chaque Pull Request au sujet des vulnérabilités détectées. Configurez `CLAUDE_API_KEY` et les permissions du workflow. L’Action officielle avertit qu’elle n’est pas renforcée contre l’injection de prompt et doit revoir des PR fiables ; examinez accès des contributeurs et du workflow avant activation.
**Étape 1. Obtenir une clé API.** Allez sur [console.anthropic.com](https://console.anthropic.com/), créez une clé API et copiez-la. **Étape 2. Ajouter la clé aux secrets du dépôt.** Dans GitHub : Settings → Secrets and variables → Actions → New repository secret. Nommez-la `CLAUDE_API_KEY` ; sa valeur est votre clé. **Étape 3. Créer un fichier de workflow.** Enregistrez-le sous `.github/workflows/security.yml` : ```yaml name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} ``` **Étape 4. Fusionner la branche dans main.** L’action démarrera automatiquement à la prochaine PR. **Ce que fait l’action :** - S’exécute à l’ouverture ou à la synchronisation de chaque Pull Request. - Prend le diff entre la branche de la PR et main. - Utilise le même moteur que la commande locale `/security-review`. - Publie des commentaires en ligne directement sur les lignes de code suspectes. - Duplique le rapport complet dans le Job Summary. **Détails importants des `permissions` :** - `pull-requests: write` - pour publier des commentaires en ligne. - `contents: read` - pour lire le code. Pas de `write`. L’action ne modifie pas le code elle-même ; elle se contente de produire un rapport. Ces permissions suffisent pour un dépôt privé. Pour un dépôt public, vous pouvez aussi spécifier `actions: read` si vous utilisez des workflows réutilisables. ## Comment filtrer les faux positifs et modifier la sensibilité ?
Points clés de la section L’action comporte 9 paramètres qui permettent de configurer son comportement pour votre projet. Les principaux sont : `exclude-directories` (par exemple, `tests/,fixtures/`), `false-positive-filtering-instructions` (chemin vers un fichier md contenant vos règles expliquant « pourquoi ceci n’est pas une vulnérabilité… ») et `custom-security-scan-instructions` pour ajouter des contrôles propres à votre domaine.
Tableau complet des paramètres de la GitHub Action ([source : README du dépôt](https://github.com/anthropics/claude-code-security-review)) : | Paramètre | Valeur par défaut | Fonction | |----|----|----| | `claude-api-key` | \- | Clé API Anthropic. Obligatoire. | | `comment-pr` | `true` | Indique s’il faut publier des commentaires en ligne dans la PR | | `upload-results` | `true` | Indique s’il faut enregistrer le résultat comme artefact pendant 90 jours | | `exclude-directories` | \- | Liste séparée par des virgules : `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Modèle à utiliser | | `claudecode-timeout` | `20` | Délai d’expiration en minutes | | `run-every-commit` | `false` | Exécuter à chaque push, et pas seulement sur les PRs | | `false-positive-filtering-instructions` | \- | Chemin vers un fichier md contenant vos règles | | `custom-security-scan-instructions` | \- | Chemin vers un fichier md contenant des contrôles supplémentaires | **Exemple de configuration du filtrage des faux positifs.** Créez le fichier `.claude/security/false-positives.md` : ```markdown # Règles de filtrage des faux positifs pour notre projet - Tout `dangerouslySetInnerHTML` dans `src/lib/email/layout.ts` est sûr : le HTML est assemblé à partir de modèles fiables et passe par `sanitize-html` lors de l’écriture en base de données, pas au moment du rendu. - Ne signale pas les clés API de test codées en dur dans `__tests__/fixtures/*.ts`. Toutes les clés commencent par `sk-test-fake-`. - La concaténation SQL dans `src/lib/admin/migrations.ts` est acceptable : le fichier s’exécute uniquement en tant que root, et les données d’entrée proviennent de variables d’environnement. ``` Ajoutez-le au workflow : ```yaml - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} false-positive-filtering-instructions: .claude/security/false-positives.md ``` **Les instructions personnalisées pour les analyses de sécurité** fonctionnent de la même façon. Créez un fichier contenant les règles particulièrement importantes pour votre projet : ```markdown # Vérifications supplémentaires pour notre projet - Chaque point de terminaison sous `/api/admin/*` doit vérifier le rôle d’administrateur au moyen d’un wrapper partagé. Sans ce wrapper, la gravité est HIGH. - Tous les webhooks YooKassa / CloudPayments doivent vérifier la signature avant d’analyser le corps de la requête. Sans cette vérification, la gravité est HIGH. - Les jetons Magic Link doivent être à usage unique (marqués comme utilisés après la première requête valide). Les jetons réutilisables sont de gravité MEDIUM. ``` Ce n’est plus un preset Anthropic : vous transmettez votre expertise du projet sous forme de règles que Claude applique à chaque fois. C’est tout le principe de « la méthode avant le modèle ». Pour en savoir plus sur la méthodologie de contexte pour Claude, consultez les guides [« Configurer CLAUDE.md »](https://ailoot.ai/blog/fr/claude-md-template/) et [« Le Second Brain dans Claude Code »](https://ailoot.ai/blog/fr/claude-code-second-brain/). ## Que ne détecte PAS Claude et pourquoi : les limites en toute transparence
Points clés de la section Une revue de code n’exerce pas à elle seule l’application active et ne vérifie pas le déploiement. Elle peut signaler des risques de concurrence, de logique métier ou de configuration visibles dans le code ; tests en staging et inspection du déploiement réel restent nécessaires pour confirmer comportement et risques restants.
Anthropic indique clairement ce qui est désactivé par défaut et pourquoi ([source : README du dépôt](https://github.com/anthropics/claude-code-security-review)) : - **Déni de service** - trop de bruit, avec presque toujours un impact faible. - **Problèmes de limitation du débit** - traités au niveau de l’infrastructure, pas dans le code. - **Épuisement de la mémoire / du CPU** - même chose. - **Validation générique des entrées sans impact démontré** - valider chaque champ entraîne une avalanche de faux positifs. - **Redirection ouverte** - comportement souvent intentionnel. Ce que la revue seule ne peut entièrement vérifier sans preuves d’exécution ou de déploiement : - **Configuration du serveur de production.** En-têtes NGINX, politiques CORS, paramètres TLS, ports en écoute. Ces éléments doivent être vérifiés manuellement dans un environnement de staging. - **Conditions de concurrence.** Par exemple, une double dépense lors de demandes de remboursement simultanées. L’analyse statique peut signaler des motifs suspects ; le comportement concurrent exige encore des tests. - **Failles de logique métier des paiements.** Si le total de la commande est calculé côté client puis simplement envoyé au prestataire de paiement, il s’agit d’un problème de gravité HIGH. Toutefois, sans contexte explicite sur le fonctionnement attendu du paiement, Claude ne détecte pas toujours ce schéma. - **IDOR au niveau de la base de données.** Si la requête `SELECT * FROM orders WHERE id = $1` ne vérifie pas `WHERE user_id = $session.userId`, Claude le détecte souvent. Mais si cette vérification est implémentée par un middleware ORM et que Claude ne peut pas voir le flux complet des données, il peut passer à côté. - **Résistance à l’ingénierie sociale / au phishing.** Cela n’a rien à voir avec le code. Utilisez `/security-review` comme revue statique initiale. Complétez avec tests dynamiques en staging, vérifications des rôles et permissions, contrôles SAST pertinents et configuration réellement déployée. Aucun pourcentage de couverture mesuré n’est établi ici. Définissez portée et fréquence de l’évaluation externe selon risques et changements du système. Ni une commande ni un audit périodique ne prouvent une sécurité couverte à 100 %. ## Comment l’auteur du contenu d’origine a effectué un audit de sécurité sur un projet vibe
Points clés de la section J’ai lancé `/security-review` sur mon propre projet TypeScript avec Next.js, Prisma, PostgreSQL et Redis. En 4 minutes, la commande a effectué un audit initial et fourni plusieurs résultats bien étayés, de gravité variable. J’ai finalement terminé les corrections fonctionnelles en une heure et demie. C’était moins cher et plus rapide que n’importe quel pentest externe.
Voici les résultats. Un tableau typique pour un projet vibe moyen au stade « fonctionne en production, mais n’a pas encore été audité » : plusieurs suspicions concernant le flux d’authentification, le traitement des webhooks de l’intégration de paiement, la gestion des téléversements de fichiers et quelques remarques précises sur le traitement du HTML au rendu. Je ne décris pas les détails publiquement ; certaines recommandations ont déjà été appliquées, tandis que d’autres sont encore dans des PR. Dans ce projet rapporté, l’analyse initiale était utile et rapide, sans établir de pourcentage d’audit couvert ou de durée universelle. Ce que j’ai écarté comme faux positifs : - Des résultats concernant un DoS via des expressions régulières dans la validation des entrées : la charge réelle ne sollicite pas ces expressions. - Un résultat concernant une clé API codée en dur : c’était une clé de test, avec le préfixe explicite `fake-`, dans les fixtures. Durée de l’opération. L’exécution elle-même a pris 4 minutes. La lecture du rapport a pris 25 minutes. L’application des corrections et les tests ont pris environ une heure. Au total : environ une heure et demie entre « le début » et « tout est dans main ». Un pentest externe portant sur le même périmètre prend une semaine calendaire et coûte plusieurs dizaines de fois plus cher. À retenir. `/security-review` ne remplace pas un pentest externe. Il peut identifier des problèmes utiles du code, comme lors de l’analyse de quatre minutes rapportée par l’auteur. Revoyez et testez les corrections, puis vérifiez comportement et configuration déployée séparément ; l’analyse n’élimine pas le risque de sécurité du projet. ## Comment intégrer /security-review à votre routine de pre-commit ?
Points clés de la section Avant les commits importants, lancez `/security-review` dans la session du projet, lisez les constats, corrigez les problèmes confirmés et relancez les tests pertinents. C’est une procédure de revue, pas une interdiction technique de commiter.
L’ancien hook utilisant `git_commit`, `--severity HIGH` et `--fail-on-find` n’est pas une recette fonctionnelle documentée et ne doit pas servir de garde de sécurité. Cet article ne fournit aucun hook local vérifié bloquant les commits. La GitHub Action officielle présentée plus haut publie des constats de PR ; ses commentaires ne prouvent pas un blocage de commit ou de fusion. Vous trouverez une explication complète des hooks dans le guide [« Hooks dans Claude Code »](https://ailoot.ai/blog/fr/claude-code-hooks/). Une autre possibilité consiste à utiliser les [routines](https://ailoot.ai/blog/fr/claude-code-routines/) pour créer une routine `pre-deploy-check` qui exécute `/security-review` + `npm run build` + `npm run test` avec une seule commande. Pour en savoir plus, consultez la documentation Ailoot. Si vous utilisez des [serveurs MCP](https://ailoot.ai/blog/fr/mcp-servers-claude-code/), vous pouvez intégrer les résultats de `/security-review` à un système de gestion des incidents (Sentry, Linear, Notion) afin que chaque problème de gravité HIGH génère automatiquement un ticket. ## FAQ sur /security-review
Points clés de la section 5 questions fréquentes : combien coûte la commande, à quelle fréquence l’exécuter, avec quelles stacks elle fonctionne, que faire si Claude a déjà détecté cette vulnérabilité et s’il est possible de la limiter à certains fichiers. Des réponses courtes, sans fioritures.
**Combien coûte une exécution ?** Cela dépend de la taille du projet. Pour mes 30K lignes, une exécution consomme environ \$0.30-0.50 de crédit API. Un grand dépôt d’entreprise comptant un million de lignes coûte jusqu’à \$5-8 par exécution. C’est plusieurs dizaines de fois moins cher que n’importe quel abonnement à un scanner SaaS. **À quelle fréquence dois-je l’exécuter en local ?** Au minimum avant chaque mise en production. Envisagez-la aussi avant les commits et PR importants. Cet article ne fournit aucun hook automatique vérifié bloquant les commits. **Avec quelles stacks fonctionne-t-il ?** Avec tout ce que Claude peut lire. D’après les observations de l’auteur, les éléments suivants ont été vérifiés : Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. La qualité est moindre avec des langages très exotiques (Erlang, Elixir, Clojure), mais la commande trouvera quelque chose. **Que faire si Claude signale chaque fois la même « vulnérabilité », alors que ce n’en est pas une ?** Ajoutez-la à `false-positive-filtering-instructions` en expliquant « pourquoi c’est sûr ». Claude cessera de la signaler lors des prochaines exécutions. **Puis-je l’exécuter uniquement sur certains fichiers ?** En local, oui : lancez simplement `/security-review src/lib/auth/*.ts`. Dans la GitHub Action, seul le diff de la PR actuelle est vérifié, ce qui correspond généralement à ce qu’on entend par « certains fichiers ». ## Sources
### Sources - [Anthropic - Annonce du lancement de Claude Code Security](https://www.anthropic.com/news/claude-code-security) - annonce officielle datée du 20 février 2026 - [Centre d’aide Anthropic - Revues de sécurité automatisées dans Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - instructions officielles pour l’exécuter - [GitHub : anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - source de la GitHub Action et README complet - [Documentation Claude Code - Revue de code](https://code.claude.com/docs/en/code-review) - documentation générale d’Anthropic - [Centre d’aide Anthropic - Utiliser Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - produits associés - [Port - Intégrer les revues de sécurité de Claude Code](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - intégration des résultats dans un portail de développement interne - [Historique des modifications de Claude Code](https://code.claude.com/docs/en/changelog) - historique de publication de la commande
Pour en savoir plus, consultez la [documentation Ailoot](https://ailoot.ai/docs/).
[Guides Ailoot](https://ailoot.ai/docs/)
[Accéder à Ailoot](https://ailoot.ai/)
## Questions fréquentes : Audit de sécurité Claude Code : /security-review et GitHub Action ### Un rapport de sécurité sans problème prouve-t-il que l’application est sûre ? Non. C’est une revue initiale avec faux négatifs et filtrage possibles. Vérifiez les corrections, exercez rôles et concurrence en staging et inspectez la configuration réellement déployée. ### La GitHub Action bloque-t-elle automatiquement commits ou fusions ? Le workflow présenté ne l’établit pas. Il publie des constats de PR ; revoyez-les et testez les corrections confirmées. L’article ne fournit aucun hook local vérifié bloquant les commits. ## Ailoot · L’entreprise et son portefeuille de projets Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI. L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois. Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.