Réaliser un audit de sécurité avec Claude Code

Ne confiez pas la sécurité à l’IA sans cadre

Claude Code peut accélérer un audit de sécurité. Il peut lire les routes, comparer un pull request, résumer les dépendances, repérer des logs dangereux, lister les variables d’environnement et transformer des habitudes de revue en checklist. C’est utile, car les vrais risques sont souvent répartis entre l’authentification, les autorisations, les tâches de facturation, les webhooks, la CI et les journaux.

L’erreur classique consiste à demander simplement “vérifie la sécurité” et à traiter la réponse comme une preuve. Un audit n’est pas une impression générale. C’est une revue cadrée des actifs, des menaces, des contrôles, des preuves et des risques restants. Claude Code aide à enquêter et à organiser, mais il ne porte pas la décision métier ni le choix de ce qui peut être publié.

Ce guide propose un flux de travail concret pour utiliser Claude Code sans publier de détails exploitables. Il couvre le périmètre, l’inventaire des actifs, le modèle de menace, la revue des dépendances, l’authentification et les sessions, les secrets, la validation d’entrée, les logs et PII, les portes de CI et le reçu de preuves. Pour les références externes, gardez OWASP Top 10, OWASP ASVS, NIST SSDF et la documentation GitHub sur le secret scanning.

Fixer le périmètre d’abord

Le premier livrable n’est pas un correctif. C’est un brief d’audit. Le périmètre indique à Claude Code quoi inspecter, quoi ne pas modifier, quelles commandes sont autorisées et ce qui compte comme terminé. Sans ce cadre, l’IA risque de commenter les fichiers visibles tout en oubliant l’administration, la facturation, les jobs asynchrones, les scripts de déploiement ou les secrets de CI.

Copiez ce modèle avant de demander des constats.

# Security Audit Brief

## Goal
- Find serious issues in authentication, authorization, secrets, input validation, logging, and dependencies before release
- Produce evidence and remaining-risk notes, not just suggested fixes

## Scope
- Repository:
- Branch or PR:
- Feature or workflow:
- Directories Claude Code may inspect:
- Directories Claude Code must not change:
- Commands Claude Code may run:

## Priority areas
- Authentication and session handling
- Authorization and roles
- Input validation and output encoding
- Secrets and environment variables
- Dependencies and licenses
- Logs, PII, and audit events
- CI gates that should block release

## Completion criteria
- Record findings in the risk register
- Include only minimal reproduction context
- Do not include live secrets, customer data, or dangerous exploit instructions
- Record commands, results, skipped areas, and human-review items in the evidence receipt

Ensuite, demandez une cartographie avant toute modification : “Liste les routes, middlewares d’authentification, APIs externes, variables d’environnement, points de log, jobs de CI et fichiers à risque. Ne modifie pas encore le code.” Cette étape donne au reviewer humain l’occasion de repérer les zones oubliées.

Inventaire des actifs et modèle de menace

La sécurité commence par ce que l’on protège. Les actifs peuvent être les données utilisateurs, l’état de facturation, les clés API, l’interface d’administration, les logs d’audit, les fichiers téléversés, les messages de support et les données d’analyse. Un modèle de menace est une petite carte : qui peut entrer, par quel point d’entrée, pour toucher quoi, et quel contrôle doit l’arrêter.

| Asset | Stored in | Entry point | Likely threat | Required control | Owner |
| --- | --- | --- | --- | --- | --- |
| User email address | users table | signup, admin | unauthorized access, log leakage | authorization, PII masking, audit log | backend |
| Billing status | billing table, Stripe | webhook, admin | tampering, duplicate processing | signature verification, idempotency, role checks | backend |
| API keys | env, secret manager | CI, runtime | repository leak, log exposure | secret scanning, rotation, least privilege | platform |
| Admin console | /admin | browser | privilege escalation | MFA, admin role, operation logs | product |

Donnez ce tableau à Claude Code et demandez-lui d’ajouter les limites de confiance et les tests. Une limite de confiance sépare ce que vous contrôlez de ce qui doit rester non fiable. Entrées navigateur, webhooks, CSV importés, Markdown, noms de fichiers et réponses d’APIs tierces doivent être validés avant usage.

