Cloudflare ouvre son auditeur : l’essentiel, c’est qu’il contredit

Cloudflare a publié cette semaine une skill qui transforme un agent de codage en auditeur de sécurité, et elle est devenue le dépôt à la croissance la plus rapide du classement hebdomadaire de GitHub : environ 16,400 étoiles en sept jours, 51 000 au total. La présentation de l’entreprise est d’une modestie inhabituelle : il s’agit du point de départ mono-dépôt dont son harnais interne de découverte de vulnérabilités a émergé, publié pour que d’autres puissent bâtir le leur.

Ce qui mérite d’être lu n’est pas le catalogue de classes d’attaque, pourtant très complet. C’est le passage sur la manière dont un constat se fait démolir.

Six phases, dont une purement comptable

Le flux de travail est structuré plutôt que conversationnel, et c’est la première chose qui le distingue d’un « demande à Claude de trouver des bugs ».

La première phase est la reconnaissance : cartographier l’architecture, les frontières de confiance, les surfaces d’entrée et, détail inhabituel, consigner le tout dans architecture.md et coverage-ledger.json. La deuxième affecte des chasseurs isolés aux unités de ce registre, note ce que chacun a vérifié, puis lance des critiques de couverture pour trouver ce que personne n’a regardé. La troisième confie chaque candidat unique à un vérificateur neuf dont le travail est de le réfuter. La quatrième écrit des enregistrements confirmed, needs_validation ou rejected dans findings.json et les valide contre un schéma JSON. La cinquième fait vérifier les affirmations finales sur le code source par des agents neufs, et tout remplacement substantiel repasse par un vérificateur indépendant. La sixième dérive les rapports à partir des enregistrements vérifiés.

Les deux validateurs sont de simples scripts Node sans dépendances : validate-coverage-ledger.cjs s’exécute après la création du registre puis à chaque mise à jour, validate-findings.cjs s’exécute en phase quatre et de nouveau après chaque remplacement en phase cinq. Ce sont les fichiers les moins intéressants du dépôt, et la raison pour laquelle le reste tient debout. Un agent incapable de produire un constat conforme au schéma ne peut pas prétendre en avoir trouvé un.

Les trois verdicts sont la vraie conception

La plupart des outils de sécurité pour agents ont deux sorties : une liste de bugs, ou rien. Celui-ci en a trois, et c’est dans la catégorie intermédiaire que se loge la réflexion.

confirmed signifie une trace source complète plus un résultat borné et observé. needs_validation signifie un fait non résolu et précis, sans sévérité attribuée. rejected signifie un candidat activement réfuté, conservé au lieu d’être supprimé.

Le troisième est rare et, à mon sens, juste. Un candidat réfuté est une preuve sur le code : il indique à l’exécution suivante de ne pas y consacrer de temps, et il dit au relecteur ce qui a été examiné. La plupart des outils jettent cela.

Le principe de conception sous-jacent est énoncé sans détour dans le README : ne confirmer que les défaillances de frontière établies, et si une piste ancrée dans le code se bloque, la laisser en needs_validation avec son fait non résolu exact plutôt que de la promouvoir en constat. Une règle voisine précise que les lacunes de défense en profondeur ne sont pas des vulnérabilités : si la couche A bloque l’attaque, l’absence de la couche B n’est qu’une note de durcissement.

Quiconque a lu un rapport de vulnérabilités généré par une machine sait exactement pourquoi ces règles existent. Le mode de défaillance de la revue de sécurité par LLM n’est pas l’oubli de bugs. C’est le bruit confiant : des motifs qui ressemblent à des vulnérabilités, signalés en sévérité élevée, qui font perdre une semaine à une équipe de triage.

La validation adversariale, au pied de la lettre

La phrase la plus importante : l’agent qui contrôle un constat n’est jamais celui qui l’a trouvé.

Ce n’est pas une instruction de prompt, c’est une contrainte d’orchestration, et c’est la seule manière pour ce genre d’outil de produire quoi que ce soit de fiable. Un LLM à qui l’on demande « ce constat est-il correct ? » à propos de sa propre production sera d’accord avec lui-même. Donnez-lui un contexte neuf, une autre instance d’agent et la tâche explicite de réfuter l’affirmation, et vous obtenez quelque chose de plus proche d’une revue de code.

La phase cinq prolonge cela : des agents neufs vérifient les affirmations finales sur le code, et si une affirmation est substantiellement remplacée, un autre vérificateur indépendant contrôle le remplacement. Il y a deux niveaux de séparation entre le chasseur et l’enregistrement qui survit.

Le chiffre honnête

Enfoui dans les principes de conception : lors des tests de Cloudflare, une exécution unique a trouvé environ la moitié des vulnérabilités que des exécutions répétées trouvaient au total.

