Le Skill security-audit de Cloudflare : audits de sécurité IA adverses avec Claude Code (2026)

Intermédiaire

What you'll learn

Expliquer pourquoi « demander à Claude de trouver des vulnérabilités » produit des résultats erronés mais présentés avec assurance, et ce que corrige la séparation des pouvoirs entre hunters et vérificateurs
Parcourir les six phases et nommer l'artefact produit par chacune, de architecture.md à NEEDS-VALIDATION.md
Lire correctement un findings.json : ce qu'exigent confirmed, needs_validation et rejected, et pourquoi seuls les enregistrements confirmed reçoivent une sévérité
Exécuter le skill dans Claude Code au sein d'un sandbox conforme à ses règles, valider les résultats de façon mécanique, et relancer pour la couverture
Budgétiser l'opération : à quoi ressemble la facture en tokens, la règle qui fait que le skill refuse de lancer des hunters, et les trois façons de garder une exécution abordable

Cloudflare a publié en open source un unique skill mi-septembre 2026, et c'est devenu le dépôt à la croissance la plus rapide de GitHub : cloudflare/security-audit-skill comptait 18,5k étoiles le 21 septembre après en avoir ajouté 2,4k en une journée, et avait déjà suscité un fil Hacker News à 211 points le 17 septembre. Ce qui compte n'est pas le nombre d'étoiles. C'est que ce skill est la graine du harnais de vulnérabilités à l'échelle d'une flotte que Cloudflare a décrit en juin, celui qui a tourné sur 128 dépôts et produit 7 245 découvertes exploitables. Le skill public est la version mono-dépôt que vous pouvez exécuter dès aujourd'hui avec Claude Code.

Il vaut la peine d'être précis sur ce que c'est. Il n'y a ni binaire, ni moteur de règles, ni modèle propre. C'est un SKILL.md plus quatorze guides de chasse et deux validateurs Node sans dépendance. Tout ce qu'il fait, il le fait en amenant votre agent à générer des sous-agents isolés avec des mandats étroits, et en refusant d'accepter leur résultat tant qu'un agent différent n'a pas essayé de le démonter.

Pourquoi « trouve les vulnérabilités » échoue seul

Le billet de juin de Cloudflare contient la phrase qui explique toute la conception : un agent non contraint « modifiera le code source pour que son propre exploit fonctionne, puis annoncera triomphalement le bug qu'il vient de créer ». Et la règle qui l'accompagne : « Si un Hunter est autorisé à corriger sa propre copie, il validera avec assurance tout ce qu'il produit. »

C'est le mode d'échec de toute invite « audite mon dépôt » en un coup. Le modèle qui a passé 80k tokens à formuler une théorie est le dernier modèle que vous voulez voir juger cette théorie. La réponse du skill est structurelle :

Les hunters ne peuvent pas déposer de découvertes. Ils renvoient des candidats et n'ont pas le droit de modifier le code source cible, les notes d'architecture, le registre ou le fichier de découvertes.
Les vérificateurs ne peuvent pas chasser. Un vérificateur neuf reçoit un seul candidat, les faits d'architecture et le schéma, et rien d'autre, pas même la conclusion d'un autre vérificateur. Son rôle est de réfuter.
Rien n'est conservé sauf si du code déterministe l'accepte. L'agent parent écrit les fichiers partagés ; validate-findings.cjs et validate-coverage-ledger.cjs rejettent tout ce qui enfreint le schéma.

La version interne de Cloudflare va plus loin et utilise un modèle différent pour la validation que pour la découverte, sur le principe que des poids distincts donnent un second avis non biaisé. Le skill public n'impose pas cela, mais rien ne vous empêche d'orienter les sous-agents vérificateurs vers un modèle différent.

Les six phases et ce que chacune laisse derrière elle

