Cloudflare security-audit : prendre en main la skill d’audit de sécurité pour agents IA

Cloudflare a récemment publié une skill open source nommée security-audit conçue pour mener un véritable audit de sécurité de votre code source, avec une méthode, des preuves et un rapport exploitable. En voici une présentation associée à une prise en main.

La skill security-audit publiée par Cloudflare s'adresse aux équipes de développement et aux équipes sécurité qui veulent passer en revue une application avant sa mise en production, mais aussi à tous ceux qui maintiennent des outils, des extensions ou encore des projets open source ! Autrement dit, à tous ceux qui codent mais qui n'ont pas de pentester sous la main.

Dans cet article, je vous propose de découvrir cette skill, puis de l'installer avec le Skills CLI (npx skills) pour Claude Code, en global ou par projet. Par la suite, nous verrons comment la prendre en main sur une application volontairement vulnérable, comment lire les résultats et quelles sont ses limites.

La skill security-audit de Cloudflare s'installe avec le Skills CLI de Vercel Labs, qui nécessite Node.js 22.20 ou une version ultérieure. Pour la rendre disponible dans tous vos projets Claude Code, exécutez :

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit -a claude-code -g

La skill est alors copiée dans ~/.claude/skills/security-audit/. Lancez ensuite Claude Code dans le dossier du code à analyser et demandez un audit de sécurité, ou invoquez directement /security-audit. Sans l'option -g, l'installation se limite au projet courant.

Qu'est-ce que la skill security-audit de Cloudflare ?

Qu'est-ce qu'une skill pour agent IA ?

Une skill (ou « Agent Skill ») est un dossier qui contient un fichier SKILL.md : un en-tête YAML avec un nom et une description, puis des instructions en Markdown. Le dossier peut aussi embarquer des fichiers de référence et des scripts. L'agent ne charge pas tout en permanence : il lit la description, et il ne charge le contenu complet de la skill que lorsque votre demande correspond à son usage.

Ce format est ouvert et décrit par la spécification Agent Skills. Il est reconnu par Claude Code, mais aussi par Codex, Cursor, Gemini CLI, GitHub Copilot ou OpenCode, entre autres. Une skill n'apporte pas de nouvel outil technique à l'agent (contrairement à un serveur MCP) : elle lui transmet un savoir-faire, une méthode de travail.

Une skill issue du harness de Cloudflare

La skill security-audit transforme un agent de code en auditeur de sécurité. Elle a été publiée par Cloudflare en accompagnement de l'article Build your own vulnerability harness. Et ce qui est intéressant, c'est que Cloudflare y décrit le système qu'il utilise en interne pour rechercher des vulnérabilités dans ses propres dépôts de code. Quand on connaît l'importance de Cloudflare dans l'écosystème mondial, il est difficile de ne pas jeter un coup d'œil à cette skill.

D'après le README du projet, cette skill est le point de départ de ce système mis au point par Cloudflare : elle a été conçue pour auditer un dépôt unique, avant d'évoluer vers une chaîne d'analyse multi-étapes appliquée à l'ensemble des dépôts de Cloudflare. Ce qu'il faut comprendre, c'est que le harness complet n'est pas publié à ce jour. Mais la skill, elle, est disponible et utilisable par tout le monde.

Les six phases d'un audit complet

Concernant cette skill, elle est conçue pour réaliser un audit complet, la skill orchestre plusieurs agents isolés au travers de six phases :

  • Reconnaissance : cartographie de l'architecture, des trust boundary et des points d'entrée, dans le fichier architecture.md. À partir de cette carte, la skill dresse la liste de tout ce qui doit être examiné : chaque point d'entrée, croisé avec le trust boundary concerné et le type d'attaque à tester. Cette liste, appelée plan de couverture, est enregistrée dans coverage-ledger.json et indique, pour chaque élément, s'il a été traité ou non.

  • Recherche de vulnérabilités, zone par zone : chaque agent de recherche reçoit un élément de cette liste, c'est-à-dire une zone précise du code et un type d'attaque à tester. Des agents « critiques » repèrent ensuite les zones oubliées.

  • Validation des candidats : chaque vulnérabilité candidate est confiée à un nouvel agent dont le rôle est de chercher à démontrer qu'il s'agit d'une fausse alerte.

  • Sortie structurée : les résultats sont écrits dans findings.json puis validés par rapport à un schéma JSON.

  • Vérification indépendante : d'autres agents, qui n'ont pas participé à la découverte, vérifient les affirmations finales dans le code source.

  • Rapport : génération de REPORT.md, FINDINGS-DETAIL.md et NEEDS-VALIDATION.md à partir des résultats vérifiés.

