Tutoriel complet de Security Audit Skill : faire de Claude Code un auditeur de sécurité IA, de l’analyse du code au rapport de vulnérabilité

Claude Code signale des risques, mais il reste difficile de savoir lesquels sont prouvés et lesquels sont de simples pistes à vérifier.

La solution la plus utile est de configurer Security Audit Skill comme un guide de travail réutilisable : il peut conduire Claude Code à examiner le code, à confronter ses constats aux outils autorisés et à préparer un rapport, mais il ne certifie pas automatiquement la sécurité du logiciel.

Ce guide s’adresse aux développeurs qui veulent standardiser des revues récurrentes, aux spécialistes de la sécurité qui doivent produire des constats vérifiables et aux responsables qui évaluent l’usage d’un agent IA dans un processus d’audit. Si le dépôt n’est pas autorisé pour l’analyse, ou si aucun humain ne peut examiner les alertes importantes, ce processus ne doit pas être considéré comme un audit complet.

Définir ce que l’agent peut réellement auditer

Security Audit Skill est une consigne spécialisée qui décrit une méthode et des règles de travail. Elle ne remplace ni les mécanismes de permission de Claude Code, ni les outils d’analyse configurés, ni l’expertise nécessaire pour interpréter une alerte. Les instructions officielles sur la création et l’usage des Skills permettent de vérifier le format et les règles de configuration applicables au moment de la mise en place.

Les rôles doivent rester distincts :

• Security Audit Skill fixe le périmètre, l’ordre des vérifications, les exigences de preuve et le format du compte rendu.
• Claude Code examine les fichiers auxquels il a accès, suit les instructions et peut résumer les éléments trouvés. Ses conclusions dépendent du contexte disponible et ne constituent pas une garantie de détection.
• Les outils d’analyse autorisés produisent leurs propres résultats selon leur périmètre et leurs limites. Le Skill peut demander d’examiner ces résultats, mais ne transforme pas un outil partiel en couverture exhaustive.
• La personne chargée de la revue vérifie les emplacements, la circulation des données, l’exposition réelle et la gravité avant de confirmer ou de classer un problème.

Cette séparation est importante parce qu’un texte convaincant n’est pas une preuve. Un message généré par l’agent qui affirme qu’une entrée est dangereuse ne confirme pas, à lui seul, qu’elle peut atteindre une opération sensible sans validation.

L’OWASP Top 10 de l’édition 2021 présente dix catégories de risques pour les applications Web. C’est un repère utile pour choisir des familles de contrôles, et non une preuve que toute application a été testée contre tous les risques. De même, le cadre NIST SP 800-218 organise les pratiques de développement logiciel sécurisé en quatre groupes de haut niveau. Ces références donnent des axes de travail ; elles ne prouvent pas qu’un dépôt particulier est conforme ou exempt de défauts.

Un constat doit rester « à vérifier » tant que l’équipe n’a pas relié le code concerné à un scénario d’impact et confirmé les conditions d’exploitation. Ne faites pas passer une hypothèse pour une vulnérabilité établie.

Avant la configuration, circonscrire le dépôt et les risques

Un audit utile commence par une autorisation explicite. Précisez le dépôt concerné, la branche ou la révision examinée, les répertoires inclus et ceux qui sont exclus. Indiquez également si l’exécution de tests ou de commandes est permise. Un accès en lecture ne signifie pas automatiquement que l’agent peut lancer n’importe quelle commande, modifier des fichiers ou consulter des secrets.

Le périmètre doit également décrire le projet : langage, composants, points d’entrée, traitements sensibles et dépendances pertinentes. Par exemple, pour un service qui reçoit des données de formulaire et construit des requêtes, demandez l’examen de la validation des entrées, du passage des données vers les requêtes et des contrôles d’accès. Évitez la consigne vague « trouve toutes les failles » : elle ne définit ni les fichiers à analyser, ni les familles de risques, ni les critères de confirmation.

Un périmètre trop large a des conséquences concrètes. L’agent peut consacrer son attention à des fichiers générés ou à des dépendances vendoriées, alors que le chemin de données sensible n’est pas décrit. À l’inverse, un contexte insuffisant peut conduire à interpréter comme exposé un code réservé à un environnement de test, ou à ne pas comprendre qu’une vérification intervient dans une autre couche de l’application.

