trebaud/swarm-audit

Schwarm-Audit

Inventarisieren → in Abschnitte aufteilen → ein Worktree und ein Audit-Agent pro Abschnitt → jeder Agent meldet bestätigte Funde an den Orchestrator → Kettenanalyse über alle Funde → ein kombinierter Bericht. Der Orchestrator ist der Worktree, in dem Sie starten. Zeigen Sie dem Benutzer jedes Artefakt, bevor Sie fortfahren; er entscheidet über Umfang und Gruppierung.

0. Vorbereitung

Klären Sie drei Dinge, bevor Sie etwas anderes tun. Fragen Sie jede offene Frage in einem einzigen AskUserQuestion-Aufruf (einfach, wenn es kein Frage-Tool gibt), und halten Sie dann an, bis der Benutzer antwortet.

Bedrohungsmodell. Suchen Sie nach **/THREAT_MODEL.md, wobei Sie vendor- und installierte Abhängigkeitsverzeichnisse überspringen. Wenn eine Datei existiert, die keine Platzhalter <…> enthält, verwenden Sie diese. Fragen Sie andernfalls, es sei denn, der Benutzer hat bereits eine schnelle Ausführung gewünscht:

• Zuerst ein Bedrohungsmodell erstellen (Empfohlen): Jeder Abschnitts-Auditor und Kritiker verwendet dessen Kontrollen und Out-of-Scope-Liste, was Fehlalarme im gesamten Schwarm reduziert und Geschäftslogik-Fehler aufdeckt. Kostet einige Fragen zu Beginn; spätere Audits verwenden es wieder.
• Schnelle Ausführung ohne Bedrohungsmodell: keine Fragen und kein Bedrohungsmodell; Abschnitts-Auditoren arbeiten nur mit dem Inventar und dem Code. Der schnellste Weg, um zu sehen, was der Schwarm findet; erwarten Sie mehr Rauschen.

Bei Erstellen führen Sie das mit diesem Plugin gebündelte security-audit-Skill über das Skill-Tool im Orchestrator aus und bitten nur um ein Bedrohungsmodell, und warten Sie auf THREAT_MODEL.md vor Schritt 1.

Aufteilungsstrategie. Wenn die Argumente --by-group [N] oder --by-theme enthalten, verwenden Sie sie. Fragen Sie andernfalls:

• Nach Thema (Empfohlen): Abschnitte folgen dem, was der Code tut (Auth, Konto, Zahlungen, Bestellungen, Admin, eine pro Drittanbieter-Integration). Jeder Auditor sieht einen gesamten Ablauf, daher werden Fehler gefunden, die mehrere Einstiegspunkte umfassen. Die Größen variieren.
• Nach Gruppe: gleich große Gruppen von etwa N Einstiegspunkten (N erfragen, Standard 25) in der Quellreihenfolge. Gleichmäßige Auslastung pro Auditor, keine Ermessensentscheidungen, aber ein Ablauf kann auf zwei Abschnitte aufgeteilt werden; die Kettenanalyse (Schritt 6) holt einen Teil davon wieder zurück.

Umfang. Wenn der Benutzer keinen genannt hat, fragen Sie, welche Dienste, Verzeichnisse oder Arten von Einstiegspunkten abgedeckt und welche ausgelassen werden sollen.

1. Inventar der Einstiegspunkte

Ein Einstiegspunkt ist jeder Ort, an dem externe Eingaben den Code erreichen: HTTP-Routen, GraphQL/RPC-Handler, Webhooks, Queue- und Event-Consumer, geplante Jobs, die externe Daten lesen, CLI-Befehle, Datei- oder Upload-Prozessoren, clientseitige Message-, Deep-Link- oder IPC-Handler.

• Finden Sie sie mit einem Parser für die Sprache des Repos (dessen Compiler oder Language-Server-API oder Tree-Sitter), nicht mit Regex: Registrierungen erstrecken sich über Zeilen und akzeptieren Arrays. Behalten Sie das Skript im Scratchpad, damit es erneut ausgeführt werden kann.
• Pro Einstiegspunkt erfassen: Art, Name oder Methode + Pfad, wer ihn erreichen kann (öffentlich, eingeloggt, Admin, intern, signierter Webhook), Wächter (Auth, MFA, Captcha, Ratenbegrenzung, Eingabeschema, Signaturprüfung), Handler, die gesamte Middleware-, Decorator-, Filter- oder Interceptor-Kette, Datei:Zeile.
• Leicht zu übersehen:
  • verschachtelte Router, Controller oder Handlergruppen, die unter einem Präfix registriert sind, und Hilfsfunktionen, die auf einem übergebenen Objekt registrieren
  • global innerhalb einer Hilfsfunktion registrierte Handler: kein Präfix
  • Middleware, Filter oder Wächter, die von einer früheren präfixebenen- oder catch-all-Registrierung geerbt wurden
  • eine Handlergruppe, die zweimal registriert wurde: einmal auflisten, den Alias notieren
  • umgebungsabhängige Einstiegspunkte (Staging, Debug, Feature-Flags): markieren Sie sie
  • Einstiegspunkte, die eine Abhängigkeit registriert (Auth-Server, Admin-Panels, Health-Checks, Job-Dashboards): lesen Sie den Paketquellcode, fügen Sie sie manuell hinzu
