swarm-audit

Audit en essaim

Inventaire → découpage en sections → un worktree et un agent d'audit par section → chaque agent rapporte les faiblesses validées à l'orchestrateur → audit en chaîne sur toutes les faiblesses → un rapport combiné. L'orchestrateur est le worktree dans lequel vous démarrez. Montrez chaque artefact à l'utilisateur avant de passer à la suite ; c'est lui qui décide du périmètre et du regroupement.

0. Prévol

Avant toute chose, réglez trois points. Posez chaque question ouverte dans un seul appel AskUserQuestion (ou simplement si aucun outil de question n'est disponible), puis arrêtez-vous jusqu'à la réponse de l'utilisateur.

Modèle de menace. Cherchez **/THREAT_MODEL.md, en ignorant les répertoires de dépendances vendues ou installées. S'il en existe un sans les placeholders <…> de template, utilisez-le. Sinon, demandez, sauf si l'utilisateur a déjà demandé un passage rapide :

• Construire un modèle de menace d'abord (Recommandé) : chaque auditeur de section et critique utilise ses contrôles et sa liste hors-périmètre, ce qui réduit les faux positifs dans tout l'essaim et révèle les bugs de logique métier. Coûte quelques tours de questions au début ; les audits ultérieurs le réutilisent.
• Passage rapide sans modèle de menace : pas de questions ni de modèle de menace ; les auditeurs de section travaillent à partir de l'inventaire et du code seuls. Le moyen le plus rapide de voir ce que l'essaim trouve ; attendez-vous à plus de bruit.

Sur Construire, exécutez le skill security-audit fourni avec ce plugin via l'outil Skill dans l'orchestrateur, en demandant uniquement un modèle de menace, et attendez THREAT_MODEL.md avant l'étape 1.

Stratégie de découpage. Si les arguments contiennent --by-group [N] ou --by-theme, utilisez-les. Sinon, demandez :

• Par thème (Recommandé) : les sections suivent ce que fait le code (auth, compte, paiements, commandes, admin, une par intégration tierce). Chaque auditeur voit un flux complet, donc les bugs qui s'étendent sur plusieurs points d'entrée sont trouvés. Les tailles varient.
• Par groupe : groupes de taille fixe d'environ N points d'entrée (demandez N, par défaut 25) dans l'ordre source. Charge de travail égale par auditeur, pas de décisions subjectives, mais un même flux peut être coupé en deux sections ; l'audit en chaîne (étape 6) en récupère une partie.

Périmètre. Si l'utilisateur n'en a nommé aucun, demandez quels services, répertoires ou types de points d'entrée couvrir, et quoi exclure.

1. Inventaire des points d'entrée

Un point d'entrée est tout endroit par lequel des données externes atteignent le code : routes HTTP, gestionnaires GraphQL/RPC, webhooks, consommateurs de files d'attente et d'événements, jobs planifiés qui lisent des données externes, commandes CLI, processeurs de fichiers ou d'uploads, gestionnaires de messages côté client, de liens profonds ou IPC.

• Trouvez-les avec un analyseur syntaxique du langage du dépôt (son compilateur ou son API de serveur de langage, ou tree-sitter), pas avec des regex : les enregistrements s'étendent sur plusieurs lignes et prennent des tableaux. Gardez le script dans le bloc-notes (scratchpad) pour pouvoir le relancer.
• Par point d'entrée, enregistrez : type, nom ou méthode + chemin, qui peut y accéder (public, connecté, admin, interne, webhook signé), gardes (auth, MFA, captcha, limite de débit, schéma d'entrée, vérification de signature), gestionnaire, toute la chaîne intergicielle (middleware, décorateur, filtre ou intercepteur), fichier:ligne.
• Facile à manquer :
  • routeurs, contrôleurs ou groupes de gestionnaires imbriqués enregistrés sous un préfixe, et fonctions auxiliaires qui enregistrent sur un objet passé
  • gestionnaires enregistrés globalement dans une fonction auxiliaire : pas de préfixe
  • intergiciels, filtres ou gardes hérités d'un enregistrement antérieur au niveau du préfixe ou de rattrapage général
  • un groupe de gestionnaires enregistré deux fois : listez-le une fois, notez l'alias
  • points d'entrée conditionnés par l'environnement (staging, debug, feature flags) : marquez-les
  • points d'entrée enregistrés par une dépendance (serveurs d'auth, panneaux d'administration, vérifications de santé, tableaux de bord de jobs) : lisez le source du paquet, ajoutez-les manuellement
• Trouvez ce qui manque : grep le code client (application web, application mobile, proxy, autres services) pour chaque chemin ou message qu'il envoie, et listez tout ce qui est enregistré au niveau supérieur. Demandez à l'utilisateur quoi ajouter ; dites ce que vous avez omis et pourquoi.
• Écrivez l'inventaire dans entry-points.md (ou le nom donné par l'utilisateur) dans le worktree de l'orchestrateur.

2. Découpage en sections