Le principe essentiel utilisé est celui de la validation adversariale : l'agent qui vérifie une découverte n'est jamais celui qui l'a trouvée. C'est ce qui distingue cette approche d'un simple « trouve-moi des failles dans ce code », qui produit souvent des faux positifs présentés avec beaucoup d'assurance.

Schéma des six phases d'un audit avec la skill security-audit de Cloudflare, de la reconnaissance au rapport.

Trois verdicts pour chaque piste

Chaque piste étudiée aboutit à l'un de ces trois verdicts :

Verdict

Signification

Niveau de sévérité

confirmed

Vulnérabilité établie, avec une trace complète dans le code source et un résultat observé

Oui (de informational à critical)

needs_validation

Piste fondée sur le code, mais bloquée par un fait précis non vérifiable (configuration, comportement d'un proxy, etc.). C'est le statut affecté aux failles non vérifiées "par la pratique" en sandbox.

Non

rejected

Piste réfutée lors de la validation

Non

À noter : la skill ne transforme pas une hypothèse en vulnérabilité. Une piste qui dépend d'un élément absent du dépôt reste en needs_validation, avec le fait exact à vérifier. De même, l'absence d'une couche de défense en profondeur n'est pas considérée comme une faille si une autre couche bloque déjà l'attaque : elle est signalée comme une piste de durcissement.

Pour cela, cette skill publiée par Cloudflare s'appuie sur un fichier SKILL.md, quatorze fichiers Markdown complémentaires (méthodologie de reconnaissance, de chasse, de validation et classes d'attaques par domaine : web et authentification, côté client, IA et LLM, supply chain, cloud, protocoles, sécurité mémoire, etc.), un schéma JSON et deux validateurs JavaScript accompagnés de leurs tests.

Les prérequis

Si après avoir lu la présentation de cette skill vous souhaitez, l'installer, sachez que pour suivre ce tutoriel, vous avez besoin de :

  • Un agent de code compatible avec les sous-agents : j'utilise ici Claude Code. Si vous ne l'avez pas encore installé, suivez notre tutoriel Installation et utilisation de Claude Code : premiers pas.

  • Node.js 22.20 ou une version ultérieure : c'est la version minimale exigée par le Skills CLI. Elle couvre aussi les validateurs de la skill. Vérifiez votre version avec node --version.

  • Git : le Skills CLI clone le dépôt de la skill.

  • Un code source à auditer : pour la prise en main, nous utiliserons une application volontairement vulnérable.

  • Idéalement, une machine ou une VM dédiée : nous verrons pourquoi dans la partie consacrée au sandbox.

Installer la skill avec le Skills CLI

Pour installer cette skill, il est recommandé d'utiliser le Skills CLI, un outil en ligne de commande open source développé par Vercel Labs et distribué sur npm sous le nom skills. Son rôle est simple : récupérer une ou plusieurs skills depuis un dépôt Git (GitHub, GitLab, Azure Repos, n'importe quelle URL Git) ou un dossier local, puis les placer dans le bon répertoire pour chaque agent. Il prend en charge près de 80 agents, dont Claude Code, Codex, Cursor et OpenCode.

Le Skills CLI n'est pas un outil d'Anthropic. Vous pouvez parfaitement vous en passer et installer la skill à la main.

Lister le contenu du dépôt avant installation