Phase	Qui exécute	Résultat
1. Reconnaissance	4 agents de recherche en parallèle (stack et build ; principaux et authentification ; surfaces d'entrée et puits ; ce qui est testable hors ligne) qui ne renvoient que des faits	`architecture.md` (environ 1 000 mots) et un `coverage-ledger.json` initialisé
2. Chasse pilotée par la couverture	Des vagues de hunters isolés, une ou plusieurs unités du registre chacun ; un critique de couverture après chaque vague	Des candidats avec `proposed_verdict`, des dispositions d'unités, des notes de durcissement, des lacunes nouvellement découvertes
3. Validation des candidats	Un vérificateur neuf par empreinte de candidat unique	Une décision par candidat : confirmed, needs_validation ou rejected
4. Sortie structurée	Le parent uniquement	`findings.json`, trié par empreinte, validé par schéma
5. Vérification indépendante des enregistrements	Un vérificateur neuf par enregistrement confirmed ou needs_validation	`verified` ou `replace` ; tout remplacement significatif reçoit un second vérificateur neuf
6. Rapport neutre vis-à-vis de la cible	Le parent, une fois la phase 5 franchie	`REPORT.md`, `FINDINGS-DETAIL.md` (medium et plus uniquement), `NEEDS-VALIDATION.md`

Tout atterrit sous ~/security-audit-skill/<repo-name>/run-<N>/, avec des répertoires agents/<id>/scratch/ et agents/<id>/artifacts/ par agent. Seul le parent écrit les fichiers partagés.

Le registre de couverture (coverage ledger) est le mécanisme que la plupart des gens manquent. Une unité est une combinaison matérielle de surface d'entrée, frontière de confiance, sous-système et classe d'attaque, avec des chemins de départ dans le dépôt. Les unités passent par les statuts planned, in_progress, blocked, covered ou candidate, et chaque statut impose des règles sur les champs de preuve à remplir. Un critique de couverture lit l'ensemble du registre après une vague et cherche des points d'entrée non cartographiés, des chemins parallèles non vérifiés et des exclusions injustifiées ; il peut rouvrir une unité (en archivant la tentative précédente) mais ne peut jamais proposer de découverte. C'est ce qui rend les relances additives : une seconde exécution reprend les unités que la première a laissées blocked ou rouvertes, au lieu de tout auditer à nouveau.

Les trois verdicts, et pourquoi un seul porte une sévérité

Le schéma est strict sur les champs que chaque verdict peut utiliser, et le validateur l'impose.

Verdict	Signifie	Doit avoir	Ne doit pas avoir
`confirmed`	Reproduit indépendamment dans le sandbox à partir du code source, effet observé minimal uniquement	root_cause, intended_behavior, trace (du point d'entrée au puits), evidence, conditions, execution, remediation, severity, confidence	claimed_root_cause, blockers, validation_plan, reason
`needs_validation`	Ancré dans le code source, mais bloqué par un fait exact unique qui ne peut être résolu localement (un paramètre de déploiement, une config réservée au propriétaire)	claimed_root_cause, trace, evidence, blockers, validation_plan	severity, execution, remediation
`rejected`	Le vérificateur l'a réfuté	claimed_root_cause, trace, evidence, reason	severity, execution, remediation, blockers

Trois conséquences en découlent :

Une découverte needs_validation n'a pas de sévérité, par conception. Ce n'est pas un « medium » ; c'est une question posée au propriétaire du code, avec un plan exact pour y répondre. NEEDS-VALIDATION.md existe pour que cette liste ne soit pas prise pour une liste de vulnérabilités.
La sévérité exige un impact démontré, pas une case manquante dans une checklist. Le calibrage dans SKILL.md : critical est une exécution de code non authentifiée, un accès complet aux données ou une prise de contrôle de compte ; high est la défaite complète d'un contrôle explicite (contournement d'authentification, accès inter-locataires) ; medium est un rayon d'impact limité ou des préconditions rares ; low est une divulgation non secrète ; informational est une observation confirmée à impact minimal. « Bonne pratique manquante » n'est explicitement pas une découverte.
Une exécution propre rapporte zéro. Le guide de rapport indique qu'un rapport proportionné peut n'avoir aucune découverte confirmed et doit le dire clairement. Si votre exécution « trouve » vingt critiques dans un petit service, soupçonnez d'abord la configuration du sandbox avant de soupçonner le service.

Pour les lecteurs de cette section, le guide de chasse IA/LLM est la partie la plus tranchante. Sa règle d'ouverture : « Une injection de prompt seule n'est pas une découverte. Exiger une défaillance de frontière au niveau du code. » Un hunter doit montrer l'attaquant, le principal affecté, l'identité d'exécution, et une action ou une divulgation non autorisée, avec une trace source depuis l'entrée contrôlée par l'attaquant jusqu'à l'effet de bord. Les schémas que le guide envoie chasser aux hunters sont ceux de nos pages injection de prompt et empoisonnement d'outils MCP, mais présentés comme des défauts de code : des arguments d'outil atteignant du SQL ou un shell sans validation côté gestionnaire, des sous-agents héritant de pleins pouvoirs au lieu du moindre privilège, des descriptions d'outils traitées comme une autorisation, une sortie de modèle rendue dans du HTML ou une commande sans encodage, une fuite de contexte inter-locataires due à des clés de cache trop larges. Persuader le modèle de dire quelque chose de grossier ne compte pas.

La règle du sandbox n'est pas un conseil

SKILL.md exige que tout code contrôlé par la cible (tests, fixtures, le build propre du projet) s'exécute dans un sandbox imposé par l'OS, sans réseau externe, avec au plus un espace de noms loopback isolé, le code source cible en lecture seule, des écritures confinées à scratch/, et des limites strictes de CPU, mémoire, processus et taille de fichier. Les vérificateurs sont informés que si le sandbox est indisponible, le candidat reste simplement non validé. La promotion de scratch/ vers artifacts/ conservés refuse les liens symboliques, les fichiers à liens multiples, les archives et les copies récursives, et ne rouvre jamais rien par chemin.

C'est le même modèle de menace que notre page agents de codage sous attaque, retourné vers l'intérieur : le dépôt que vous auditez peut être hostile, et sa suite de tests est du code que vous êtes sur le point d'exécuter. Dans Claude Code, cela signifie exécuter l'audit avec les contrôles sandbox et masquage des identifiants activés, pas dans votre shell habituel avec vos véritables variables d'environnement. Une subtilité issue du propre harnais de Cloudflare s'applique si vous imbriquez Docker dans un conteneur : il faut seccomp=unconfined et apparmor=unconfined « sinon il échoue silencieusement ».

Guided walkthrough1 of 6

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit. Le CLI skills (vercel-labs/skills) le dépose dans .claude/skills/ pour Claude Code ou .agents/skills/ pour Codex, Cursor et Gemini CLI ; ajoutez -g pour une installation globale, -a claude-code pour cibler un seul agent. Lisez SKILL.md avant de l'exécuter : c'est le contrat que vous êtes sur le point d'exécuter.

Phrases déclencheuses et commandes du validateur

# Full audit (creates ~/security-audit-skill/<repo>/run-N/)
security audit this codebase
find security vulnerabilities in ./src

# Guidance mode (no run directory, no sub-agent fleet)
is the session cookie handling in auth/session.ts safe against fixation?

# After a run: mechanical checks, zero dependencies beyond Node
node .claude/skills/security-audit/validate-findings.cjs ~/security-audit-skill/<repo>/run-1/findings.json
node .claude/skills/security-audit/validate-coverage-ledger.cjs ~/security-audit-skill/<repo>/run-1/coverage-ledger.json

# What the schema hard-limits (validator rejects beyond these)
# findings.json: 5 MiB, 1,000 findings, 64 nesting levels
# coverage-ledger.json: 5 MiB, 10,000 units, 1,000 entries per collection

Ce que ça coûte, et comment garder cela abordable

Le fil HN porte surtout sur la facture. Un utilisateur a rapporté « j'ai brûlé 1M de tokens pour rien sur une base de code moyenne » ; un autre place le plafond pratique à 150k tokens, « là où on commence à entrer dans la zone bête » de l'attention dégradée. Ce sont des anecdotes, pas des mesures, mais elles correspondent à la forme de la conception : quatre agents de reconnaissance, une vague de hunters, un vérificateur par candidat, un critique par vague, puis un second vérificateur par enregistrement survivant. Les chiffres de flotte de Cloudflare donnent l'échelle réelle : un dépôt standard de 30k lignes a pris de 3 à 4 heures pour environ 100 découvertes brutes, et sur l'ensemble de la flotte, 58 % des candidats bruts ont survécu à la validation (12 057 sur 20 799).

Trois éléments du skill lui-même l'empêchent de s'emballer :

La règle de réserve de budget. Avant chaque vague, le parent doit réserver du budget pour les hunters, la passe de validation, le critique de fin de vague et un critique final propre. HUNTING.md dit : si ces réserves obligatoires ne rentrent pas, ne lancer aucun hunter pour cette vague, et marquer les unités comme différées avec la raison budgétaire. Une exécution qui se termine avec des unités différées est une exécution qui a respecté votre budget, pas une exécution cassée.
Des mandats étroits. Chaque sous-agent reçoit une seule unité ou un seul candidat. Le harnais de Cloudflare maintenait chaque agent sous 25 % de sa fenêtre de contexte, et en crédite, plus que tout choix de formulation d'invite, la qualité des découvertes.
Le mode guidage. La plupart des questions de sécurité n'ont pas besoin du pipeline. Posez-les directement et le skill répond sans rien générer.

De votre côté : limitez la première exécution à un seul répertoire ; utilisez un modèle avec un grand contexte et des lectures de cache bon marché pour les hunters, et un modèle plus puissant pour les vérificateurs ; mettez un budget de tâche sur la session ; et traitez une exécution interrompue par une limite de session comme partielle, pas comme un échec, car le registre enregistre exactement où elle s'est arrêtée.

Où il se situe par rapport à Semgrep, CodeQL et la revue de code par IA

Ce n'est pas un remplacement de l'analyse statique et il ne prétend pas l'être. Le billet de Cloudflare contient un détail révélateur : ils ont branché Semgrep dans le harnais et les agents l'ont « complètement ignoré », préférant lire et exécuter le code. Les outils statiques offrent une couverture déterministe, bon marché et reproductible des schémas connus ; ce skill offre une couverture coûteuse, probabiliste et gourmande en raisonnement des défaillances de frontière que les comparateurs de schémas ne peuvent exprimer, avec une étape de validation que les outils statiques n'ont pas. Utilisez les deux. Et ne le confondez pas avec la revue au moment de la PR : open-code-review d'Alibaba est un reviewer de diff qui s'exécute en quelques secondes par pull request ; ceci est un audit de plusieurs heures d'une base de code au repos.

Termes que vous rencontrerez dans le répertoire d'exécution

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.

1 / 8

Testez-vous

0/6

Un hunter est convaincu d'avoir trouvé un contournement d'authentification. Qu'a-t-il le droit d'en faire ?
Un enregistrement de findings.json a le verdict needs_validation et une sévérité high. Que s'est-il passé ?
Votre suite de tests effectue des appels HTTP sortants. Que dit le skill aux hunters et vérificateurs de faire ?
Un hunter montre qu'un e-mail conçu à cet effet fait dire à l'assistant quelque chose d'offensant. Selon AI-AND-LLM.md, ceci est :
L'exécution se termine avec plusieurs unités marquées deferred et une raison budgétaire. Qu'est-ce que cela signifie ?
Les données de flotte de Cloudflare disent qu'une seule exécution trouve environ quelle part de ce que trouvent des exécutions répétées ?

Sources et lectures complémentaires

cloudflare/security-audit-skill sur GitHub — README, SKILL.md, les guides de phase (RECONNAISSANCE.md, HUNTING.md, VALIDATION-AND-REPORTING.md), les quatorze guides de classe d'attaque dont AI-AND-LLM.md, report-schema.json, et les deux validateurs ; MIT
Build your own vulnerability harness — blog Cloudflare, 18 juin 2026 (Grant Bourzikas) : comment le skill est devenu le harnais de flotte, l'entonnoir 20 799 à 12 057 à 7 245, le chiffre de 3 à 4 heures par dépôt de 30k lignes, la règle « corriger sa propre copie », les pièges du Docker imbriqué et du 200-OK-avec-erreur
Hacker News discussion (item 49736466) — retours de première main sur les tokens et les critiques sur le coût
vercel-labs/skills — le CLI npx skills add et où il installe les skills pour chaque agent
Agent Skills open standard — pourquoi un seul SKILL.md s'exécute dans Claude Code, Codex, Cursor et Gemini CLI

Suite

Vetting agent skills you install — ce skill génère des agents qui exécutent le code de votre dépôt ; lisez-le avant de faire confiance à un skill, y compris celui-ci
Hardening autonomous runs — la configuration de sandbox, de secrets et de sortie réseau dont a besoin un audit autonome de plusieurs heures
Open Code Review: Alibaba's hybrid AI reviewer — le pendant au moment de la PR, et la même leçon précision contre rappel

Partager cette page

Pourquoi « trouve les vulnérabilités » échoue seul​

Les six phases et ce que chacune laisse derrière elle​

Les trois verdicts, et pourquoi un seul porte une sévérité​

La règle du sandbox n'est pas un conseil​