• Par thème : regroupez par ce que fait le code, pas par taille, et ne mélangez jamais deux limites de confiance (public, partenaire, interne, worker) dans une même section. Divisez un thème trop grand pour un seul auditeur.
• Par groupe : découpez l'inventaire dans l'ordre en groupes d'environ N ; gardez les points d'entrée d'un même fichier ensemble lorsque cela ne change le groupe que de quelques unités.
• Montrez le découpage proposé (nom, nombre, une ligne de contenu, décisions subjectives) et attendez l'approbation avant de l'écrire dans le fichier d'inventaire.

3. Un worktree par section

Créez le worktree de chaque section à partir du commit actuel de l'orchestrateur, afin que chaque section audite le code sur lequel l'utilisateur se trouve. Utilisez mori quand command -v mori le trouve, sinon git simple :

	mori	git
Créer	mori new sec-audit-NN-<nom> --from <branche courante> ; il affiche le chemin du worktree (sous ~/.mori/worktrees/<depot>/) — enregistrez-le	git worktree add ../<depot>-sec-audit-NN-<nom> -b sec-audit-NN-<nom>
Dépendances	installées par les étapes post_create du .mori.json du dépôt si présentes ; sinon, installez-les vous-même	installez-les vous-même
Supprimer	vérifiez dirty dans mori list --json, puis mori remove <branche> -f ; supprimez la branche si elle reste	vérifiez git status dedans, puis git worktree remove <rep> et git branch -D <branche>

Sur un HEAD détaché, utilisez git (git worktree add <rep> -b <branche> HEAD). Créez les worktrees en arrière-plan.

• Copiez dans chacun : AUDIT_SCOPE.md (le tableau de la section, les notes de colonne, « auditez uniquement ces points d'entrée »), l'inventaire complet, et, si le modèle de menace a été construit mais pas encore engagé, une copie au même chemin.
• Créez la boîte de réception dans l'orchestrateur : <orchestrateur>/.security-audit/swarm/<section>/.
• Pour refaire le découpage : supprimez les anciens worktrees et leurs branches comme ci-dessus (ne forcez jamais la suppression d'un worktree avec des modifications que vous n'avez pas examinées), puis recréez.

4. Exécution des audits de section en parallèle

Écrivez une courte instruction dans le bloc-notes et lancez un agent en arrière-plan par section pointant dessus. L'instruction doit dire :

• Travaillez uniquement dans WORKTREE ; lisez ses instructions d'agent (CLAUDE.md, AGENTS.md). Les seules écritures en dehors de WORKTREE vont dans INBOX (chemin absolu vers la boîte de réception de la section dans l'orchestrateur).
• Utilisez le skill security-audit fourni avec ce plugin (ou un autre nommé par l'utilisateur), via l'outil Skill, limité à @AUDIT_SCOPE.md ; sur un passage rapide, dites-lui qu'il s'agit d'un passage rapide pour qu'il ne s'arrête jamais pour demander. Sans modèle de menace : tracez chaque entrée de la source au puits avec fichier:ligne, prouvez qu'elle est atteignable au-delà de chaque contrôle, jetez tout ce qui n'est pas atteignable.
• Avec un modèle de menace : lisez-le en entier avant de tracer ; utilisez ses points d'entrée, ses contrôles et sa liste hors-périmètre ; ne le réécrivez jamais. Passage rapide : pas de modèle de menace, n'en créez pas. Ne posez jamais de questions.
• Chaque candidat va à un sous-agent critique frais qui suppose un faux positif ; si un sous-agent ne peut pas être lancé, autocritiquez-vous et dites-le par constatation.
• Critique/Élevée : un test échouant via le point d'entrée réel, exécuté avec le lanceur de tests du dépôt, laissé dans l'arbre.
• Signalez chaque constatation dans INBOX dès que son critique revient, un fichier par constatation (NN-<slug>.md), afin que rien ne soit perdu si la sortie de l'agent est coupée. Format ci-dessous.
• Signalez également les candidats bloqués : un flux qui atteint un puits mais a besoin de quelque chose que la section ne peut pas fournir (un id, un jeton, une action de victime, une valeur divulguée, une condition de course). Utilisez status: blocked et nommez exactement ce qui manque ; une autre section peut le fournir.
• Écrivez également le rapport de section dans WORKTREE/.security-audit/<section>-<date>.md.
• Règles strictes : suivez les règles de sécurité du dépôt ; pas de migrations ni de scripts de base de données, pas d'écritures git, pas d'appels à des services externes.
• Message final : ligne de verdict, une ligne par constatation, combien de fichiers sont allés dans INBOX, éléments non vérifiés, et comment le skill d'audit a été invoqué.

Format du fichier de constatation :

---
id: <section>-NN
status: validated | blocked
severity: critical | high | medium | low | info
critic: independent | self
entry_point: <méthode + chemin ou nom du gestionnaire>
needs: <ce que l'attaquant doit avoir avant : type de compte, id, jeton, clic de victime, timing>
gives: <ce que l'attaquant a après : valeur divulguée, accès en écriture, session, argent, exécution de code>
test: <chemin ou none>
---
Affirmation en une ligne.

Trace : source `fichier:ligne` → … → puits `fichier:ligne`.
Repro : entrée exacte (requête, message, fichier) dans un bloc de code.
Contrôles vérifiés : ce qui a été examiné et pourquoi cela n'arrête pas ceci.

needs et gives sont ce que l'audit en chaîne relie ensemble : écrivez-les concrètement (« un id de commande d'une victime », pas « des données »).