Commençons par regarder ce que contient le dépôt de Cloudflare, sans rien installer. L'option --list affiche les skills disponibles :

npx skills add https://github.com/cloudflare/security-audit-skill --list

Le dépôt contient une seule skill, nommée security-audit, ce qui correspond bien à ce qu'on pouvait s'attendre.

Installation globale pour Claude Code

L'installation globale rend la skill disponible dans tous vos projets. C'est le choix que je recommande pour un outil transverse comme celui-ci, qui n'a pas vocation à vivre dans le dépôt audité. Au moins, vous pourrez auditer chaque projet que vous développez avec l'IA, y compris (et surtout ?) s'il s'agit d'un outil vibe codé.

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit -a claude-code -g

Quelques explications sur les options utilisées :

  • --skill security-audit (ou -s) : sélectionne la skill à installer. Sans cette option, le CLI vous propose de choisir parmi les skills du dépôt.

  • -a claude-code (ou --agent) : cible un agent précis. Sans cette option, le CLI détecte les agents installés sur votre machine et vous demande lesquels utiliser.

  • -g (ou --global) : installe la skill dans votre répertoire personnel plutôt que dans le projet courant.

Vous devez confirmer avec yes l'installation de la skill. L'opération est simple et rapide.

Suite à l'exécution de cette commande, les fichiers de la skill sont stockés dans ~/.claude/skills/security-audit/, qui est le répertoire des skills personnelles de Claude Code.

ls ~/.claude/skills/security-audit/

total 696
-rw-r--r--@ 1 florian  staff  10617 Oct 20 15:40 AI-AND-LLM.md
-rw-r--r--@ 1 florian  staff  15695 Oct 20 15:40 ATTACK-CLASSES.md
-rw-r--r--@ 1 florian  staff   8594 Oct 20 15:40 CLIENT-SIDE.md
-rw-r--r--@ 1 florian  staff   8291 Oct 20 15:40 CLOUD-AND-DEPLOYMENT.md
-rw-r--r--@ 1 florian  staff   7798 Oct 20 15:40 DATA-ISOLATION-AND-LIFECYCLE.md
-rw-r--r--@ 1 florian  staff   8739 Oct 20 15:40 DESKTOP-MOBILE-AND-LOCAL-IPC.md
-rw-r--r--@ 1 florian  staff  22446 Oct 20 15:40 HUNTING.md
-rw-r--r--@ 1 florian  staff  10513 Oct 20 15:40 MEMORY-SAFETY-AND-BINARY.md
-rw-r--r--@ 1 florian  staff   7483 Oct 20 15:40 PROTOCOLS-RPC-AND-MESSAGING.md
-rw-r--r--@ 1 florian  staff  15902 Oct 20 15:40 RECONNAISSANCE.md
-rw-r--r--@ 1 florian  staff  14494 Oct 20 15:40 report-schema.json
-rw-r--r--@ 1 florian  staff   7476 Oct 20 15:40 RESOURCE-EXHAUSTION-AND-AVAILABILITY.md
-rw-r--r--@ 1 florian  staff  22026 Oct 20 15:40 SKILL.md
-rw-r--r--@ 1 florian  staff   7258 Oct 20 15:40 SUPPLY-CHAIN-AND-RELEASE.md
-rwxr-xr-x@ 1 florian  staff  33522 Oct 20 15:40 validate-coverage-ledger.cjs
-rw-r--r--@ 1 florian  staff  28483 Oct 20 15:40 validate-coverage-ledger.test.cjs
-rwxr-xr-x@ 1 florian  staff  28806 Oct 20 15:40 validate-findings.cjs
-rw-r--r--@ 1 florian  staff  26384 Oct 20 15:40 validate-findings.test.cjs
-rw-r--r--@ 1 florian  staff  17843 Oct 20 15:40 VALIDATION-AND-REPORTING.md
-rw-r--r--@ 1 florian  staff  12300 Oct 20 15:40 WEB-PROTOCOL-AND-AUTH.md

Gérer la skill au quotidien