• Finden Sie, was fehlt: durchsuchen Sie den Client-Code (Web-App, mobile App, Proxy, andere Dienste) nach jedem Pfad oder jeder Nachricht, die er sendet, und listen Sie alles auf, was auf der obersten Ebene registriert ist. Fragen Sie den Benutzer, was hinzugefügt werden soll; sagen Sie, was Sie ausgelassen haben und warum.
• Schreiben Sie das Inventar in entry-points.md (oder den vom Benutzer angegebenen Namen) im Orchestrator-Worktree.

2. In Abschnitte aufteilen

• Nach Thema: gruppieren Sie nach dem, was der Code tut, nicht nach Größe, und mischen Sie niemals zwei Vertrauensgrenzen (öffentlich, Partner, intern, Arbeiter) in einem Abschnitt. Teilen Sie ein Thema, das für einen Auditor zu groß ist.
• Nach Gruppe: schneiden Sie das Inventar der Reihe nach in Gruppen von etwa N; behalten Sie Einstiegspunkte einer Datei zusammen, wenn dies eine Gruppe nur um wenige ändert.
• Zeigen Sie den vorgeschlagenen Split (Name, Anzahl, eine Zeile Inhalt, Ermessensentscheidungen) und warten Sie auf die Genehmigung, bevor Sie ihn in die Inventardatei schreiben.

3. Ein Worktree pro Abschnitt

Erstellen Sie den Worktree jedes Abschnitts aus dem aktuellen Commit des Orchestrators, damit jeder Abschnitt den Code auditiert, auf dem der Benutzer ist. Verwenden Sie mori, wenn command -v mori es findet, andernfalls einfaches Git:

	mori	git
Erstellen	mori new sec-audit-NN-<name> --from <aktueller Branch>; gibt den Worktree-Pfad aus (unter ~/.mori/worktrees/<repo>/) — notieren Sie ihn	git worktree add ../<repo>-sec-audit-NN-<name> -b sec-audit-NN-<name>
Abhängigkeiten	installiert durch die post_create-Schritte der .mori.json des Repos, falls vorhanden; andernfalls selbst installieren	selbst installieren
Entfernen	dirty in mori list --json prüfen, dann mori remove <branch> -f; Branch löschen, wenn er noch existiert	git status darin prüfen, dann git worktree remove <dir> und git branch -D <branch>

Bei einem detached HEAD verwenden Sie git (git worktree add <dir> -b <branch> HEAD). Erstellen Sie die Worktrees im Hintergrund.

• Kopieren Sie in jeden: AUDIT_SCOPE.md (die Tabelle des Abschnitts, die Spaltennotizen, „nur diese Einstiegspunkte auditieren“), das vollständige Inventar und, falls das Bedrohungsmodell erstellt, aber noch nicht committet wurde, eine Kopie davon am gleichen Pfad.
• Erstellen Sie das Postfach im Orchestrator: <orchestrator>/.security-audit/swarm/<section>/.
• Um den Split zu wiederholen: entfernen Sie die alten Worktrees und deren Branches wie oben (erzwingen Sie niemals das Entfernen eines mit Änderungen, die Sie nicht angesehen haben), und erstellen Sie sie dann neu.

4. Die Abschnittsaudits parallel ausführen

Schreiben Sie eine kurze Anweisung in das Scratchpad und starten Sie einen Hintergrund-Agenten pro Abschnitt, der darauf verweist. Die Anweisung muss besagen:

