Zum Hauptinhalt springen

Cloudflares security-audit-Skill: Adversariale KI-Sicherheitsaudits mit Claude Code (2026)

Fortgeschritten
What you'll learn
  • Erklären, warum 'bitte finde Schwachstellen' selbstbewussten Müll produziert und was die Gewaltenteilung zwischen Huntern und Verifiern behebt
  • Die sechs Phasen durchgehen und das Artefakt benennen, das jede erzeugt, von architecture.md bis NEEDS-VALIDATION.md
  • Eine findings.json richtig lesen: was confirmed, needs_validation und rejected jeweils verlangen und warum nur confirmed-Einträge eine Schwere bekommen
  • Den Skill in Claude Code in einer Sandbox ausführen, die seine Regeln erfüllt, die Ausgaben mechanisch validieren und für mehr Abdeckung erneut laufen lassen
  • Budgetieren: wie die Token-Rechnung aussieht, die Regel, die den Skill Hunter verweigern lässt, und die drei Wege, einen Lauf bezahlbar zu halten

Cloudflare hat Mitte September 2026 einen einzelnen Skill als Open Source veröffentlicht, und er wurde zum am schnellsten wachsenden Repo auf GitHub: cloudflare/security-audit-skill stand am 21. September bei 18,5k Sternen, nachdem es an einem Tag 2,4k dazugewonnen hatte, und hatte bereits am 17. September einen Hacker-News-Thread mit 211 Punkten ausgelöst. Der Grund, warum das wichtig ist, ist nicht die Zahl der Sterne. Es ist, dass dieser Skill der Keim des flottenweiten Schwachstellen-Harness ist, den Cloudflare im Juni beschrieben hat — jener, der über 128 Repositories lief und 7.245 umsetzbare Funde hervorbrachte. Der öffentliche Skill ist die Einzel-Repo-Version, die du heute mit Claude Code ausführen kannst.

Es lohnt sich, präzise zu sein, was er ist. Es gibt kein Binary, keine Rules Engine, kein eigenes Modell. Es ist eine SKILL.md plus vierzehn Hunting-Leitfäden und zwei abhängigkeitsfreie Node-Validatoren. Alles, was er tut, tut er, indem er deinen Agenten dazu bringt, isolierte Sub-Agenten mit engen Aufträgen zu starten, und deren Ausgabe erst akzeptiert, nachdem ein anderer Agent versucht hat, sie zu zerlegen.

Warum "finde die Schwachstellen" für sich genommen scheitert​

Cloudflares Juni-Artikel enthält den Satz, der das ganze Design erklärt: Ein unbeschränkter Agent "will edit the source code so its own exploit works, then triumphantly report the bug it just created." Und die begleitende Regel: "If a Hunter is allowed to grade its own homework, it will confidently validate everything it outputs."

Das ist der Fehlermodus jedes One-Shot-Prompts vom Typ "audit my repo". Das Modell, das 80k Token darauf verwendet hat, eine Theorie zu bilden, ist das letzte Modell, das diese Theorie beurteilen sollte. Die Antwort des Skills ist strukturell:

  • Hunter können keine Findings einreichen. Sie liefern Kandidaten zurück und dürfen weder den Ziel-Quellcode noch die Architektur-Notizen, das Ledger oder die Findings-Datei bearbeiten.
  • Verifier dürfen nicht jagen. Ein frischer Verifier erhält einen Kandidaten, die Architekturfakten und das Schema — und sonst nichts, nicht einmal die Schlussfolgerung eines anderen Verifiers. Seine Aufgabe ist es, zu widerlegen.
  • Nichts wird behalten, wenn deterministischer Code es nicht akzeptiert. Der Eltern-Agent schreibt die gemeinsamen Dateien; validate-findings.cjs und validate-coverage-ledger.cjs weisen alles zurück, was das Schema verletzt.

Cloudflares interne Version geht weiter und verwendet für die Validierung ein anderes Modell als für die Entdeckung — mit der Begründung, dass getrennte Gewichte eine unvoreingenommene Zweitmeinung ergeben. Der öffentliche Skill erzwingt das nicht, aber nichts hindert dich daran, die Verifier-Sub-Agenten an ein anderes Modell zu routen.

Die sechs Phasen und was jede hinterlässt​

