Audit de sécurité Claude Code : /security-review et GitHub Action

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.

Qu’est-ce que /security-review dans Claude Code ?#

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.

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 ?#

Étape 1. Mettre Claude Code à jour. La commande fonctionne à partir de la version publiée le 20 février 2026.

claude update

Si vous avez installé Claude Code avec npm, vous pouvez aussi exécuter :

npm install -g @anthropic-ai/claude-code@latest

Vérifiez que /security-review est disponible :

claude /help | grep security

Étape 2. Ouvrir le projet et se connecter à Claude Code.

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.

Quelles vulnérabilités /security-review détecte-t-il ?#

La liste complète des éléments inclus par défaut dans l’analyse figure dans la documentation officielle d’Anthropic :

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 ?#

Étape 1. Obtenir une clé API. Allez sur 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 :

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é ?#

Tableau complet des paramètres de la GitHub Action (source : README du dépôt) :

Exemple de configuration du filtrage des faux positifs. Créez le fichier .claude/security/false-positives.md :

# 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 :

- 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 :

# 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 » et « Le Second Brain dans Claude Code ».

Que ne détecte PAS Claude et pourquoi : les limites en toute transparence#

Anthropic indique clairement ce qui est désactivé par défaut et pourquoi (source : README du dépôt) :

• 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#

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 ?#

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 ».

Une autre possibilité consiste à utiliser les 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, 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#

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#

Pour en savoir plus, consultez la documentation Ailoot.