Publier cela est un choix. Cela vous dit que l’outil est une machine à couvrir du code, pas un oracle, et cela recadre le flux de travail : on ne le lance pas une fois avant une release, on le lance de façon répétée et on laisse les registres s’accumuler. Le dépôt le prend explicitement en charge : plusieurs exécutions sur le même dépôt sont additives, elles utilisent les registres et constats antérieurs pour viser les manques, revalident le code modifié et reportent les preuves du code actuel sans traiter un travail périmé comme couvert.

La moitié est aussi une estimation raisonnable pour des auditeurs humains au premier passage, ce qui est soit rassurant, soit accablant selon ce que vous pensez du métier.

L’exigence qui arrêtera la plupart des gens

Le README énumère une exigence stricte que la plupart des utilisateurs sauteront avant de s’y heurter : un bac à sable imposé par le système d’exploitation pour les builds, les tests, les processus, les navigateurs, les émulateurs, les fuzzers et les fixtures, le réseau externe désactivé, un environnement assaini sur liste blanche, des limites de ressources appliquées et des écritures restreintes à des chemins temporaires.

Sans ces contrôles, le flux de travail garde la piste en needs_validation au lieu d’exécuter le code cible. C’est la bonne décision, on fait quand même tourner les suggestions d’un modèle de langage contre une base de code, mais cela signifie que l’outil se dégrade en exercice d’analyse statique et de raisonnement pour quiconque n’a pas d’infrastructure de conteneurs.

Cela signifie aussi que ce n’est pas un outil pour ordinateur portable, malgré la ligne d’installation en npx. L’installation tient en une commande :

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

Et l’usage consiste simplement à demander :

security audit this codebase

Le contraste est étrange : l’invocation est une phrase, les prérequis sont une politique de bac à sable. C’est dans cet écart que passera l’essentiel de l’effort de déploiement.

À quoi ressemble réellement la sortie

Trois artefacts, dérivés plutôt qu’écrits : REPORT.md, FINDINGS-DETAIL.md et NEEDS-VALIDATION.md, plus le findings.json sous-jacent et le registre de couverture.

Cette séparation est plus utile qu’elle n’en a l’air. Un rapport unique force chaque constat dans le même registre, ce qui aboutit à une injection SQL critique juste à côté d’un en-tête CSP manquant. Séparer les constats confirmés, les questions ouvertes et les synthèses dérivées signifie que celui qui lit NEEDS-VALIDATION.md sait qu’il regarde du travail en cours, pas des résultats.

Le répertoire de sortie par défaut est ~/security-audit-skill/<repo-name>/run-<N>, et le flux de travail n’écrit dans le dépôt cible que si vous le pointez explicitement vers un répertoire ignoré par git. Petit détail, instinct juste : les artefacts d’audit dans un dépôt finissent commités par accident, et une liste commitée de vulnérabilités non corrigées est un incident à elle seule.

Comment savoir si cela a marché

Lancez-le deux fois. C’est le test que le README suggère sans l’énoncer : comme les exécutions s’additionnent et qu’une seule trouve environ la moitié, la deuxième exécution sur le même commit mesure directement la couverture de l’outil sur votre code. Si la seconde ne remonte rien de neuf, soit votre code est propre, soit les classes de chasse ne correspondent pas à votre stack.

Regardez ensuite le journal des rejets. Une exécution qui confirme cinq problèmes et rejette quarante candidats fait son travail. Une exécution qui en confirme quarante et n’en rejette aucun a cessé de vérifier, et vous devriez lire ces quarante à la main avant d’en croire un seul.

Ce que cela dit de la catégorie

Trois choses, brièvement.

Les skills d’agents deviennent un mode de distribution. Ce n’est pas une bibliothèque que l’on importe, c’est un dossier de markdown et deux scripts de validation qu’un modèle lit à l’exécution. Le dépôt, c’est une vingtaine de fichiers d’instructions plus des catalogues de classes d’attaque découpés par cible : sûreté mémoire et binaire, surfaces LLM et agents, protocoles web et authentification, côté client, chaîne d’approvisionnement, cloud et déploiement, RPC et messagerie, épuisement de ressources, isolation des données, poste de travail et IPC local. Cette structure est le produit.

La vérification devient le facteur différenciant. Chaque éditeur sait désormais générer un constat plausible. Presque aucun ne peut vous dire lesquels ont survécu à une passe adversariale, écrits selon un schéma, avec les réfutés conservés.

Et l’habitude du chiffre honnête se répand. Un éditeur qui publie « nous n’avons trouvé que la moitié » est un éditeur dont la prochaine affirmation est plus crédible.

Le dépôt est sous licence MIT, ce qui signifie que la question intéressante n’est pas de savoir s’il fonctionne, mais si votre équipe peut se payer le bac à sable dont il a besoin pour fonctionner correctement.