• Arbeiten Sie NUR im WORKTREE; lesen Sie dessen Agentenanweisungen (CLAUDE.md, AGENTS.md). Die einzigen Schreibvorgänge außerhalb des WORKTREE gehen an INBOX (absoluter Pfad zum Postfach des Abschnitts im Orchestrator).
• Verwenden Sie das mit diesem Plugin gebündelte security-audit-Skill (oder ein anderes, das der Benutzer nennt) über das Skill-Tool, beschränkt auf @AUDIT_SCOPE.md; bei einer schnellen Ausführung teilen Sie mit, dass dies eine schnelle Ausführung ist, damit es nie anhält, um zu fragen. Ohne eines: verfolgen Sie jede Eingabe vom Einstiegspunkt zur Senke mit Datei:Zeile, beweisen Sie, dass sie nach jeder Kontrolle erreichbar ist, verwerfen Sie alles, was nicht erreichbar ist.
• Mit einem Bedrohungsmodell: lesen Sie es vollständig, bevor Sie verfolgen; verwenden Sie dessen Einstiegspunkte, Kontrollen und Out-of-Scope-Liste; schreiben Sie es niemals um. Schnelle Ausführung: kein Bedrohungsmodell, keines erstellen. Stellen Sie niemals Fragen.
• Jeder Kandidat geht an einen frischen Kritiker-Sub-Agenten, der eine Fehlalarmannahme hat; wenn keiner gestartet werden kann, selbst kritisieren und dies pro Fund angeben.
• Kritisch/Hoch: ein fehlschlagender Test durch den echten Einstiegspunkt, ausgeführt mit dem Test-Runner des Repos, im Baum belassen.
• Melden Sie jeden Fund sofort nach Rückkehr seines Kritikers an INBOX, eine Datei pro Fund (NN-<slug>.md), damit nichts verloren geht, wenn die Ausgabe des Agenten abgeschnitten wird. Format unten.
• Melden Sie auch blockierte Kandidaten: ein Ablauf, der eine Senke erreicht, aber etwas benötigt, das der Abschnitt nicht liefern kann (eine ID, ein Token, eine Opferaktion, ein durchgesickerter Wert, eine Race). Verwenden Sie status: blocked und benennen Sie genau, was fehlt; ein anderer Abschnitt kann es möglicherweise liefern.
• Schreiben Sie auch den Abschnittsbericht in WORKTREE/.security-audit/<section>-<date>.md.
• Harte Regeln: befolgen Sie die Sicherheitsregeln des Repos; keine Migrationen oder Datenbankskripte, keine Git-Schreibvorgänge, keine Aufrufe externer Dienste.
• Abschließende Nachricht: Urteilszeile, eine Zeile pro Fund, wie viele Dateien an INBOX gingen, nicht verifizierte Elemente und wie das Audit-Skill aufgerufen wurde.

Format der Funddatei:

---
id: <section>-NN
status: validated | blocked
severity: critical | high | medium | low | info
critic: independent | self
entry_point: <method + path or handler name>
needs: <was der Angreifer vorher haben muss: Kontoart, ID, Token, Opferklick, Timing>
gives: <was der Angreifer danach hat: durchgesickerter Wert, Schreibzugriff, Sitzung, Geld, Codeausführung>
test: <Pfad oder none>
---
Einzeilige Behauptung.

Trace: Quelle `Datei:Zeile` → … → Senke `Datei:Zeile`.
Repro: genaue Eingabe (Anfrage, Nachricht, Datei) in einem Codeblock.
Geprüfte Kontrollen: was angesehen wurde und warum es dies nicht verhindert.

needs und gives sind das, worauf die Kettenanalyse aufbaut: schreiben Sie sie konkret („eine Bestell-ID des Opfers“, nicht „einige Daten“).

Sie können einen Abschnitt inline selbst auditieren. Rechnen Sie damit, dass das gleichzeitige Sub-Agenten-Limit einige Kritiker blockiert.

5. Vor der Verkettung noch einmal prüfen

Wenn alle Abschnitts-Agenten fertig sind, lesen Sie das Postfach und vergleichen Sie die Dateianzahl mit der Abschlussnachricht jedes Agenten. Führen Sie dann selbst eine frische Kritik durch an:

• allen Hoch- oder Kritisch-Einstufungen mit critic: self
• allen Funden, die als vorläufig, bedingt oder „hängt ab von “ markiert sind: lesen Sie den Code dieses Dienstes, wenn Sie ihn haben, und klären Sie die Frage. Fehler an der Grenze zwischen zwei Diensten sind die, die jeder Abschnitt allein übersieht.

Aktualisieren Sie die Funddatei mit der Schwere des Kritikers und behalten Sie das Original in einer was:-Zeile.

6. Kettenanalyse

Ein letztes Audit im Orchestrator über das gesamte Postfach, mit dem Inventar und dem Bedrohungsmodell (falls vorhanden) zur Hand. Führen Sie es inline oder als einen Agenten mit dem vollständigen Postfach in seiner Anweisung durch.

