Cloudflare open-source son skill d'audit sécurité IA
Cloudflare a levé le capot sur son harness interne de découverte de vulnérabilités et open-sourcé security-audit-skill : un ensemble de skills qui transforme un agent de code (Claude Code, Copilot et consorts) en auditeur de sécurité structuré.
L'essentiel
Cloudflare a publié sous licence MIT security-audit-skill, un ensemble de skills qui transforme un agent de code capable d'utiliser des outils et de lancer des sous-agents en auditeur de sécurité. Le workflow compte six phases, de la reconnaissance de l'architecture au rapport final. Son principe central : l'agent qui trouve une vulnérabilité ne la valide jamais lui-même, un agent vierge cherche à la réfuter. Les résultats sont classés en « confirmed », « needs_validation » ou « rejected ». Cloudflare a décrit l'approche dans un article de blog publié le 18 juin 2026, où son harness interne a produit 20 799 candidats, dont 12 057 ont survécu à la validation. Pour les équipes qui livrent du code, l'enseignement tient moins au modèle utilisé qu'à la discipline du process : couverture tracée, validation indépendante et preuves exigées avant toute sévérité.
Qu'est-ce que security-audit-skill ?
Un skill est un ensemble d'instructions qu'un agent de code charge pour accomplir une tâche précise, ici un audit de sécurité. security-audit-skill s'active par une simple phrase, par exemple « security audit this codebase », et exige un agent dont le modèle gère l'appel d'outils et les sous-agents en parallèle.
Quelles sont les six phases de l'audit ?
Le dépôt GitHub décrit le workflow en six phases.
| Phase | Ce qu'elle fait |
|---|---|
| 1. Reconnaissance | Cartographie l'architecture, les frontières de confiance, les surfaces d'entrée et les preuves antérieures |
| 2. Chasse pilotée par la couverture | Confie des unités du registre de couverture à des chasseurs isolés, puis des critiques de couverture cherchent les trous |
| 3. Validation des candidats | Donne chaque candidat unique à un vérificateur vierge qui tente de le réfuter |
| 4. Sortie structurée | Écrit les enregistrements confirmed, needs_validation et rejected dans findings.json |
| 5. Vérification indépendante | Des agents vierges contrôlent les affirmations finales sur le code source ; un remplacement important reçoit un nouveau vérificateur |
| 6. Rapport | Produit REPORT.md, FINDINGS-DETAIL.md et NEEDS-VALIDATION.md |
Pourquoi séparer la découverte de la validation ?
Cloudflare a fait un choix pertinent : l'agent qui trouve un finding ne le valide jamais lui-même. Un autre agent, vierge, reçoit la découverte avec une seule mission : la réfuter. Les statuts découlent de ce test. « confirmed » exige une trace complète du code avec un résultat observé et borné. « needs_validation » désigne un fait précis non résolu, sans sévérité assignée. « rejected » documente un candidat réfuté.
Les classes d'attaque couvertes vont loin : supply chain et CI/CD, IAM et InfraAsCode, containers, serverless, injection de prompt sur les cibles qui embarquent un LLM, épuisement de ressources. La liste du dépôt va jusqu'à l'isolation entre tenants, les webhooks ou la sécurité mémoire.
Quel problème résout-il : l'hallucination d'audit ?
Les audits sécurité par IA souffrent d'un problème connu : le modèle hallucine des vulnérabilités ou en rate la moitié, et personne ne sait lesquelles. Ici, la couverture est tracée dans un ledger, les runs sont additifs (le skill réutilise les audits précédents pour cibler les trous) et chaque affirmation finale repasse par un agent indépendant. Sur des projets déjà passés en revue manuellement, le set Cloudflare a ressorti des findings manqués.
L'article de blog de Cloudflare sur son harness, signé Grant Bourzikas, donne des ordres de grandeur pour la version interne : 20 799 candidats générés, 12 057 ayant survécu à la validation. Le taux de rejet initial est passé de 40 % à 11 %. Les agents n'ont invoqué Semgrep aucune fois sur un mois, ce qui suggère que les modèles préfèrent l'analyse dynamique du code. Ces chiffres concernent le harness interne, pas le skill publié.
Un audit par agent deviendra-t-il un step standard en CI ?
Ce genre d'outil a toutes les chances de devenir un step standard dans les pipelines CI d'ici deux ans, comme le SAST et le DAST : un audit par skills entre le lint et les tests, sur chaque merge.
N'oublions pas qu'un outil ne fait pas tout. Cloudflare le rappelle sur son blog : le skill a grandi jusqu'à tourner à l'échelle de leur flotte, mais leur vrai atout reste la discipline du process plutôt que le modèle sous le capot.
Ce que ça change pour vos équipes
Un harness d'audit ouvert à tous : la question n'est plus de savoir si vos agents vont auditer votre code, mais quand. Pour nous, qui concevons, sécurisons et opérons des plateformes en production, l'intérêt est de pouvoir reproduire la discipline plutôt que de croire un modèle sur parole. La même logique de contrôle s'applique aux agents eux-mêmes, comme dans le cas des agents fantômes et de RSA Agent ID, et la chaîne d'approvisionnement reste une classe d'attaque centrale, comme le montre l'affaire des paquets malveillants sur RubyGems.
Mesures que nous appliquons :
- Commencer par un audit sur un dépôt déjà revu à la main, pour mesurer ce que l'agent retrouve et ce qu'il ajoute.
- Traiter chaque finding « needs_validation » comme une tâche humaine, sans sévérité tant que le fait manquant n'est pas établi.
- Exiger une preuve rejouable avant tout ticket : trace du code et résultat observé.
- Exécuter l'agent d'audit avec des droits en lecture seule sur le dépôt et sans accès aux secrets de production.
- Conserver le registre de couverture et les rapports en artefacts de pipeline, pour que chaque run reparte des précédents.