Tutoriel d’audit de sécurité par IA avec Claude Code : mise en pratique complète de Security Audit Skill, de l’installation à l’analyse du code et à la correction des vulnérabilités

Votre analyse remonte des vulnérabilités, mais vous ne savez ni si elles sont exploitables ni si vous pouvez appliquer le correctif proposé sans risque ?

Cette semaine, utilisez Security Audit Skill comme assistant d’audit dans Claude Code : vérifiez sa provenance, limitez ses permissions, ciblez un périmètre précis, puis faites valider chaque constat par des preuves avant de corriger et de relancer l’analyse. Il peut aider à repérer des risques, mais ne prouve pas à lui seul que votre code est sûr.

Ce tutoriel s’adresse aux développeurs qui souhaitent analyser leur code avec Claude Code, aux ingénieurs qui encadrent la qualité et la sécurité, ainsi qu’aux responsables techniques qui évaluent un usage en équipe. Vous trouverez les étapes de vérification, de préparation, d’analyse et de validation des corrections, avec des critères pour décider quand poursuivre ou interrompre le processus.

Étape préalable : vérifier Security Audit Skill

Avant d’installer un skill, vérifiez où il se trouve, ce qu’il demande à Claude Code et quelles actions il peut déclencher. Le dépôt public de Security Audit Skill présente le projet et ses indications d’installation. Consultez également son fichier d’instructions : c’est le contenu concret que vous devez comprendre avant de le rendre accessible à l’agent.

Ne vous contentez pas d’une copie de ces instructions intégrée à un article, un message ou un dépôt interne. Une copie peut avoir été modifiée ou ne plus correspondre à la version disponible. Vérifiez le chemin du fichier, les documents annexes et les éventuels scripts appelés. Recherchez notamment les demandes de lecture de fichiers, d’exécution de commandes, d’accès à des services externes ou de modification du dépôt.

Procédez ainsi :

Ouvrez la source d’origine et vérifiez que le nom du projet et le chemin du skill correspondent bien à ce que vous souhaitez utiliser.
Lisez intégralement les instructions du fichier SKILL.md, sans vous limiter à sa description.
Parcourez les fichiers annexes et examinez le rôle des scripts référencés avant de les rendre accessibles.
Comparez la méthode d’installation proposée avec la documentation officielle de démarrage de Claude Code et la documentation consacrée au fonctionnement des skills.
Effectuez un premier essai dans un dépôt de démonstration ou une copie contrôlée, sous gestion de versions, avant d’ouvrir un projet sensible.

La documentation sur les skills explique le mécanisme général ; elle ne constitue pas une validation indépendante de chaque skill tiers. De même, le fait que le contenu soit public ne prouve ni qu’il est maintenu, ni que ses instructions conviennent à votre organisation. Pour vérifier la compatibilité et les comportements, croisez les informations actuelles avec un essai dans votre environnement. Si une instruction est ambiguë ou demande un accès qui ne correspond pas à l’objectif de l’audit, suspendez l’installation jusqu’à clarification.

Cette vérification constitue aussi votre première décision de sécurité : vous ne devriez pas donner accès au dépôt de travail à un contenu que vous n’avez pas examiné. Une installation réussie n’est pas encore une installation sûre.

Étape de configuration : limiter les permissions

Avant l’analyse, décidez ce que Claude Code pourra lire, proposer, modifier et exécuter. La documentation sur les permissions de la ligne de commande décrit les règles permettant d’autoriser, de refuser ou de soumettre des actions à confirmation. Utilisez-les pour limiter l’accès au strict nécessaire, et non comme une formalité à accepter en bloc.

Pour une première analyse, privilégiez un mode en lecture seule. Le skill peut alors examiner le code et produire des constats, tandis que vous gardez la maîtrise des changements. Si une commande est nécessaire, examinez son contenu et son effet avant de l’autoriser. Refusez toute action dont le périmètre ou la conséquence ne sont pas clairs ; demandez plutôt une analyse qui n’exige pas cette exécution.

