Créez un agent d’analyse de sécurité Claude Code pour l’OWASP

Créez un agent d’analyse de sécurité Claude Code pour l’OWASP

Le scan s’est terminé à 23h47 un jeudi soir, et je suis resté là devant le terminal comme s’il venait d’insulter l’ensemble de ma base de code. Trente-sept vulnérabilités. Neuf critiques. Un score de risque de 245 affiché en haut du rapport dans cette teinte de rouge bien spécifique qui signifie « ne déployez surtout pas ça ». Le plus ironique ? Ce n’était pas le code d’un client. C’était une application de prise de notes délibérément vulnérable que j’avais conçue pour servir de cible de test à l’agent de scan de sécurité de code Claude que j’avais bricolé dans l’après-midi.

Et l’agent a tout détecté. Hachage de mots de passe en MD5. Concaténation naïve de chaînes SQL. Un chemin de contrôle d’accès défaillant où n’importe quel utilisateur authentifié pouvait supprimer les notes d’un autre juste en devinant son ID. Un point d’exécution de code arbitraire que j’avais caché, trois fichiers en profondeur, juste pour voir s’il le trouverait. Il l’a trouvé. En trente secondes.

C’est à ce moment-là que j’ai arrêté de voir ce projet comme une expérimentation de week-end, et ai commencé à me dire que j’aurais dû créer ça il y a six mois.

Je dirige une marque cybersécurité — xCyberSecurity — et une grande partie de mon travail consiste à mener des audits OWASP sur des applications web. L’audit en lui-même est une activité humaine coûteuse. Lire du code, suivre les flux de données, vérifier les versions de dépendances, croiser les CVE, rédiger les rapports avec sévérité et recommandations. C’est un ingénieur senior qui effectue ce travail. Lentement. Précautionneusement. À l’heure facturée.

Un agent Claude Code ne va pas remplacer cet ingénieur. Mais il peut assurer un premier passage. Il peut relever les failles évidentes avant même qu’un humain n’ouvre le fichier. Et, depuis que Claude Code a introduit le modèle Skill + sous-agent, l’ensemble reste modulaire — une brique réutilisable que je peux partager d’un projet à l’autre, chaîner à d’autres agents, ou intégrer dans un hook de pré-commit un mardi après-midi.

Voilà comment je l’ai construit. Et, plus important encore, pourquoi l’architecture a son importance.

Pourquoi un agent monolithique ne fonctionne pas ici

Mon premier réflexe — et sûrement le vôtre également — a été d’écrire un gros prompt système. "Vous êtes un auditeur sécurité. Vérifiez les injections SQL, le contrôle d’accès défaillant, la cryptographie faible, tout l’OWASP Top 10, rédigez un rapport." On le lance. Et on passe à autre chose.

J’ai commencé par cette version. Elle fonctionnait. Plus ou moins. Les rapports étaient incohérents. Certains scans signalaient chaque appel à md5() comme critique ; d’autres les ignoraient. La notation de "sévérité" variait d’une exécution à l’autre — un scan qualifiait une clé API codée en dur de "haute", le suivant de "critique". Pire encore, l’agent n’avait aucune mémoire de ce à quoi devait ressembler une bonne sortie. À chaque appel, c’était de l’improvisation pure.

Le vrai problème était structurel. Je demandais à une seule fenêtre de contexte de contenir quatre éléments à la fois : le référentiel OWASP Top 10, la méthodologie de scan, le format du rapport, et le code à auditer. Beaucoup trop de charge cognitive pour un seul prompt, et Claude — même en version Opus 4.7 — réagit à cette surcharge comme un auditeur humain après sa huitième boisson énergisante : il devient négligent.

Les skills corrigent ça. Les sous-agents aussi. En les combinant, tout s’aligne instantanément.

Si vous souhaitez un aperçu plus global sur la façon dont les skills s’intègrent dans Claude Code, j’ai détaillé tout ça dans mon guide des Skills Claude Code Agent — à lire en parallèle de cet article, car notre scanner est justement une application concrète de ces patterns.