Avant de lancer une session, contrôlez les autorisations dans les réglages du projet et dans les permissions disponibles. La documentation officielle des permissions de Claude Code explique que les permissions déterminent quelles actions sont permises, refusées ou soumises à validation. Les réglages officiels précisent où ces paramètres peuvent être configurés. Le Skill ne doit pas être utilisé comme un moyen de contourner ces règles.

Pour cadrer le travail, un fichier de consignes peut demander à l’agent de :

• ne lire que le dépôt autorisé et les chemins explicitement inclus ;
• ne pas afficher ni recopier les secrets, jetons ou données personnelles ;
• ne pas modifier le code et ne pas lancer de commande sans autorisation ;
• distinguer une observation du code, une alerte d’outil et une conclusion confirmée ;
• citer un chemin, une fonction ou un extrait minimal pour chaque constat ;
• signaler les zones non examinées plutôt que de les présenter comme sûres.

Comment configurer Security Audit Skill pour examiner le code ?

Dans la documentation officielle, un Skill repose sur un fichier SKILL.md placé dans un répertoire de Skill ; ses métadonnées et ses instructions définissent son nom, sa description et les consignes à suivre. Vérifiez la documentation actuelle des Skills avant de déployer une configuration, car le format et les modalités d’usage doivent correspondre à la version effectivement installée.

Voici une structure de départ à adapter au dépôt autorisé. La formulation est volontairement prudente : elle demande une analyse et des preuves, sans promettre une couverture complète.

---
name: security-audit
description: Examine le code du dépôt autorisé et prépare des constats de sécurité vérifiables.
---

# Mission
Analyse uniquement les chemins explicitement autorisés pour cette session.
Ne modifie aucun fichier et n'exécute aucune commande sans permission accordée.

# Contexte requis
Avant l'analyse, demande ou relève :
- le dépôt et la révision examinés ;
- les répertoires inclus et exclus ;
- le langage et les composants concernés ;
- les familles de risques prioritaires ;
- les outils de contrôle approuvés et leurs résultats disponibles.

# Méthode
- Repère les points d'entrée et les traitements sensibles.
- Suis les données pertinentes entre leur source et leur usage.
- Consulte les résultats des outils autorisés sans les traiter comme une preuve suffisante.
- Pour chaque alerte, indique les éléments qui la confirment et ceux qui restent inconnus.
- Ne déclare pas une vulnérabilité confirmée sans validation des conditions et de l'impact.

# Sortie
Pour chaque constat : type de risque, emplacement, preuve minimale,
chemin de données, impact plausible, proposition de correction,
état de validation et limites de l'analyse.

Le Skill doit fournir une séquence que l’équipe peut suivre, et non une liste illimitée de commandes. Si un outil d’analyse statique est déjà approuvé pour le projet, indiquez son nom et le moyen autorisé de consulter sa sortie. Dans le cas contraire, demandez à Claude Code de relever cette absence au lieu d’inventer une commande ou de prétendre avoir effectué un contrôle.

La configuration des permissions reste indépendante du texte du Skill. Une commande peut nécessiter une autorisation distincte ; une instruction qui dit « lance l’analyse » ne donne pas à l’agent le droit de l’exécuter. La documentation officielle de sécurité de Claude Code doit aussi être consultée pour tenir compte des précautions applicables à l’environnement et aux données. Pour une équipe, il est préférable de conserver les consignes dans le dépôt autorisé, de les soumettre à revue et de consigner les changements de périmètre plutôt que de laisser des consignes personnelles invisibles modifier la procédure.

Lancer une analyse contrôlée et examiner les premières alertes

Voici un déroulement reproductible pour un dépôt de démonstration détenu par l’équipe ou explicitement autorisé. Il ne nécessite ni cible externe, ni tentative d’exploitation. Avant de commencer, choisissez la révision à examiner et vérifiez que les fichiers sensibles ou secrets ne seront pas incorporés aux sorties partagées.

Commencez par demander à Claude Code de reformuler le périmètre : dépôt, chemins inclus, exclusions, risques prioritaires, commandes permises et limites connues. Corrigez toute interprétation erronée avant l’analyse. Cette étape permet notamment de détecter une confusion entre l’application et ses dépendances, ou entre le code de production et des exemples de test.