PhaseWer läuftAusgabe
1. Reconnaissance4 parallele Recherche-Agenten (Stack und Build; Prinzipale und Auth; Eintrittsflächen und Sinks; was offline testbar ist), die nur Fakten zurückliefernarchitecture.md (rund 1.000 Wörter) und ein initialisiertes coverage-ledger.json
2. Abdeckungsgeführtes HuntingWellen isolierter Hunter, je eine oder mehrere Ledger-Units; ein Coverage-Kritiker nach jeder WelleKandidaten mit proposed_verdict, Unit-Dispositionen, Härtungsnotizen, neu entdeckte Lücken
3. KandidatenvalidierungEin frischer Verifier pro eindeutigem Kandidaten-FingerprintEine Entscheidung pro Kandidat: confirmed, needs_validation oder rejected
4. Strukturierte AusgabeNur der Eltern-Agentfindings.json, nach Fingerprint sortiert, schemavalidiert
5. Unabhängige DatensatzverifikationEin frischer Verifier pro confirmed- oder needs_validation-Eintragverified oder replace; jede materielle Ersetzung bekommt einen zweiten frischen Verifier
6. Zielneutrale BerichterstattungDer Eltern-Agent, nachdem Phase 5 bestanden istREPORT.md, FINDINGS-DETAIL.md (nur ab medium aufwärts), NEEDS-VALIDATION.md

Alles landet unter ~/security-audit-skill/<repo-name>/run-<N>/, mit Verzeichnissen agents/<id>/scratch/ und agents/<id>/artifacts/ pro Agent. Nur der Eltern-Agent schreibt die gemeinsamen Dateien.

Das Coverage-Ledger ist der Mechanismus, den die meisten übersehen. Eine Unit ist eine materielle Kombination aus Eintrittsfläche, Vertrauensgrenze, Subsystem und Angriffsklasse, mit Startpfaden im Repo. Units durchlaufen planned, in_progress, blocked, covered oder candidate, und jeder Zustand hat Regeln dazu, welche Evidenzfelder ausgefüllt sein müssen. Ein Coverage-Kritiker liest nach einer Welle das gesamte Ledger und sucht nach nicht erfassten Eintrittspunkten, ungeprüften Parallelpfaden und unbegründeten Ausschlüssen; er kann eine Unit wieder öffnen (und den vorherigen Versuch archivieren), aber niemals ein Finding vorschlagen. Genau das macht Wiederholungsläufe additiv: Ein zweiter Lauf greift die Units auf, die der erste als blocked hinterlassen oder wieder geöffnet hat, statt alles neu zu auditieren.

Die drei Verdikte — und warum nur eines eine Schwere trägt​

Das Schema ist strikt darin, welche Felder jedes Verdikt verwenden darf, und der Validator erzwingt es.

VerdiktBedeutetMuss habenDarf nicht haben
confirmedIn der Sandbox unabhängig aus dem Quellcode reproduziert, nur minimal beobachteter Effektroot_cause, intended_behavior, trace (Entrypoint bis Sink), evidence, conditions, execution, remediation, severity, confidenceclaimed_root_cause, blockers, validation_plan, reason
needs_validationQuellenbasiert, aber blockiert durch genau einen Fakt, der lokal nicht geklärt werden kann (eine Deployment-Einstellung, eine nur dem Eigentümer zugängliche Konfiguration)claimed_root_cause, trace, evidence, blockers, validation_planseverity, execution, remediation
rejectedDer Verifier hat es widerlegtclaimed_root_cause, trace, evidence, reasonseverity, execution, remediation, blockers

Daraus folgen drei Konsequenzen:

  • Ein needs_validation-Finding hat per Design keine Schwere. Es ist kein "medium"; es ist eine Frage an den Code-Eigentümer mit einem exakten Plan, sie zu beantworten. NEEDS-VALIDATION.md existiert, damit diese Liste nicht für eine Schwachstellenliste gehalten wird.
  • Schwere verlangt nachgewiesene Auswirkung, kein verfehltes Checklisten-Item. Die Kalibrierung in SKILL.md: critical ist unauthentifizierte Codeausführung, vollständiger Datenzugriff oder Account-Übernahme; high ist die vollständige Aushebelung einer expliziten Kontrolle (Auth-Bypass, mandantenübergreifender Zugriff); medium ist begrenzter Wirkungsradius oder ungewöhnliche Vorbedingungen; low ist Offenlegung nicht geheimer Daten; informational ist eine bestätigte Beobachtung mit minimaler Auswirkung. "Fehlende Best Practice" ist ausdrücklich kein Finding.
  • Ein sauberer Lauf meldet null. Der Reporting-Leitfaden sagt, ein verhältnismäßiger Bericht darf keine bestätigten Findings enthalten und muss das klar sagen. Wenn dein Lauf in einem kleinen Service zwanzig Criticals "findet", verdächtige zuerst das Sandbox-Setup und nicht den Service.