Donner des axes de revue précis

La revue des dépendances doit couvrir package.json, lockfiles, images Docker, GitHub Actions, versions de runtime et dépendances transitives. npm audit n’est qu’un signal. Demandez à Claude Code de distinguer le risque atteignable en production du bruit de développement, d’expliquer les breaking changes et de préciser les tests qui prouvent que la mise à jour tient.

La revue auth et session doit couvrir login, logout, reset de mot de passe, MFA, OAuth, flags de cookies, expiration de session, CSRF et autorisation côté serveur. “L’utilisateur est connecté” et “l’utilisateur a le droit d’agir” sont deux questions différentes. Les APIs admin, actions de billing, téléchargements, IDs utilisateur dans les routes et webhooks rejouables sont des zones sensibles.

La revue des secrets doit inclure .env, secrets CI, configurations d’exemple, README, logs, captures d’écran et fixtures de test. Claude Code ne doit jamais afficher de secret réel dans le chat. S’il détecte une valeur suspecte, le rapport doit garder le chemin, le type, la recommandation de rotation et le responsable, avec la valeur masquée. Sur GitHub, vérifiez aussi secret scanning et push protection.

La validation d’entrée consiste à suivre le trajet des données : d’où elles viennent, où elles sont stockées, rendues ou renvoyées. Ne demandez pas de payloads dangereux. Demandez plutôt validation aux frontières, normalisation, échappement, typage et tests. Pour une équipe débutante, suivre le flux de données est plus robuste que réciter des noms de vulnérabilités.

Les logs et PII demandent de rechercher emails, noms, adresses, tokens, cookies, headers d’authentification, identifiants de paiement et texte libre. Un console.log de développement peut devenir un problème de rétention en production. Les logs doivent contenir le minimum utile pour diagnostiquer et auditer, pas des corps de requêtes complets.

Quatre cas d’usage réalistes

Premier cas : audit SaaS avant release. Avant de livrer facturation, invitations, réglages d’organisation ou administration, faites lire à Claude Code le diff du PR, les migrations, routes, webhooks, tests et jobs CI. Le but est un registre de risques pour la réunion de release, pas une promesse générale de sécurité.

Deuxième cas : audit de passation d’un dépôt GitHub. Dans un repo hérité, les risques se cachent souvent dans les scripts de déploiement, secrets CI, noms d’environnements, runbooks manuels et dossiers sans owner. Demandez une checklist de première semaine : clés à faire tourner, documentation à écrire, gates CI manquants et zones nécessitant un responsable humain.

Troisième cas : audit après incident. Après une panne ou une suspicion de fuite, ne corrigez pas seulement la ligne fautive. Demandez à Claude Code de rechercher les motifs similaires, vérifier les PII dans les logs, proposer des tests de non-régression, mettre à jour les gates CI et le runbook. Une communication publique doit expliquer impact et correction sans donner d’instructions exploitables.

Quatrième cas : revue sécurité d’un PR généré par IA. Le code généré peut être propre visuellement tout en oubliant autorisation, logs d’audit, gestion d’erreurs ou tests. Demandez à Claude Code de ne regarder que l’impact sécurité du diff : surface d’attaque, permissions, secrets, données personnelles, dépendances et couverture CI.

Registre de risques et reçu de preuves

Un constat doit être traçable. La sévérité seule ne suffit pas. Le registre doit garder impact, preuve, action recommandée, priorité, état et owner.

| ID | Risk | Impact | Evidence | Recommended action | Priority | Status | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | Missing authorization on admin API | Another user's data may be changed | routes/admin.ts has no role check | Add middleware and regression tests | High | Open | backend |
| SEC-002 | Webhook logs include email | Unnecessary PII retention | logs/webhook-sample.txt | Mask email and reduce retention | Medium | Open | platform |

Le reçu de preuves évite qu’un audit ne reste une conversation impossible à relire.

# Security Audit Evidence Receipt

- Target:
- Date:
- Reviewer:
- Scope provided to Claude Code:
- Commands executed:
- Files or directories inspected:
- High-risk findings:
- Fixed items:
- Skipped or out-of-scope areas:
- Decisions requiring human review:
- Release recommendation:

Checklist de revue PR

Pour les pull requests, gardez une checklist courte dans le prompt. Elle est particulièrement utile avec du code généré par IA, car elle ramène la discussion au risque et aux preuves.

## Security PR Review

- [ ] Scope is clear and no unrelated files are changed
- [ ] Authenticated users cannot access another user's data
- [ ] Admin or billing actions require explicit authorization
- [ ] Inputs are validated at the boundary
- [ ] Outputs are escaped or rendered safely
- [ ] No secrets, tokens, cookies, or PII are printed to logs
- [ ] Dependency changes have a reason and test evidence
- [ ] Errors do not reveal internals
- [ ] CI includes lint, tests, typecheck, and security-relevant checks
- [ ] Risk register and evidence receipt are updated

Checklist de commandes

Les commandes dépendent du stack, mais un projet Node ou TypeScript peut commencer par ceci. Demandez à Claude Code d’expliquer chaque commande avant exécution et de s’arrêter si un échec change le niveau de risque.

git status --short
npm ci
npm audit --audit-level=moderate
npm run lint
npm run typecheck
npm test
rg -n "TODO|FIXME|console\\.log|process\\.env|localStorage|innerHTML|dangerouslySetInnerHTML" src
git diff --check

Les résultats de rg sont des indices, pas des verdicts. process.env peut être correct. innerHTML peut être acceptable s’il est assaini. Demandez à Claude Code de séparer preuve, hypothèse et étape de confirmation.

Échecs fréquents

Le premier échec est le prompt vague. “Vérifie la sécurité” produit souvent une réponse superficielle. Un bon prompt nomme le périmètre, les actifs, la date de release, les commandes autorisées, les flux critiques et le format attendu. Un rapport qui indique clairement “non revu” vaut mieux qu’une conclusion confiante sans preuve.

Le deuxième échec est l’absence d’évidence. Si personne ne sait quelles commandes ont tourné, quels fichiers ont été inspectés et quelles zones ont été exclues, l’audit ne peut pas soutenir une décision de release. Les affirmations de Claude Code doivent être confirmées par CI, tests, diffs, logs et configuration.

Un échec dangereux consiste à publier trop de détails. Ne mettez pas d’URLs réelles, tokens, données clients ou étapes exploitables dans des issues ou articles publics. Le public doit voir l’impact et la correction. Les détails sensibles vont dans un espace restreint.

Ne négligez pas secrets et logs. Une application peut avoir un code raisonnable et fuiter via logs CI, captures de debug, .env d’exemple ou erreurs trop bavardes. Enfin, les changements à haut risque sur auth, paiement, données personnelles ou admin doivent recevoir une revue humaine.

Intégrer l’audit à la CI et à l’équipe

Un audit ponctuel vieillit vite. Ajoutez des gates CI pour lint, typecheck, tests, audit des dépendances, secret scanning, recherche d’APIs dangereuses et règles de logging. Tous les avertissements ne doivent pas bloquer. En pratique, bloquez High, créez des tickets datés pour Medium et regroupez Low en maintenance.

Revoyez aussi les permissions de Claude Code avec le guide des permissions. Lisez aussi gestion des secrets, cas d’échec sécurité et revue de code avec Claude Code. Pour transformer cela en politique de revue, gates CI et brief adapté à votre dépôt, commencez par formation et conseil Claude Code.

Résumé

Claude Code est utile en audit quand l’humain construit le système autour : périmètre, actifs, modèle de menace, axes de revue, registre de risques, reçu de preuves, CI et validation humaine des décisions critiques. Sans cette structure, le rapport peut être agréable à lire sans expliquer le risque réel.

Quand Masa a appliqué ce flux aux revues pré-release de ClaudeCodeLab, les meilleurs gains sont venus du registre de risques et du reçu de preuves. Faire inventorier routes, logs, variables d’environnement et CI par Claude Code avant la revue humaine a rendu les questions ouvertes beaucoup plus visibles. Le résultat n’était pas une garantie de sécurité parfaite, mais une décision de release plus claire.