Demandez ensuite un inventaire succinct des composants utiles à la revue, sans solliciter un résumé de tout le dépôt. L’agent peut repérer les points d’entrée, les fonctions qui traitent des entrées non fiables et les opérations qui accèdent à des données ou à des privilèges sensibles. Chaque piste doit être rattachée à un chemin réellement consulté.

Si une commande d’analyse approuvée est disponible et que les permissions l’autorisent, exécutez-la selon la procédure du projet ou demandez à Claude Code d’en examiner le résultat déjà produit. L’agent doit indiquer quel résultat il a consulté, ce que l’outil a effectivement signalé et ce qu’il n’a pas contrôlé. Les capacités d’un outil varient selon le langage, la configuration et le type d’analyse ; une absence d’alerte ne signifie donc pas que le code est sûr.

Examinez ensuite les constats un par un. Prenons un exemple pédagogique : une chaîne SQL semble être construite en incorporant une adresse électronique fournie par une requête. Le fragment justifie une vérification, mais ne suffit pas encore à confirmer une injection. Il faut repérer la source de l’entrée, suivre son passage jusqu’à la requête, examiner si le pilote ou une couche intermédiaire utilise des paramètres, et vérifier si un contrôle intervient avant l’usage. L’explication de CWE sur la distinction entre faiblesse et vulnérabilité aide à ne pas confondre un défaut de code potentiel avec une vulnérabilité démontrée dans son contexte.

Classez les résultats sans surinterprétation :

• Confirmé : le code et les conditions observables établissent le chemin concerné, et une revue humaine valide le risque et son impact.
• À vérifier : un indice existe, mais une condition, une protection intermédiaire ou le contexte d’exécution reste inconnu.
• Non confirmé ou faux positif : les éléments vérifiés ne soutiennent pas l’alerte, par exemple parce que le chemin est inatteignable dans le périmètre examiné ou que le contrôle pertinent est présent.

Conservez également les limites : fichiers ignorés, outil indisponible, résultats incomplets, contexte manquant ou hypothèse non vérifiée. L’objectif n’est pas de produire le plus grand nombre d’alertes, mais de fournir des éléments qu’une autre personne peut retrouver et contrôler.

Transformer les constats en rapport de vulnérabilité vérifiable

Un compte rendu utile sépare les faits observés de leur interprétation. Pour chaque problème, consignez le type de faiblesse, le chemin et l’emplacement concernés, la preuve minimale, le parcours des données lorsque cela s’applique, l’impact plausible, la correction proposée et l’état de validation. Ajoutez la révision examinée et le périmètre retenu afin que le rapport reste compréhensible après une modification du dépôt.

Une note brute telle que « possible injection dans la requête » est trop ambiguë pour guider une correction. Une entrée de rapport plus exploitable peut prendre cette forme :

État : à vérifier
Type : construction potentiellement dangereuse d'une requête
Emplacement : chemin/vers/le/fichier, fonction concernée
Observation : une valeur issue d'une entrée semble participer à la requête
Éléments manquants : confirmation du traitement par le pilote et des protections en amont
Impact plausible : dépend du chemin réellement atteignable et des données concernées
Correction à examiner : utiliser une requête paramétrée adaptée au pilote
Vérification : faire relire le flux de données et retester après correction
Limites : résultat d'analyse automatique non suffisant pour conclure

Cette entrée ne déclare pas une vulnérabilité confirmée : elle décrit précisément pourquoi le signal doit être examiné. Si la revue établit ensuite que l’entrée contrôlable atteint une requête sans paramétrage ni protection pertinente, l’état et l’impact peuvent être réévalués, avec une preuve associée à l’emplacement correspondant. Si le pilote paramètre déjà les données ou si le chemin n’est pas atteignable dans le contexte étudié, le rapport doit consigner ce motif de déclassement.

Évitez de reproduire des secrets, des données personnelles ou de longs extraits de code dans le rapport. Une référence à un fichier, une fonction et une courte preuve suffit souvent à permettre la vérification. Lorsque l’impact dépend d’une configuration que l’équipe n’a pas examinée, indiquez explicitement cette dépendance plutôt que d’attribuer une gravité définitive.