Le Skills CLI contient des commandes globales de suivi des skills, dont une commande pour la mettre à jour ou la désinstaller. Cela pourrait vous servir par la suite :

# Lister les skills installées au niveau utilisateur
npx skills ls -g

# Vérifier si une mise à jour est disponible
npx skills check

# Mettre à jour la skill
npx skills update security-audit

# Désinstaller la skill du niveau utilisateur
npx skills remove security-audit -g

Installer la skill sans le Skills CLI

Puisqu'une skill est un simple dossier, vous pouvez l'installer à la main, ce qui vous permet aussi de garder un contrôle total sur la version installée :

# Cloner le dépôt de la skill dans un dossier de travail
git clone --depth 1 https://github.com/cloudflare/security-audit-skill.git ~/src/security-audit-skill

# Créer le répertoire des skills personnelles de Claude Code s'il n'existe pas
mkdir -p ~/.claude/skills

# Copier le dossier de la skill
cp -r ~/src/security-audit-skill/skills/security-audit ~/.claude/skills/

Pour une installation au niveau du projet, copiez le dossier dans .claude/skills/ à la racine du dépôt. Claude Code surveille ces répertoires et prend en compte une nouvelle skill sans redémarrage.

Prise en main dans Claude Code

Si vous êtes arrivé jusqu'ici tout en effectuant les manipulations, la skill doit être installée. Pour le vérifier, dans Claude Code, la commande /skills affiche la liste des skills disponibles : security-audit doit y apparaître.

Commande /skills dans Claude Code affichant la skill security-audit de Cloudflare installée

Deux modes de fonctionnement

Avant de lancer quoi que ce soit, il faut comprendre que la skill fonctionne selon deux modes :

  • Le mode « guidance » (par défaut) : pour une question de sécurité, une revue ciblée ou l'analyse d'une piste précise, l'agent utilise seulement les parties utiles de la skill. Il ne crée pas de dossier de sortie et ne déroule pas les six phases.

  • Le mode « full audit » : il est déclenché par une demande explicite d'audit ou de pentest d'une base de code, d'une revue « complète » ou « de bout en bout », ou par une demande de rapport. L'agent déroule alors les six phases et produit les fichiers de résultats.

Si votre demande est ambiguë, la skill demande à l'agent de vous poser une question avant de créer des fichiers. C'est un bon réflexe, car un audit complet est long et consomme beaucoup de tokens.

Préparer un terrain d'essai avec DVWA

Pour une première prise en main, je vous recommande de ne pas commencer par un projet sensible. Analysez un petit outil vibe codé... Ou prenez plutôt une application volontairement vulnérable, dont vous connaissez déjà les failles : cela vous permettra de juger la qualité des résultats. DVWA (Damn Vulnerable Web Application), une application PHP / MariaDB conçue pour l'entraînement, fait très bien l'affaire. Mais on verra, que ça peut aussi poser problème.

# Créer un dossier de lab pour dvwa et cloner le projet DVWA
mkdir -p dvwa && cd dvwa
git clone https://github.com/digininja/DVWA.git

Attention : DVWA est vulnérable par conception. Nous n'avons besoin que de son code source : ne la déployez pas, et surtout pas sur un serveur exposé à Internet.

Isoler l'exécution : le sandbox de Claude Code et ses limites

La skill est très stricte sur ce point. Par défaut, elle se contente d'analyser le code source en lecture seule. Elle n'accepte d'exécuter du code issu de la cible (build, tests, scripts, fixtures) qu'à l'intérieur d'un sandbox imposé par le système d'exploitation, qui doit réunir toutes ces conditions :

  • Aucun accès au réseau externe

  • Un environnement vide, rempli uniquement à partir d'une liste explicite de variables

  • Une cible et une chaîne d'outils en lecture seule, avec écriture limitée à un dossier de travail dédié

  • Des limites explicites de CPU, de mémoire, de processus, de taille de fichiers et de durée