L’architecture : Compétence + Sous-agent

Voici la répartition qui fonctionne.

La Compétence est la couche de connaissance. Elle contient la documentation de référence de l’OWASP Top 10, la méthodologie de scan et le format exact des rapports. Il s’agit d’un dossier avec un fichier SKILL.md et quelques fichiers markdown — un par catégorie OWASP — chargés à la demande. La compétence ne scanne rien directement. C’est un ensemble d’instructions en attente d’exécution.

Le Sous-agent est la couche d’exécution. C’est un sous-agent Claude Code spécialisé, avec son propre prompt système, ses propres accès outil (Read, Glob, Grep, Bash pour les clones gh, Write pour les rapports), et des instructions explicites pour charger la compétence sécurité à l’exécution. Le sous-agent est ce que l’on invoque réellement. La compétence est ce qu’il consulte.

Cette séparation compte pour trois raisons.

Premièrement, séparation des responsabilités. La connaissance est versionnée indépendamment de la logique d’exécution. Lorsque l’OWASP a publié la mise à jour du Top 10 en 2025 — ils ont déplacé SSRF dans Broken Access Control, ajouté Les Défaillances de la chaîne d’approvisionnement logicielle comme nouvelle catégorie principale, et ajouté la Mauvaise gestion des conditions exceptionnelles — j’ai mis à jour deux fichiers markdown dans la compétence. Le sous-agent, lui, n’a pas bougé. Dans l’ancien monde du prompt unique, il aurait fallu réécrire tout le prompt système.

Deuxièmement, partageabilité. La compétence est un dossier. Je peux le zipper, l’envoyer à un collègue, le committer dans un dépôt partagé, ou le déposer dans un registre de compétences d’équipe. Le sous-agent est un simple fichier markdown avec frontmatter. Même approche. N’importe qui dans l’équipe peut cloner les deux, les connecter en cinq minutes, et obtenir exactement les mêmes résultats de scan que moi.

Troisièmement, composabilité. Le sous-agent scanner peut être invoqué directement — @security-scanner audit this repo — ou chaîné depuis un agent coordinateur de plus haut niveau. J’ai un agent principal pour la revue de code ; lorsqu’il rencontre security : dans un message de commit, il délègue au scanner. Ce schéma serait impossible si la sécurité était embarquée dans le prompt de l’agent de revue lui-même. J’ai détaillé ce type de délégation dans mon article sur l’architecture swarm d’agents, et le scanner en est un exemple éclairant.

La suite de cet article est la construction concrète.

Le SKILL.md à Copier

La compétence se trouve dans .claude/skills/security-vulnerability/. Voici le fichier SKILL.md — c’est l’ossature que j’utilise réellement, avec une légère mise au propre :

---
name: security-vulnerability
description: Analysez une base de code ou un dépôt GitHub pour détecter les vulnérabilités listées dans l’OWASP Top 10 de 2025. Utilisez ce skill lorsque l’utilisateur demande un audit de sécurité, une analyse de vulnérabilités, une revue OWASP ou une vérification de sécurité pré-déploiement sur un répertoire local ou une URL GitHub.
---

Vous effectuez un audit de sécurité selon les catégories de l’OWASP Top 10 2025. Suivez exactement le déroulement ci-dessous. Ne sautez aucune étape. N’inventez pas de niveaux de gravité.

Gestion des entrées

Acceptez l’un des deux types d’entrées suivants :