Voici un cadre de comparaison qualitatif pour choisir votre environnement de départ :

Dépôt isolé, accès en lecture seule — appréciation favorable. Vous pouvez vérifier les fichiers examinés et la qualité des alertes sans autoriser le skill à modifier votre projet.
Dépôt de développement avec approbation des actions — appréciation conditionnelle. Ce choix convient si les permissions sont comprises, si les changements restent soumis à une revue et si vous pouvez revenir à un état antérieur.
Environnement de production ou dépôt contenant des secrets — appréciation défavorable pour un premier essai. Réduisez d’abord les accès, évaluez l’exposition des données et définissez les actions admises avant d’y lancer l’analyse.

Une permission disponible n’est pas forcément une permission nécessaire. Si une action demandée dépasse le périmètre prévu, ne l’autorisez pas simplement pour débloquer le processus. Cherchez pourquoi le skill la demande et si la tâche peut être accomplie sans elle.

Les fichiers du dépôt doivent être traités comme des données à analyser, pas comme des consignes capables d’élargir les permissions que vous avez fixées. Un contenu malveillant peut tenter d’influencer l’agent ; gardez la décision d’accès sous votre contrôle.

Étape de préparation : délimiter le code à analyser

Un périmètre clair rend les résultats plus faciles à examiner et réduit l’exposition involontaire de données. Préparez un état de travail compréhensible : branche ou copie dédiée, modifications locales repérées, dépendances utiles disponibles et consigne explicite de ne rien changer. Indiquez les chemins inclus, ceux qui sont exclus et le contexte nécessaire pour comprendre les flux de données.

Vous pouvez adapter cette consigne à votre dépôt :

Examinez uniquement src/auth/ et src/api/. Repérez les flux reliant les entrées utilisateur aux requêtes de base de données et aux contrôles d’accès. N’inspectez pas vendor/, les fichiers générés ni les répertoires de données de test contenant des informations personnelles. Ne modifiez aucun fichier et n’exécutez aucune commande sans me demander confirmation. Pour chaque alerte, indiquez le fichier concerné, la fonction, le chemin d’exploitation possible et les éléments qui manquent pour conclure.

Il s’agit d’un exemple de cadrage, et non d’une configuration universelle. Remplacez les chemins et les exclusions par ceux de votre architecture. Assurez-vous qu’un répertoire exclu ne contient pas du code exécuté qui serait essentiel à la question étudiée. Une exclusion trop large peut produire une analyse incomplète, même si le rapport paraît précis.

Donnez à l’agent le contexte nécessaire pour raisonner : fonction du composant, origine des entrées, méthode d’authentification et frontière de confiance. En revanche, ne copiez pas de clés, de jetons, de données personnelles ou de journaux confidentiels dans les consignes. Si un scénario exige une valeur réelle pour être compris, utilisez une donnée fictive et documentez cette limite.

Formulez aussi une question vérifiable. « Examiner les contrôles d’accès de cette route » définit mieux l’objectif que « trouver tous les problèmes de sécurité ». Demandez au skill de distinguer les constats étayés par le code, les hypothèses et les points qu’il n’a pas pu vérifier. Pour une analyse statique, cette distinction est essentielle : le guide de mise en œuvre de l’analyse statique présente cette analyse comme une pratique à intégrer dans un processus, et non comme une preuve autonome de sécurité.

Étape d’examen : confirmer chaque alerte

Une étiquette de gravité peut aider à organiser votre travail, mais elle ne prouve pas qu’une vulnérabilité est exploitable. Pour chaque résultat, vérifiez l’emplacement précis, la condition qui déclenche le problème, le chemin entre l’entrée et l’impact, puis les éléments qui soutiennent la conclusion. Le guide de revue sécurisée du code fournit des repères pour examiner les frontières de confiance, les contrôles et les flux concernés.