Si l'une de ces conditions ne peut pas être garantie, la skill ne lance rien : la piste identifiée reste alors sur l'état needs_validation, accompagnée d'un plan de validation. Elle n'installe pas non plus de dépendances et interdit de sonder des services déployés ou des environnements de production.

La difficulté, c'est la mise en place de cette sandbox.... Claude Code dispose bien d'une sandbox native pour les commandes shell, désactivée par défaut. Elle repose sur Seatbelt sous macOS (natif), et sur bubblewrap et socat sous Linux et WSL2 :

sudo apt-get install bubblewrap socat

Ensuite, dans une session Claude Code, la commande /sandbox ouvre le panneau de configuration. Une fois le sandbox activé, les commandes shell ne peuvent plus écrire en dehors des dossiers autorisés, et le trafic réseau passe par un proxy local qui n'autorise que les domaines de votre liste (vide au départ).

Ci-dessous la configuration de la sandbox, l'idée étant que ce soit réellement une sandbox stricte.

Mais soyons honnêtes, l'activation de cette sandbox ne suffit. Elle ne remplit donc pas, à elle seule, toutes les conditions posées par la skill de Cloudflare. Pour aller jusqu'à l'exécution de tests sur le code audité, la solution la plus propre reste de travailler dans une machine virtuelle jetable (sur votre hyperviseur ou votre lab Proxmox, par exemple), sans accès réseau vers vos autres machines et sans aucun identifiant sensible. Pour une première prise en main, l'analyse statique suffit largement : c'est d'ailleurs le comportement par défaut de la skill.

Premier usage sur une demande spécifique

Placez-vous dans le dossier de DVWA et lancez Claude Code :

cd DVWA
claude

Commençons par une demande ciblée, qui reste en mode guidance. Cloudflare explique qu'il est possible de demander un audit de sécurité en une phrase directe, du style : "security audit this codebase". Mais on peut aussi lui donner des instructions plus spécifiques (ce qui est bien et pas bien, selon le contexte). Par exemple :

/security-audit Le fichier vulnerabilities/sqli/source/low.php est-il vulnérable à une injection SQL ? Explique le chemin de la donnée, de l'entrée utilisateur jusqu'à la requête, et propose le correctif minimal.

La question relevant de la sécurité, la skill doit se charger automatiquement, mais personnellement je préfère l'indiquer explicitement via le préfixe /security-audit. L'agent répond dans la conversation, sans créer de dossier de rapport. Ce mode est pratique au quotidien, par exemple pour challenger une fonction avant une revue de code.

Voici un aperçu partiel de la réponse obtenue :

Analyse d'une injection SQL dans DVWA par Claude Code avec la skill security-audit en mode guidance

L'analyse du code indique qu'il y a bien une faille de sécurité de type injection SQL, mais malgré tout elle reste dans l'état à confirmer : elle n'a pas été vérifiée dans une sandbox. Autrement dit, elle a été déterminée suite à l'analyse du code, mais pas en pratique.

Lancer un audit complet

Passons maintenant à l'audit complet. Vous pouvez simplement lui demander d'effectuer un audit de sécurité sur la codebase ou alors de cadrer la demande : profil, périmètre, dossier de sortie et budget. Si je dis ça, c'est parce qu'il peut très bien lancer 50 ou 60 agents en parallèle pour faire une analyse, donc ça peut rapidement consommer beaucoup de tokens.

/security-audit Réalise un audit de sécurité complet de ce dépôt.
Profil : quick.
Périmètre : le dossier vulnerabilities/ uniquement.
Analyse statique uniquement : n'exécute aucun code du dépôt.
Budget : 25 agents au maximum.
Écris les résultats dans le sous-dossier run-1.