Für Leserinnen und Leser dieses Abschnitts ist der KI/LLM-Hunting-Leitfaden der schärfste Teil. Seine Eröffnungsregel: "Prompt injection alone is not a finding. Require a code-level boundary failure." Ein Hunter muss den Angreifer, den betroffenen Prinzipal, die Ausführungsidentität und eine unautorisierte Aktion oder Offenlegung zeigen — mit einem Quellcode-Trace von der angreiferkontrollierten Eingabe bis zum Seiteneffekt. Die Muster, auf die er Hunter ansetzt, sind die aus unseren Seiten zu Prompt Injection und MCP Tool Poisoning, aber als Code-Defekte formuliert: Tool-Argumente, die ohne handlerseitige Validierung in SQL oder eine Shell gelangen; Sub-Agenten, die volle Zugangsdaten statt minimaler Rechte erben; Tool-Beschreibungen, die als Autorisierung behandelt werden; Modellausgabe, die ohne Kodierung in HTML oder einen Befehl gerendert wird; mandantenübergreifendes Context-Bleed durch zu breite Cache-Keys. Das Modell dazu zu überreden, etwas Unhöfliches zu sagen, zählt nicht.

Die Sandbox-Regel ist kein Ratschlag​

SKILL.md verlangt, dass jeglicher zielkontrollierter Code (Tests, Fixtures, der eigene Build des Projekts) in einer betriebssystemseitig erzwungenen Sandbox läuft: ohne externes Netzwerk, höchstens mit einem isolierten Loopback-Namespace, mit schreibgeschütztem Zielquellcode, mit auf scratch/ beschränkten Schreibzugriffen und mit strikten Grenzen für CPU, Speicher, Prozesse und Dateigröße. Verifiern wird gesagt: Ist die Sandbox nicht verfügbar, bleibt der Kandidat schlicht unvalidiert. Die Beförderung von scratch/ in behaltene artifacts/ verweigert Symlinks, mehrfach verlinkte Dateien, Archive und rekursive Kopien und öffnet nichts erneut über den Pfad.

Das ist dasselbe Bedrohungsmodell wie auf unserer Seite Coding-Agenten unter Angriff, nur nach innen gedreht: Das Repository, das du auditierst, kann feindlich sein, und seine Testsuite ist Code, den du gleich ausführst. In Claude Code heißt das, das Audit mit den Kontrollen für Sandbox und Credential Masking zu fahren und nicht in deiner täglichen Shell mit deinen echten Umgebungsvariablen. Ein Stolperstein aus Cloudflares eigenem Harness gilt, wenn du Docker in einem Container verschachtelst: Es braucht seccomp=unconfined und apparmor=unconfined, "or it will silently fail."

Guided walkthrough1 of 6
  1. npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit. Die skills-CLI (vercel-labs/skills) legt ihn in .claude/skills/ für Claude Code oder in .agents/skills/ für Codex, Cursor und Gemini CLI ab; -g für eine globale Installation, -a claude-code, um einen bestimmten Agenten anzusprechen. Lies SKILL.md, bevor du ihn ausführst: Es ist der Vertrag, den du gleich ausführst.

Auslösephrasen und die Validator-Befehle

# Full audit (creates ~/security-audit-skill/<repo>/run-N/)
security audit this codebase
find security vulnerabilities in ./src

# Guidance mode (no run directory, no sub-agent fleet)
is the session cookie handling in auth/session.ts safe against fixation?

# After a run: mechanical checks, zero dependencies beyond Node
node .claude/skills/security-audit/validate-findings.cjs ~/security-audit-skill/<repo>/run-1/findings.json
node .claude/skills/security-audit/validate-coverage-ledger.cjs ~/security-audit-skill/<repo>/run-1/coverage-ledger.json

# What the schema hard-limits (validator rejects beyond these)
# findings.json: 5 MiB, 1,000 findings, 64 nesting levels
# coverage-ledger.json: 5 MiB, 10,000 units, 1,000 entries per collection

Was es kostet und wie man es bezahlbar hält​

Im HN-Thread geht es vor allem um die Rechnung. Ein Nutzer berichtete: "I threw 1M tokens for nothing in a medium codebase"; ein anderer setzte die praktische Obergrenze bei 150k Token an, "where you start hitting the dumb zone" nachlassender Aufmerksamkeit. Das sind Anekdoten, keine Messungen, aber sie passen zur Form des Designs: vier Recon-Agenten, eine Welle Hunter, ein Verifier pro Kandidat, ein Kritiker pro Welle, dann ein zweiter Verifier pro überlebendem Eintrag. Cloudflares Flottenzahlen geben den ehrlichen Maßstab: Ein Standard-Repository mit 30.000 Zeilen brauchte 3 bis 4 Stunden für rund 100 Rohfunde, und über die Flotte hinweg überlebten 58 % der Rohkandidaten die Validierung (12.057 von 20.799).