1. Deduplizieren. Führen Sie Funde mit derselben Grundursache (gleiche Senke und gleiche fehlende Kontrolle) zu einem zusammen, und listen Sie jeden Abschnitt und Einstiegspunkt auf, der davon betroffen ist. Zwei Einstiegspunkte für einen Fehler sind ein Fund mit einem größeren Schadensradius, nicht zwei Funde.
2. Verbinden. Prüfen Sie für jedes Paar, ob das gives eines Fundes das needs eines anderen erfüllt, einschließlich blocked-Kandidaten. Suchen Sie auch nach den üblichen Eskalationen:
   • Informationsleck (ID, E-Mail, Token, interne URL) → IDOR, Kontoübernahme oder SSRF, die es benötigte
   • Benutzeraufzählung + fehlende Ratenbegrenzung → Credential-Stuffing oder OTP-Brute-Force
   • Self-XSS oder HTML-Injection + CSRF oder Login-CSRF → gespeichertes XSS auf einem Opfer
   • Offener Redirect + OAuth- oder Magic-Link-Ablauf → Token-Diebstahl
   • Massenzuweisung oder schwache Validierung + ein privilegierter Consumer nachgelagert (Worker, Admin-Ansicht, Webhook)
   • Race-Condition + Guthaben, Gutschein, Limit oder einmalige Aktion → wiederholter Gewinn
   • zwei geschäftslogische Lücken mit geringen Auswirkungen, die zusammen Geld bewegen oder ein Limit umgehen
3. Beweisen Sie jede Kette. Verfolgen Sie sie Ende-zu-Ende mit Datei:Zeile an jedem Glied und der genauen Eingabe bei jedem Schritt. Ein Glied, das nicht im Code ist, ist keine Kette: erfinden Sie keine, und zählen Sie kein Glied, das eine Vorbedingung benötigt, die kein Fund oder keine öffentliche Aktion liefert.
4. Kritisieren Sie jede Kette mit einem frischen Sub-Agenten, parallel. Dieser geht davon aus, dass die Schritte in der Praxis nicht zusammenhängen (verschiedene Benutzer, verschiedene Sitzungen, abgelaufene Token, Reihenfolge, ein Schritt wird bereits durch eine andere Kontrolle abgefangen) und gibt die Schwere der Kette zurück: Auswirkung des endgültigen Gewinns × Wahrscheinlichkeit aller Schritte zusammen, oder „geklärt“.
5. Testen Sie jede als Kritisch oder Hoch eingestufte Kette mit einem fehlschlagenden Test, der jeden Schritt durch die echten Einstiegspunkte treibt, im Orchestrator-Worktree.
6. Schreiben Sie jede Kette in <orchestrator>/.security-audit/swarm/chains/NN-<slug>.md im Fundformat, mit links: der Fund-IDs. Behalten Sie auch die Komponentenfunde.

7. Kombinierter Bericht

Schreiben Sie .security-audit/<scope>-combined-<date>.md im Orchestrator:

1. Urteilszeile mit Zählwerten nach Deduplizierung, Ketten separat gezählt („3 Ketten, 2 erhöhen Schweregrad“). Bei einer schnellen Ausführung beginnen Sie mit der Schnelldurchlauf-Zeile aus references/REPORT_FORMAT.md des security-audit-Skills.
2. Zuerst Ketten: die Schritte als nummerierte Liste mit Eingabe und Datei:Zeile, endgültiger Gewinn, Schweregrad vor und nach der Verkettung, Kritiker, Testpfad. Sagen Sie, welche einzelne Behebung jede Kette unterbricht.
3. Kritisch/Hoch-Ausarbeitungen: Reproduktion mit der genauen Eingabe, Trace mit Datei:Zeile, Gewinn und Voraussetzungen, Behebung, Kritiker, Testpfad und was der Test nicht beweist.
4. Tabelle für Mittel, Liste für Niedrig (eingeklappt), blockierte Kandidaten, die nichts freigegeben hat (eingeklappt: sie sind Hinweise, keine Funde).
5. Muster über Abschnitte hinweg.
6. Abdeckungslücken und nicht verifizierte Elemente (abgeschnittene Agenten, Postfachanzahl-Unstimmigkeiten, Produktionskonfiguration, Drittanbieterverhalten, selbst geprüfte Kritiker).
7. Abschnittstabelle mit dem Berichtspfad in jedem Worktree.

Nichts wird committet. Leiten Sie die Chat-Zusammenfassung mit den Ketten und der Kritisch/Hoch-Tabelle ein, und sagen Sie, welche Behebung zuerst ausgeliefert werden sollte: bevorzugen Sie diejenige, die die meisten Ketten unterbricht.