Ces paramètres correspondent à ce que prévoit la skill :

  • Le profil : quick réalise une passe unique avec des unités de couverture regroupées, idéale pour une première approche. standard (par défaut) applique le déroulé complet. deep découpe plus finement et multiplie les vérifications, pour les cibles sensibles ou volumineuses.

  • Le périmètre : un audit peut cibler des chemins précis, un sous-système ou la différence entre deux commits. Tout ce qui sort du périmètre est marqué out_of_scope, jamais « couvert ».

  • Le budget : il s'exprime en nombre maximal d'invocations d'agents. La skill réserve d'abord les agents nécessaires à la reconnaissance, aux critiques de couverture et à la validation, avant d'attribuer le reste aux chasseurs. Si le budget ne suffit pas, l'audit est déclaré incomplet au lieu d'être bâclé.

  • Le dossier de sortie : à défaut, la skill écrit dans ~/security-audit-skill/<nom-du-dépôt>/run-<N>. Ici, ce sera dans un sous-dossier, mais ajustez selon vos préférences.

Si vous le lancez sans préciser votre demande, il vous posera surement la question. Par exemple :

Pendant l'audit, vous verrez Claude Code lancer plusieurs sous-agents en parallèle :

En effectuant ces tests d'audit sur DVWA, j'ai eu un cas intéressant. La Skill s'est arrêtée net à cause des garde-fous de Claude Opus 5.5. En effet, même si j'ai un abonnement Claude, j'ai les mêmes restrictions que toutes les autres personnes qui ne font pas partie du Cyber Verification Program. Ainsi, cela m'a bloqué, mais en relançant l'analyse sur un périmètre différent (exposé ci-dessus), c'est passé. J'ai également pu réaliser des audits complets sur des outils internes développés à l'aide de Claude.

Le contenu du dossier de résultats

À la fin d'un audit complet, le dossier de sortie contient les fichiers suivants :

Fichier

Contenu

run-metadata.json

Paramètres de l'exécution : dépôt, commit audité, profil, périmètre, budget, statut

architecture.md

Synthèse de l'architecture et des trust boundary

coverage-ledger.json

Plan de couverture : chaque unité, son statut et les agents qui l'ont traitée

findings.json

Tous les résultats structurés (confirmed, needs_validation, rejected)

REPORT.md

Le rapport de synthèse, à lire en premier

FINDINGS-DETAIL.md

Le détail de chaque vulnérabilité confirmée

NEEDS-VALIDATION.md

Les pistes non tranchées, avec le blocage précis et les étapes de validation

agents/

Les dossiers de travail de chaque agent

Quand il termine son travail, il évoque clairement ces fichiers. L'idéal, c'est d'avoir un lecteur de fichiers Markdown ou alors de lui demander de produire un rapport sous la forme d'un document, afin d'avoir un résultat facilement lisible.

Lire et exploiter le rapport

Le fichier REPORT.md commence par rappeler le profil, le périmètre, le budget consommé et le commit audité. Il présente ensuite un tableau des vulnérabilités confirmées (sévérité, titre, frontière franchie, résultat observé), puis un tableau séparé des pistes à valider.

La skill applique une grille de sévérité basée sur l'impact démontré :

Sévérité

Exemples donnés par la skill

critical

Un attaquant non authentifié obtient une exécution de code, un accès complet aux données ou la prise de contrôle de comptes arbitraires

high

Contournement complet d'un contrôle de sécurité : bypass d'authentification, accès entre locataires, XSS stocké visant d'autres utilisateurs, exécution de code authentifiée

medium

Violation réelle d'une frontière, mais avec un impact limité ou des conditions peu courantes

low

Divulgation d'informations internes non sensibles, ou effet qui demande beaucoup d'efforts pour un gain minime

informational

Observation confirmée à impact minimal, utile surtout comme maillon d'une attaque plus large

Pour chaque vulnérabilité confirmée, FINDINGS-DETAIL.md fournit la trace dans le code (fichiers et lignes), les conditions d'exploitation, la correction minimale recommandée et des tests de non-régression. La skill décrit les corrections, mais ne modifie jamais le code audité. C'est à vous de les appliquer, éventuellement en demandant ensuite à Claude Code de le faire à partir de findings.json, dans une session distincte.

Relancer l'audit pour améliorer la couverture