Drei Dinge im Skill selbst verhindern, dass er davonläuft:

  1. Die Budgetreserve-Regel. Vor jeder Welle muss der Eltern-Agent Budget für die Hunter, den Validierungsdurchgang, den Kritiker nach der Welle und einen abschließenden Clean-Kritiker reservieren. HUNTING.md sagt: Wenn diese verpflichtenden Reserven nicht hineinpassen, starte aus dieser Welle keinen Hunter und markiere die Units als zurückgestellt, mit dem Budget als Grund. Ein Lauf, der mit zurückgestellten Units endet, ist ein Lauf, der dein Budget respektiert hat — kein kaputter Lauf.
  2. Enge Aufträge. Jeder Sub-Agent bekommt eine Unit oder einen Kandidaten. Cloudflares Harness hielt jeden Agenten unter 25 % seines Kontextfensters und schreibt dem — mehr als jeder Prompt-Formulierung — die Qualität der Funde zu.
  3. Guidance-Modus. Die meisten Sicherheitsfragen brauchen die Pipeline nicht. Stell sie direkt, und der Skill antwortet, ohne irgendetwas zu starten.

Auf deiner Seite: Begrenze den ersten Lauf auf ein Verzeichnis; nutze für die Hunter ein Modell mit großem Kontext und günstigen Cache-Reads und für die Verifier ein stärkeres; setze ein Task-Budget auf die Sitzung; und behandle einen von einem Sitzungslimit abgeschnittenen Lauf als unvollständig, nicht als gescheitert — denn das Ledger hält genau fest, wo er aufgehört hat.

Wo er neben Semgrep, CodeQL und KI-Code-Review steht​

Er ist kein Ersatz für statische Analyse und versucht das auch nicht. Cloudflares Beitrag enthält ein vielsagendes Detail: Sie banden Semgrep in den Harness ein, und die Agenten "ignored it completely" — sie lasen und führten den Code lieber selbst aus. Statische Werkzeuge liefern deterministische, günstige, wiederholbare Abdeckung bekannter Muster; dieser Skill liefert teure, probabilistische, schlussfolgerungsintensive Abdeckung von Grenzverletzungen, die Pattern-Matcher nicht ausdrücken können — mit einem Validierungsschritt, den statische Werkzeuge nicht haben. Fahre beides. Und verwechsle ihn nicht mit Review zur PR-Zeit: Alibabas open-code-review ist ein Diff-Reviewer, der pro Pull Request in Sekunden läuft; dies ist ein mehrstündiges Audit einer ruhenden Codebasis.

Begriffe, die dir im Run-Verzeichnis begegnen
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 8

Teste dich selbst

0/6
  1. Ein Hunter ist überzeugt, einen Auth-Bypass gefunden zu haben. Was darf er damit tun?
  2. Ein Eintrag in findings.json hat das Verdikt needs_validation und die Schwere high. Was ist passiert?
  3. Deine Testsuite macht ausgehende HTTP-Aufrufe. Was sagt der Skill Huntern und Verifiern, was zu tun ist?
  4. Ein Hunter zeigt, dass eine präparierte E-Mail den Assistenten dazu bringt, etwas Anstößiges zu sagen. Nach AI-AND-LLM.md ist das:
  5. Der Lauf endet mit mehreren Units, die als zurückgestellt und mit Budgetgrund markiert sind. Was bedeutet das?
  6. Cloudflares Flottendaten sagen, dass ein einzelner Lauf ungefähr welchen Anteil dessen findet, was wiederholte Läufe finden?

Quellen & weiterführende Literatur​

  • cloudflare/security-audit-skill auf GitHub — README, SKILL.md, die Phasenleitfäden (RECONNAISSANCE.md, HUNTING.md, VALIDATION-AND-REPORTING.md), die vierzehn Angriffsklassen-Leitfäden einschließlich AI-AND-LLM.md, report-schema.json und die beiden Validatoren; MIT
  • Build your own vulnerability harness — Cloudflare-Blog, 18. Juni 2026 (Grant Bourzikas): wie der Skill zum Flotten-Harness heranwuchs, der Trichter von 20.799 über 12.057 zu 7.245, die Zahl von 3–4 Stunden pro 30k-Zeilen-Repo, die "grade its own homework"-Regel sowie die Stolpersteine mit verschachteltem Docker und "200 OK mit Fehler"
  • Hacker-News-Diskussion (item 49736466) — Token-Berichte aus erster Hand und der Widerspruch zu den Kosten
  • vercel-labs/skills — die npx skills add-CLI und wo sie Skills für jeden Agenten installiert
  • Offener Standard für Agent Skills — warum eine einzige SKILL.md in Claude Code, Codex, Cursor und Gemini CLI läuft

Weiter​