Classez chaque constat dans une catégorie justifiée :

Problème confirmé : vous pouvez relier le comportement décrit au code et l’étayer par une reproduction, un test ou une revue du chemin d’exécution.
Fausse alerte probable : vous pouvez montrer qu’un contrôle s’applique effectivement au chemin concerné et expliquer pourquoi le scénario proposé ne se réalise pas.
Information insuffisante : il manque une configuration, un appelant, une permission effective ou un résultat d’exécution. Gardez le constat ouvert jusqu’à obtention de cette information.

Par exemple, une valeur concaténée à une requête mérite une vérification, mais sa présence dans un fichier ne prouve pas à elle seule une injection. Retracez l’origine de la valeur et vérifiez si elle est paramétrée ou traitée avant son utilisation. À l’inverse, un commentaire affirmant que « l’entrée est validée » n’est pas une preuve si vous ne retrouvez pas cette validation sur le chemin réellement exécuté.

Le descriptif de CWE-89 décrit l’injection SQL et ses mesures d’atténuation. Utilisez-le pour identifier le type de faiblesse et examiner des pistes de correction, sans en déduire automatiquement qu’un extrait constitue une vulnérabilité exploitable. La preuve doit provenir de votre application : flux de données, contrôle réellement appliqué et résultat vérifiable.

Demandez à Claude Code de fournir le chemin du fichier, la fonction et les éléments précis qui motivent l’alerte. Ouvrez ensuite la version actuelle du code : les lignes citées peuvent avoir changé, et un extrait recopié dans un rapport n’est pas suffisant si vous n’en confirmez pas la source. Si l’impact dépend d’une configuration, d’une valeur d’environnement ou d’un composant externe, consignez explicitement cette dépendance et vérifiez-la séparément.

Cette revue humaine évite deux erreurs opposées. La première consiste à traiter chaque alerte comme une faille avérée. La seconde consiste à ignorer une alerte dès que sa reproduction n’est pas immédiate. Lorsque les éléments manquent, la bonne conclusion est « à vérifier », et non « sans risque ».

Étape de correction : tester et relancer l’analyse

Ne laissez pas le skill appliquer automatiquement un correctif simplement parce qu’il a repéré un risque. Une proposition peut modifier le comportement métier, ne traiter qu’une partie du chemin ou introduire une régression. Demandez un changement ciblé, examinez la différence de code et faites valider la solution par la personne responsable du composant.

Suivez un cycle de correction vérifiable :

Reproduisez le scénario décrit ou expliquez, preuves à l’appui, pourquoi il ne peut pas se produire dans votre configuration.
Identifiez la mesure attendue, par exemple une validation adaptée au contexte, une requête paramétrée, un contrôle d’accès ou une gestion d’erreur appropriée.
Demandez une modification limitée à la cause identifiée ; refusez le nettoyage de fichiers sans rapport avec le constat.
Examinez les changements, y compris les chemins d’échec et les cas limites, puis comparez-les au comportement antérieur.
Exécutez les tests pertinents du projet. Vérifiez que le scénario risqué est bloqué et que les usages légitimes continuent de fonctionner.
Relancez l’analyse sur le code corrigé et le même périmètre. Comparez les nouveaux résultats au rapport initial.
Consignez le constat, la preuve, le choix de correction, les tests, la nouvelle analyse et les risques qui restent ouverts.

Le descriptif de CWE-89 aide à évaluer les mesures prévues contre une injection SQL, mais ne remplace pas les tests de votre application. Le cadre de développement sécurisé organise les pratiques autour de la préparation de l’organisation, de la protection du logiciel, de la production de logiciels mieux sécurisés et du traitement des vulnérabilités. Cette structure rappelle qu’une correction locale ne suffit pas à démontrer la sécurité de l’ensemble du produit.