Un seul passage ne suffit pas. Cloudflare l'indique clairement dans le README : lors de ses tests, une exécution unique trouvait environ la moitié des vulnérabilités découvertes au total sur plusieurs exécutions. La skill est prévue pour cela : les exécutions successives sur un même dépôt sont cumulatives. À chaque nouveau passage, elle relit les plans de couverture et les résultats précédents, cible les zones non couvertes, revalide ce qui a changé dans le code et ne considère jamais une zone non traitée comme sûre.

Donc vous pouvez, je dirais même vous devez, relancer l'audit plusieurs fois. Voici un exemple de prompt dans cet esprit.

/security-audit Relance un audit complet de ce dépôt en profil standard, en tenant compte des exécutions précédentes. Écris les résultats dans ~/audits/dvwa/run-2.

Vous pourriez aussi aller plus loin dans la rédaction du prompt, ce qui peut être un moyen d'optimiser votre budget :

/security-audit Réalise un audit de sécurité complet et ciblé de ce dépôt, que je suis autorisé à auditer.
Périmètre : le code censé être sûr (connexion, session, setup, changement de niveau, jetons CSRF, API et fichiers impossible.php). Les fichiers low, medium et high sont des failles volontaires et restent hors périmètre. Le dossier .github/ est hors périmètre.
Politique attendue : les modules sont réservés aux utilisateurs authentifiés. Au niveau impossible, chaque module doit résister à l'attaque qu'il illustre. La réinitialisation de la base via setup.php est une fonctionnalité documentée.
Profil : quick. 
Budget : 30 agents au maximum.
Enregistre le commit audité et l'état du dépôt.
Avant toute exécution de code du dépôt, indique quels contrôles du sandbox sont réellement disponibles. S'ils manquent, garde le blocage exact visible.
Écris les résultats dans ~/audits/dvwa/run-2 et distingue clairement les résultats validés des pistes bloquées.

Conclusion

La skill security-audit de Cloudflare apporte à votre agent de code ce qui manque le plus souvent aux analyses de sécurité assistées par IA : une méthode. Plan de couverture, chasse aux bugs organisée, validation par des agents indépendants, verdicts distincts et rapport structuré : on est loin du simple prompt « trouve des failles ». Son installation est rapide avec le Skills CLI, que ce soit en global ou par projet, et elle fonctionne aussi bien avec Claude Code qu'avec d'autres agents compatibles.

Le problème, c'est cette histoire de sandbox : rien n'indique clairement comment la créer et la configurer. De ce fait, la majorité des failles restent en attente de validation, car la mécanique d'évaluation "en conditions réelles" ne peut pas se déclencher. C'est un point sur lequel je vais effectuer des recherches prochainement.

En attendant, voici quelques points d'attention à garder en tête :

  • Prévoir la consommation de tokens : un audit complet mobilise de nombreux sous-agents. Commencez par le profil quick et un périmètre restreint, et fixez un budget en nombre d'agents.

  • Auditer un commit précis : la skill enregistre le commit audité et signale un dépôt modifié localement. Travaillez sur une copie propre, à jour, pour que le rapport corresponde à un état identifiable du code.

  • Garder un humain dans la boucle : même avec la validation adversariale, chaque vulnérabilité confirmée doit être relue avant correction. Cloudflare reconnaît lui-même ne pas pouvoir mesurer son taux de faux négatifs, faute de jeu de données étiqueté : l'absence de résultat ne prouve pas l'absence de faille.

  • Ne pas en faire un pentest : la skill travaille sur le code source et refuse de sonder des environnements déployés. Tout ce qui dépend de la configuration réelle (reverse proxy, WAF, en-têtes HTTP, fournisseur d'identité) reste en needs_validation. Un test d'intrusion sur l'environnement réel reste complémentaire, et nécessaire.

  • N'analysez pas n'importe quel dépôt : ne lancez pas la skill sur un dépôt dont vous n'avez pas le droit d'analyser le code.

Ajouter IT-Connect à mes
sources préférées

author avatar

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.

readers loved this