Vous pouvez auditer une section vous-même en ligne. Attendez-vous à ce que la limite de sous-agents simultanés bloque certains critiques.

5. Re-vérification avant le chaînage

Lorsque chaque agent de section a terminé, lisez la boîte de réception et comparez les nombres de fichiers avec le message final de chaque agent. Ensuite, exécutez vous-même un nouveau critique sur :

• toute constatation Haute ou Critique avec critic: self
• toute constatation marquée provisoire, conditionnelle ou « dépend de » : lisez le code de ce service si vous l'avez et réglez la question. Les bugs à la frontière entre deux services sont ceux que chaque section manque seule.

Mettez à jour le fichier de constatation avec la sévérité du critique et conservez l'originale dans une ligne was:.

6. Audit en chaîne

Un dernier audit dans l'orchestrateur sur toute la boîe de réception, avec l'inventaire et le modèle de menace (s'il y en a un) à portée de main. Exécutez-le en ligne ou comme un agent avec la boîte de réception complète dans son instruction.

1. Déduplication. Fusionnez les constatations ayant la même cause racine (même puits et même contrôle manquant) en une seule, listant chaque section et point d'entrée qui la déclenche. Deux points d'entrée dans un même bug sont une seule constatation avec un rayon d'explosion plus large, pas deux constatations.
2. Assemblage. Pour chaque paire, vérifiez si le gives d'une constatation satisfait le needs d'une autre, y compris les candidats blocked. Recherchez également les escalades habituelles :
   • fuite d'informations (id, email, jeton, URL interne) → IDOR, prise de contrôle de compte ou SSRF qui en avait besoin
   • énumération d'utilisateurs + limite de débit manquante → credential stuffing ou force brute OTP
   • auto-XSS ou injection HTML + CSRF ou CSRF de connexion → XSS persistante sur une victime
   • redirection ouverte + flux OAuth ou lien magique → vol de jeton
   • affectation massive ou validation faible + un consommateur privilégié en aval (worker, vue admin, webhook)
   • condition de course + solde, coupon, limite ou action unique → gain répété
   • deux lacunes de logique métier à faible impact qui ensemble déplacent de l'argent ou contournent une limite
3. Prouvez chaque chaîne. Tracez-la de bout en bout avec fichier:ligne à chaque maillon et l'entrée exacte à chaque étape. Un maillon qui n'est pas dans le code n'est pas une chaîne : n'en inventez pas, et ne comptez pas un maillon qui nécessite une précondition qu'aucune constatation ou action publique ne fournit.
4. Critiquez chaque chaîne avec un nouveau sous-agent, en parallèle. Il suppose que les étapes ne se connectent pas en pratique (utilisateurs différents, sessions différentes, jetons expirés, ordre, une étape déjà corrigée par un autre contrôle) et retourne la sévérité de la chaîne : impact du gain final × probabilité de toutes les étapes ensemble, ou « cleared ».
5. Testez chaque chaîne Critique ou Haute avec un test échouant qui exécute chaque étape via les points d'entrée réels, dans le worktree de l'orchestrateur.
6. Écrivez chaque chaîne dans <orchestrateur>/.security-audit/swarm/chains/NN-<slug>.md au format de constatation, avec links: listant les ids des constatations. Conservez également les constatations composantes.

7. Rapport combiné

Écrivez .security-audit/<perimetre>-combined-<date>.md dans l'orchestrateur :

1. Ligne de verdict avec les comptes après déduplication, les chaînes comptées séparément ("3 chaînes, 2 augmentent la sévérité"). Sur un passage rapide, commencez par la ligne de passage rapide du references/REPORT_FORMAT.md du skill security-audit.
2. Chaînes en premier : les étapes sous forme de liste numérotée avec l'entrée et fichier:ligne, gain final, sévérité avant et après chaînage, critique, chemin du test. Dites quelle correction unique brise chaque chaîne.
3. Rapports critiques/élevés : repro avec l'entrée exacte, trace avec fichier:ligne, gain et prérequis, correction, critique, chemin du test et ce que le test ne prouve pas.
4. Tableau des moyennes, liste des basses (repliée), candidats bloqués que rien n'a débloqués (repliée : ce sont des pistes, pas des constatations).
5. Motifs récurrents entre sections.
6. Lacunes de couverture et éléments non vérifiés (agents interrompus, décalages de comptage dans la boîte de réception, configuration de production, comportement de tiers, critiques auto-examinés).
7. Tableau des sections avec le chemin du rapport dans chaque worktree.

Rien n'est engagé (committed). Menez le résumé de chat avec les chaînes et le tableau des critiques/élevés, et dites quelle correction déployer en premier : privilégiez celle qui brise le plus de chaînes.