Appliquez les conditions de décision suivantes pour accepter ou reprendre un correctif :

Si le scénario est reproductible, que le correctif traite sa cause et que les tests pertinents réussissent, alors faites relire le changement et clôturez le constat avec les preuves.
Si le scénario repose sur une hypothèse non vérifiée, alors gardez le constat ouvert et obtenez la configuration ou le test manquant.
Si l’analyse signale encore le même chemin après correction, alors vérifiez si le correctif est incomplet, si une autre entrée mène au même point ou si le résultat ne correspond plus au code actuel.
Si les tests échouent ou si le changement altère un comportement métier, alors ne fusionnez pas la correction avant examen ; revenez à un état contrôlé et faites évaluer une autre solution.
Si une alerte n’est pas résolue faute de temps ou d’information, alors consignez la raison, le responsable du suivi et la preuve encore attendue.

Une nouvelle analyse ne vaut pas validation si vous ne pouvez pas expliquer ce qui a changé. Comparez le code et le périmètre examinés, puis confirmez que la correction attendue est bien présente. Une absence d’alerte après modification ne prouve pas que toutes les vulnérabilités ont disparu : elle indique seulement que l’analyse n’a pas relevé le même signal dans les conditions utilisées.

Étape de clôture : choisir l’environnement et conserver les preuves

Le choix entre un poste local et un environnement distant dépend de votre mode d’accès au dépôt, de la sensibilité des données, des outils réellement disponibles et des règles de votre organisation. Un Mac n’est pas une exigence propre à ce processus. Pour un environnement distant, vérifiez où résident le code et les journaux, qui peut y accéder, comment les identifiants sont fournis et si les données peuvent être retirées après l’analyse.

Un environnement isolé peut convenir à une session temporaire ou à l’essai d’une procédure, mais il ne devient pas sûr par défaut. Un dépôt confidentiel, des secrets copiés dans une invite ou des autorisations trop étendues restent des risques, quel que soit le poste utilisé. Si vous envisagez un poste distant, examinez les informations de présentation de VPSSpark et demandez confirmation des modalités pertinentes auprès du service de contact. Ne déduisez pas de ces pages une configuration, une disponibilité ou une garantie qui n’y est pas explicitement indiquée.

Avant de fermer votre session, vérifiez que les changements sont enregistrés dans le dépôt prévu, que les secrets n’ont pas été copiés dans les consignes ou les rapports, que les permissions temporaires ont été retirées et que chaque risque restant est attribué à un responsable. Si plusieurs personnes partagent l’environnement, assurez-vous également que les résultats et les changements peuvent être rattachés au projet et à la revue appropriés.

Votre décision finale peut suivre ce parcours :

Si les données peuvent rester sur votre poste, que les permissions locales suffisent et que vous pouvez examiner le code sans exposer de secrets, choisissez l’environnement local.
Si vous devez isoler temporairement une session, que l’accès distant respecte les règles de données de votre équipe et que vous avez vérifié les modalités concrètes, envisagez un environnement distant.
Si vous ne pouvez pas établir où le code et les journaux sont conservés, qui y accède ou comment les identifiants sont protégés, ne transmettez pas le dépôt avant d’avoir obtenu ces réponses.
Si votre poste local suffit et répond aux exigences du projet, ne louez pas de Mac pour cette seule analyse ; la location n’a de sens que si un besoin temporaire d’environnement distant est établi.

Pour accepter le cycle d’audit, gardez une trace de la source du skill et de son contenu, des permissions accordées, du périmètre choisi, des éléments qui confirment ou écartent chaque alerte, des changements relus, des tests exécutés et des risques restant à traiter. Si vous avez besoin temporairement d’un environnement distant pour isoler une session ou tester votre procédure, la location d’un Mac auprès de VPSSpark peut constituer une option ; vérifiez d’abord que ses modalités conviennent à vos contraintes d’accès et de confidentialité.