• Un chemin de répertoire local (ex. : /Users/me/projects/app)
• Une URL GitHub (ex. : https://github.com/org/repo)

Si l’entrée est une URL GitHub, clonez le dépôt avec : gh repo clone <org/repo> /tmp/scan- Ensuite, définissez le chemin de travail sur le répertoire cloné.

Flux d'exécution

1. Inventorier la base de code. Identifier les langages, frameworks et fichiers de manifestes de packages (package.json, composer.json, requirements.txt, go.mod, Gemfile, pom.xml).
2. Charger les références par catégorie. Pour chaque catégorie OWASP Top 10 2025, lire le fichier de référence correspondant dans ce dossier de skill :
   • references/A01-broken-access-control.md
   • references/A02-security-misconfiguration.md
   • references/A03-supply-chain-failures.md
   • references/A04-injection.md
   • references/A05-cryptographic-failures.md
   • references/A06-insecure-design.md
   • references/A07-auth-failures.md
   • references/A08-data-integrity-failures.md
   • references/A09-logging-alerting-failures.md
   • references/A10-exceptional-conditions.md
3. Analyser par catégorie. Pour chaque catégorie, utiliser Grep et Read sur la base de code en se basant sur les motifs documentés dans le fichier de référence de la catégorie. Consigner chaque résultat avec le chemin du fichier, le numéro de ligne, un extrait de code, et la catégorie.
4. Vérifier les dépendances. Pour chaque manifeste de package, extraire les versions déclarées. Signaler les packages associés à des CVE connues en s’appuyant sur OSV.dev ou la GitHub Advisory Database. Ne fabriquez pas d’identifiants CVE. Si la vérification n’est pas possible dans l’environnement actuel, consigner le package et la version sous « dépendances non vérifiées » au lieu d’inventer un verdict.
5. Évaluer et classifier. Attribuer à chaque résultat un niveau de gravité : critique, élevé, moyen ou faible. Utiliser le barème disponible dans references/severity-rubric.md. Calculer un score de risque global : (critique × 10) + (élevé × 5) + (moyen × 2) + (faible × 1).
6. Rédiger le rapport. Sauvegarder dans audit/YYYY-MM-DD/report.md par rapport à la cible scannée. Utiliser le format de rapport ci-dessous.

Format du rapport

Le rapport doit contenir, dans cet ordre :

1. Résumé — cible, date du scan, nombre total de vulnérabilités par niveau de gravité, score de risque global, verdict réussite/échec.
2. Résultats par catégorie — une section par catégorie OWASP ayant des découvertes. Chaque résultat précise : gravité, fichier:ligne, extrait, impact, suggestion de correction.
3. Risques liés aux dépendances — paquets identifiés comme vulnérables, avec références CVE et chemins de mise à jour.
4. Dépendances non vérifiées — paquets signalés mais non confirmés.
5. Priorité des remédiations — une liste ordonnée des dix principaux correctifs par gravité et effort requis.

Règles strictes

• Ne jamais inventer d’ID CVE, de niveaux de gravité ou de correctifs dont vous n’êtes pas certain. Signalez explicitement toute incertitude.
• Ne jamais appliquer automatiquement des correctifs. Le sous-agent peut proposer des patchs dans un fichier séparé, mais la modification du code source requiert l’approbation explicite d’un humain.
• Si un fichier dépasse 2000 lignes, lisez-le par segments. Ne le sautez pas.
• Chaque résultat doit citer un fichier et une plage de lignes précise.

C’est tout. Voilà le cœur du “skill brain”. Chaque fichier de référence sous `references/` est un document ciblé de 200 à 400 lignes : définition, motifs courants à rechercher (grep), exemples spécifiques à un langage, et grille de gravité pour cette catégorie. Vous pouvez rédiger ces fichiers de référence en une après-midi si vous avez déjà travaillé en sécurité.

## Le sous-agent qui l’utilise

Le sous-agent se trouve à l’emplacement `.claude/agents/security-scanner.md`. Voici le frontmatter et l'invite système — à nouveau, il s’agit de la version exacte que j’utilise :

```markdown
---
name: security-scanner
description: Auditez un répertoire local ou un dépôt GitHub selon l’OWASP Top 10 2025. Utilisez proactivement dès que l’utilisateur évoque un audit de sécurité, une recherche de vulnérabilités, un test d’intrusion, une vérification pré-déploiement ou un contrôle OWASP.
model: opus
tools: Read, Glob, Grep, Bash, Write
---

Vous êtes un ingénieur sécurité applicative sénior. Votre mission est de mener un audit approfondi du Top 10 OWASP 2025 sur une base de code cible et de produire un rapport exploitable par un examinateur humain.

Procédure lors de l’activation :

1. Confirmez la cible du scan auprès de l’utilisateur en cas d’ambiguïté (chemin local vs URL GitHub).
2. Chargez la compétence `security-vulnerability`. Suivez exactement son déroulé d’exécution.
3. Lancez l’analyse. Soyez méthodique, pas inventif. La couverture prime sur la rapidité.
4. Écrivez le rapport dans `audit/YYYY-MM-DD/report.md` et affichez le résumé dans la discussion.
5. Une fois le rapport sauvegardé, proposez — sans les exécuter — des corrections automatiques pour les failles détectées qui sont mécaniquement sûres (par exemple remplacer `md5()` par `password_hash()`, paramétrer une requête SQL). Attendez une validation explicite avant toute modification de fichier source.

Règles de fonctionnement :

- Vous ne faites pas de pentest sur des systèmes en production. Analyse statique uniquement.
- Vous ne devinez pas. Si une découverte est incertaine, marquez-la comme telle dans le rapport.
- Vous ne supprimez ni ne déplacez aucun fichier.
- Vous journalisez chaque appel d’outil. Tenez la piste d’audit dans `audit/YYYY-MM-DD/trail.log`.

Deux fichiers. C’est l’ensemble du scanner.

Ce qui s’est passé quand je l’ai exécuté

J’ai construit une application de prise de notes volontairement vulnérable comme cible de test. Un stack proche de Laravel, SQLite, quelques routes, authentification utilisateur, CRUD de notes. J’y ai intentionnellement dissimulé six catégories de vulnérabilités et en ai ajouté quelques autres que j’avais oubliées avoir codées.

Le scan a pris environ 90 secondes sur une base de code de 4 000 lignes. Voici le résumé généré :

• Constats total : 37
• Critiques : 9
• Hauts : 15
• Moyens : 12
• Faibles : 1
• Score de risque : 245 (critique)

Les constats critiques couvraient A01 Contrôle d’accès défaillant (deux routes sans vérification de propriété — tout utilisateur authentifié pouvait modifier ou supprimer n’importe quelle note en devinant son ID), A04 Injection (trois cas de concaténation de chaînes brutes dans des requêtes SQL), A05 Défaillances cryptographiques (hachage de mots de passe en MD5 et une clé APP_KEY codée en dur dans un .env.example commité), et A06 Conception non sécurisée (un endpoint admin acceptant un paramètre cmd qui était transmis tel quel dans un appel d’exécution shell).

Le rapport détaillait tout cela : chemins des fichiers, numéros de lignes, extraits exacts, et une proposition de correction pour chaque constat. Pour les cas d’injection SQL, il proposait une réécriture des requêtes avec requêtage paramétré directement dans l’extrait. Pour le hachage MD5, il pointait le Hash::make() de Laravel et indiquait la procédure de migration pour les mots de passe existants.

Était-ce parfait ? Non. Il a signalé une instruction de logging affichant un email utilisateur comme un problème A09, ce qui peut se défendre mais paraissait excessif — dans la plupart des juridictions, ce n’est pas une vulnérabilité. Il a également manqué une condition de compétition subtile sur l’endpoint de partage de notes qu’un reviewer humain aurait repérée en trente secondes. L’analyse statique par motifs ne raisonne pas sur la concurrence, et aucun prompt ne corrigera cela.

Mais les failles détectées l’ont été proprement. Et j’ai eu un rapport horodaté dans audit/2026-04-18/ que je pouvais envoyer à un client.

Intégration dans un flux Pre-Commit ou CI

Le sous-agent est utile seul. Il l’est encore plus une fois automatisé.

Pour le pre-commit, j’utilise un hook Git qui exécute Claude Code en mode headless uniquement sur les fichiers mis en attente de commit. Il charge le sous-agent de scan, limite l’analyse aux chemins modifiés, et interrompt le commit si de nouvelles détections critiques ou majeures apparaissent, absentes du scan précédent. Le mot-clé ici est « nouvelles » — lancer une analyse OWASP complète à chaque commit serait absurde. Un scan différentiel par rapport à la dernière validation réussie est le bon compromis.

Pour l’intégration continue, même principe, autre habillage. Une GitHub Action s’exécute pour chaque pull request : elle clone la branche du PR dans un répertoire temporaire, lance le scanner, et publie le résumé en commentaire du PR, avec le rapport complet archivé comme artefact de build. Si le score de risque dépasse un seuil prédéfini par rapport à la branche de base, le contrôle échoue. Le propriétaire de l’équipe peut passer outre en ajoutant un label approuvé. Cela a déjà permis d’identifier deux évolutions de dépendance qui introduisaient indirectement des packages vulnérables, avant qu’elles n’atteignent la branche principale.

Aucune de ces tâches n’incombe directement au scanner : il s’agit de l’orchestration autour de l’outil. Mais leur intégration devient triviale dès lors que la skill et le sous-agent existent, puisque le scanner lit un chemin et écrit un rapport. Tout le reste n’est que de la tuyauterie.

Là où ça pose vraiment problème

Je ne vais pas prétendre que cela remplace un pentesteur humain, donc soyons précis sur les limites.

Faux positifs. Le scanner signale excessivement certains motifs. Chaque appel à md5() est signalé, même s’il est utilisé à des fins non sécuritaires comme l’empreinte de contenu. Chaque appel à risque apparent dans un fichier de test est signalé. On apprend à faire le tri, mais si vous devez remettre le rapport à un client non technique, il faudra faire ce tri vous-même.

Aucune analyse à l’exécution. L’analyse statique voit ce que dit le code, pas ce qu’il se passe à l’exécution. Conditions de concurrence, attaques par temporisation, failles de logique métier qui n’apparaissent que lors d’une séquence spécifique d’appels d’API — le scanner ne les détecte pas. Un pentesteur, si. C’est une lacune qui ne peut pas être comblée par un outil.

L’intelligence sur les dépendances ne vaut que la qualité du flux de données. Le scanner vérifie via OSV.dev et GitHub Advisories. Si un package a un CVE publié, parfait. Si une vulnérabilité a été signalée il y a trois jours mais n’est pas encore dans une base de données publique, le scanner passera à côté. Les zero-days restent un problème purement humain.

La correction automatique est un piège. Voilà le point sur lequel j’insiste le plus. Le sous-agent peut proposer des corrections. Il ne doit jamais les appliquer sans relecture. Je le sais, car la première version de l’agent appliquait effectivement des corrections, et il a joyeusement remplacé un appel à md5() dans un ancien processus de vérification de mot de passe, sans effectuer de migration des mots de passe. Le changement a cassé la connexion pour tous les utilisateurs existants en préproduction. Appliquer des corrections statiques sans prise en compte de la migration peut transformer une détection "moyenne" en panne critique. Impératif : un humain reste dans la boucle.

Sécurité des compétences elles-mêmes. Enfin, le dernier point — et celui-ci m’a fait réfléchir, après avoir découvert les récentes recherches de Repello sur la sécurité des compétences — est que ces "skills" sont un contexte exécutable. Toute compétence que vous installez peut lire votre système de fichiers et exécuter des commandes shell. Un skill malveillant déguisé en scanner de sécurité représente un vrai risque. J’écris mes propres skills, j’audite systématiquement chaque skill importé, et je garde la frontière de confiance très étroite. Vous devriez en faire autant.

La partie que la plupart des gens oublient

Ce que je me surprends à répéter quand d'autres développeurs me posent des questions sur ce pattern, c'est que le scanner n'est pas la partie précieuse. Le scanner, c'est une semaine de travail. N'importe quel ingénieur compétent avec Claude Code et un après-midi peut en construire un.

La vraie valeur réside dans la discipline imposée par la séparation Skill + sous-agent. Lorsque vous écrivez la compétence, vous formalisez ce à quoi ressemble réellement un bon audit de sécurité — les catégories, les patterns, la grille de sévérité, le format du rapport. Ce document, qui se trouve dans .claude/skills/security-vulnerability/, devient un savoir institutionnel qui n'existait pas auparavant. Il a plus de valeur que l’agent lui-même. Car l’année prochaine, quand l’OWASP publiera le Top 10 2028 et que la moitié des catégories changeront de nouveau, il vous suffit de mettre à jour les fichiers de référence. L’agent continue de fonctionner. La connaissance est versionnée, partageable, et n’est plus enfermée dans la tête de quelqu’un.

C’est ça, la vraie leçon de ce projet. Ce n’est pas "J’ai automatisé l’OWASP." La leçon, c’est que des agents modulaires vous obligent à expliciter votre savoir, et que la connaissance explicite se capitalise.

Choisissez un de vos dépôts ce soir. Pas celui du client. L’un des vôtres. Lancez une analyse. Regardez les résultats. Vous en apprendrez plus sur votre propre code en quatre-vingt-dix secondes qu’au cours des six derniers mois de développement.

Foire aux questions

Claude Code peut-il analyser un dépôt GitHub privé ?

Oui, tant que l’interface CLI gh utilisée sur la machine où tourne Claude Code est authentifiée avec les accès nécessaires à ce dépôt. Le scanner utilise en interne la commande gh repo clone, il hérite donc des permissions accordées lors de votre gh auth login. Pour les dépôts d’organisation, vérifiez que votre jeton possède bien le scope repo.

Le scanner remplace-t-il des outils comme Snyk ou Semgrep ?

Non. Il les complète. Snyk et Semgrep reposent sur des ensembles de règles définies et des bases de vulnérabilités plus expertes que n’importe quel prompt LLM. Le scanner Claude Code ajoute de la capacité de raisonnement — il peut retracer les flux de données et détecter des problèmes contextuels que les règles statiques ratent. Utilisez les deux. Le scanner relève les problèmes de conception ; Snyk identifie plus vite les CVE connus.

Combien coûte un scan OWASP de cette façon ?

Sur Opus 4.7, un scan complet sur une base de code de 4 000 lignes avec la configuration Skill + sous-agent me coûte quelques dollars d’API par exécution. Les scans delta sur des fichiers indexés dans un hook pre-commit reviennent bien moins chers. Si vous disposez d’un abonnement Claude Code avec usage inclus, la plupart des analyses quotidiennes rentrent dans ce budget.

Puis-je partager la skill avec mon équipe sans partager mon compte Claude ?

Oui. La skill est simplement un dossier de fichiers markdown. Versionnez .claude/skills/security-vulnerability/ dans votre dépôt de projet ou dans un dépôt mutualisé de skills. Chaque membre de l’équipe ayant Claude Code la chargera automatiquement depuis son propre compte. Même principe pour le fichier de sous-agent sous .claude/agents/.

Le scanner doit-il appliquer automatiquement les correctifs ?

Non, et je dirais même jamais. Proposez les correctifs, écrivez-les dans un fichier de patch séparé, exigez toujours une validation humaine avant toute modification des sources. J’ai moi-même cassé un environnement de staging en faisant confiance à l’agent pour appliquer un “simple” remplacement crypto. Sans problème à part, catastrophique combiné au reste du flux d’auth. Gardez l’humain dans la boucle.

Travaillons ensemble

Vous souhaitez développer des systèmes d’IA, automatiser des workflows ou faire évoluer votre infrastructure technique ? Je serais ravi de vous accompagner.

• Fiverr (développements et intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions pour entreprises) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io