La taxonomie OWASP Top 10 peut aider à formuler une famille de risques pour les applications Web, tandis que les définitions de CWE aident à distinguer une faiblesse de sa conséquence dans une application donnée. Il faut éviter d’annoncer une correspondance certaine avec une catégorie ou une faiblesse si les éléments disponibles ne la justifient pas. Le rapport gagne en fiabilité lorsqu’il explique aussi ce qui n’a pas été vérifié.

Vérifier les limites avant de clôturer l’audit

Avant de diffuser le rapport, appliquez cette liste à l’analyse et à chaque constat important :

• [ ] L’autorisation couvre le dépôt, la révision et les chemins examinés.
• [ ] Les exclusions et les zones non analysées sont mentionnées sans être présentées comme sûres.
• [ ] Aucune commande ni modification n’a dépassé les permissions accordées.
• [ ] Les secrets et les données personnelles sont absents des sorties partagées, sauf nécessité autorisée et traitement conforme aux règles de l’équipe.
• [ ] Chaque alerte importante renvoie à un emplacement et à des éléments vérifiables dans le code ou dans le résultat d’un outil autorisé.
• [ ] Les états « confirmé », « à vérifier » et « non confirmé » sont distincts et justifiés.
• [ ] Les limites de l’outil et du contexte sont indiquées, notamment les langages ou chemins non couverts.
• [ ] Une personne compétente a examiné les constats à fort impact et les hypothèses qui conditionnent leur gravité.
• [ ] Les corrections proposées sont relues, puis les constats concernés sont retestés après modification.

La documentation des pratiques de développement sécurisé du NIST rappelle que la sécurité s’inscrit dans un processus de développement, plutôt que dans une seule passe d’analyse. Dans un flux d’équipe, le rapport de l’agent est donc un élément de revue : la décision de corriger, d’accepter un risque ou de demander une expertise supplémentaire doit rester traçable.

Faites intervenir un spécialiste lorsque le risque dépend d’une architecture que le dépôt ne révèle pas, que l’alerte concerne l’accès à des données sensibles, ou que plusieurs services et frontières de confiance sont impliqués. Une analyse automatisée est également insuffisante si des composants critiques n’ont pas été couverts, si les résultats d’outils se contredisent ou si l’équipe ne peut pas expliquer pourquoi une alerte a été écartée. La sécurité de Claude Code et celle du processus d’analyse doivent elles-mêmes être examinées selon les consignes officielles de sécurité.

Choisir un environnement adapté au travail d’audit

Un poste local est souvent le choix le plus simple lorsque le dépôt, les outils et les autorisations sont déjà gérés par l’équipe. En revanche, réserver une machine personnelle à des analyses longues peut la rendre indisponible pour d’autres tâches ; reproduire manuellement le même environnement sur plusieurs postes peut aussi entraîner des différences de versions et de réglages. Ces difficultés ne justifient pas, à elles seules, de déplacer du code sensible : la politique de l’organisation, la gestion des accès et les règles de conservation des données priment.

Un environnement distant peut convenir si l’équipe doit séparer le travail d’audit de son poste habituel, conserver un environnement de développement accessible à distance ou exécuter des outils compatibles avec macOS. Il ne remplace ni les permissions minimales, ni l’autorisation du dépôt, ni la validation humaine. Avant de retenir cette option, vérifiez les conditions réelles de l’environnement et les modalités applicables : la présentation de Zutcloud et son centre d’aide permettent de consulter les informations disponibles sans présumer de caractéristiques non vérifiées.

Pour un essai ponctuel, lancez d’abord Security Audit Skill sur un dépôt autorisé et limité, puis relisez chaque constat selon la liste ci-dessus. Si le poste local est déjà adapté et que les analyses ne perturbent pas le travail, une location n’apporte pas nécessairement d’avantage. Si les analyses mobilisent le poste habituel, qu’un environnement distant est réellement nécessaire et que les outils sont compatibles avec macOS, examinez les informations du service Mac distant de Zutcloud avant de choisir. La décision doit découler du besoin d’exploitation et des exigences de sécurité, pas de l’idée qu’un environnement distant rendrait automatiquement l’audit plus fiable.