security-audit : faire exécuter un audit de sécurité en six étapes par un agent de code

À qui ça s'adresse

Utilisez security-audit lorsque vous voulez que l'agent de code actuel travaille comme auditeur de sécurité et termine six étapes — reconnaissance, chasse, validation, rapport, sortie structurée, vérification indépendante — pour trouver des vulnérabilités à impact réel et exploitables. Il orchestre plusieurs sous-agents parallèles ; il ne vous fait pas cliquer à la main un produit de scan non nommé.

Prérequis : le modèle de l'agent de code doit prendre en charge les appels d'outils et les sous-agents parallèles ; la validation de schéma de la cinquième étape a aussi besoin de Node.js, pour validate-findings.cjs. Le matériau ne liste pas de produits d'agent ; il liste des exigences de capacité, donc ne le traitez pas comme exclusif à un logiciel. La page officielle du guide est

https://github.com/cloudflare/security-audit-skill

Premier essai en 3 minutes

La commande d'installation officielle est dans l'extrait :

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

Cette commande écrit un skill, donc elle a des effets de bord. Confirmez que l'environnement courant est l'agent de code que vous utiliserez pour l'audit, puis exécutez. Après l'installation, vérifiez d'abord que la machine a Node.js, car la cinquième étape s'en sert pour lancer validate-findings.cjs.

Ne dites pas tout de suite «pen-test the code» contre un dépôt inconnu. Les demandes qui correspondent à des phrases déclencheurs telles que security audit, find vulnerabilities et pen-test the code s'activent automatiquement. Si vous n'indiquez pas de répertoire de sortie, il demandera, et l'écriture par défaut va vers ~/security-audit-skill/<repo-name>/run-<N>. Cela crée des fichiers sous le répertoire personnel.

Premier essai à bas risque : après une installation réussie, indiquez d'abord un répertoire de sortie vide que vous possédez, et demandez seulement «si on auditait maintenant, où la sortie serait-elle écrite» ; n'autorisez pas le début de modifications de code ni d'envoi de paquets vers l'extérieur. Signal de succès : le skill est installé, l'agent peut reformuler la règle du chemin de sortie par défaut, et il n'a pas commencé les six étapes avant que vous confirmiez le répertoire. Pour un audit complet, confirmez d'abord le dépôt cible et le chemin de sortie, puis utilisez une phrase déclencheur.

Cas d'usage

Cas 1 : lancer un audit sur un dépôt de code que vous possédez. Terminez l'installation officielle, confirmez que Node.js est disponible, donnez un répertoire de sortie clair, puis utilisez l'une des phrases déclencheurs du matériau. Le critère de fin : l'agent est entré dans les six étapes et a laissé la sortie de ce run dans le répertoire indiqué. Ne laissez pas le chemin par défaut écraser d'anciens résultats que vous voulez garder. L'extrait n'écrit pas les commandes internes de chaque étape ; n'inventez pas de scripts concrets de reconnaissance ou de chasse.

Cas 2 : ne garder que les découvertes exploitables. Le matériau exige : ne rapporter que les problèmes que vous pouvez exploiter, et chaque découverte doit avoir un scénario d'attaque concret, pas «un attaquant pourrait théoriquement…». La cinquième étape utilise validate-findings.cjs pour la validation de schéma. Cela contraint la sortie : lancez d'abord la validation, puis décidez quelles entrées restent. Le résumé dit aussi que la vérification adverse doit être faite par un agent autre que le découvreur, mais l'extrait n'écrit pas de commande pour changer d'agent. Le critère de fin de ce cas est «les entrées ont des scénarios concrets et passent le schéma», pas qu'un agent vérificateur a déjà été échangé automatiquement.

Limites d'usage

Les six étapes sont reconnaissance, chasse, validation, rapport, sortie structurée et vérification indépendante. La sortie par défaut est ~/security-audit-skill/<repo-name>/run-<N>. Sans Node.js vous ne terminez pas la validation de la cinquième étape. Sans appels d'outils et sous-agents parallèles, vous n'atteignez pas les exigences d'exécution écrites dans le matériau.

Ne rapportez pas de problèmes théoriques inexploitables. N'utilisez pas la phrase déclencheur pen-test contre une cible non autorisée. Le matériau ne donne pas de liste de clients et ne dit pas comment sauter la validation sans Node.js. Au-delà de ces normes d'installation, de déclenchement, de répertoire de sortie et de rapport déjà écrites, ce guide ne couvre rien.