Cloudflare Security Audit Skill: Sicherheitsaudit mit Claude Code

Cloudflare hat im Juni 2026 den Skill veröffentlicht, mit dem das Unternehmen seine automatisierte Schwachstellensuche begonnen hat. Das Repository cloudflare/security-audit-skill hat inzwischen rund 38.500 Sterne auf GitHub, davon rund 16.700 im letzten Monat. Der Skill macht aus einem Coding-Agenten wie Claude Code einen Prüfer, der den Quellcode in sechs Phasen untersucht: Aufklärung, Suche nach Schwachstellen, unabhängige Gegenprüfung, strukturierte Ausgabe, zweite Verifikation und Bericht. Diese Anleitung zeigt, wie Sie den Skill auf einem festen Stand installieren, ein eigenes Projekt prüfen lassen, die Ergebnisse lesen und den Skill aktuell halten. Der Haken: Ein vollständiger Lauf startet viele Unteragenten und verbraucht entsprechend Kontingent, und er ersetzt keinen Penetrationstest.

Voraussetzungen

• Claude Code auf macOS, Linux oder Windows mit WSL2, angemeldet und mit genug Kontingent für mehrere parallele Unteragenten. Im Test lief Claude Code 2.1.201 mit dem Modell claude-opus-4-8.
• Node.js für die beiden Validatoren validate-findings.cjs und validate-coverage-ledger.cjs. Sie kommen laut Projekt ohne weitere Pakete aus. Im Test lief Node.js v26.12.1. Wer stattdessen über die Skills-CLI installiert, braucht laut deren Dokumentation Node.js 22.20 oder neuer.
• Git und ein Git-Repository mit dem Code, den Sie prüfen wollen. Git setzt den Skill auf einen festen Commit und hält den geprüften Stand fest.

Eckdaten	Wert
Repository	github.com/cloudflare/security-audit-skill, Lizenz MIT
Stand im Test	Commit c1c8a8c1 vom 14.09.2026 (keine Releases, keine Tags)
Umfang	20 Dateien: SKILL.md, 14 Methodik-Dateien, Schema, zwei Validatoren mit Tests
Ausgabe	Standard ~/security-audit-skill/<repo-name>/run-<N>
Profile	quick, standard (Vorgabe), deep

Schritt 1: Skill holen und Stand festlegen

Ein Skill ist eine Sammlung von Anweisungen, die Ihr Agent mit vollen Rechten ausführt. Lesen Sie deshalb vor der Installation zumindest SKILL.md und setzen Sie einen festen Commit, statt blind dem Hauptzweig zu folgen. Das Projekt veröffentlicht keine Releases, der Commit ist der einzige feste Bezugspunkt.

mkdir -p ~/werkzeuge && cd ~/werkzeuge
git clone -q https://github.com/cloudflare/security-audit-skill.git
cd security-audit-skill
git checkout -q c1c8a8c1
git log -1 --format='%H %cI %s'

Verifizieren: Die letzte Zeile zeigt genau diesen Commit:

c1c8a8c1471069fb0e188eeaff69b8e8db6564a8 2026-09-14T20:28:54+01:00 Clarify guidance and full audit modes

Schritt 2: Skill im Projekt installieren

Claude Code lädt Projekt-Skills aus .claude/skills/<name>/SKILL.md im Startverzeichnis und in den übergeordneten Verzeichnissen bis zur Repository-Wurzel. Der Ordnername oder das Feld name in SKILL.md wird zum Befehl, hier beides security-audit, also /security-audit. Kopieren Sie nur den Unterordner des Skills in Ihr Projekt. Im Test war das eine kleine Flask-API namens notizen-app mit absichtlich eingebauten Schwachstellen.

cd ~/projekte/notizen-app
mkdir -p .claude/skills
cp -R ~/werkzeuge/security-audit-skill/skills/security-audit .claude/skills/
grep -qxF '.claude/skills/security-audit/' .git/info/exclude || echo '.claude/skills/security-audit/' >> .git/info/exclude
ls .claude/skills/security-audit | wc -l

Der Eintrag in .git/info/exclude wirkt wie .gitignore, bleibt aber lokal. Git führt den Skill nicht als neue Datei, er landet nicht in Ihren Commits, und das Projekt bleibt ohne eigenen Commit sauber. Wer den Skill für das ganze Team einchecken will, lässt die Zeile weg und committet den Ordner.

Laut Projektdokumentation geht die Installation auch über die Skills-CLI. Ohne weitere Angabe holt sie den aktuellen Stand des Standardzweigs statt eines festen Commits:

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

Die CLI fragt dabei nach dem Installationsort (Project oder Global). Ohne Terminal, etwa in einem Skript, bricht sie an dieser Stelle ab, ohne etwas zu installieren. Sie selbst nennt dafür die Schalter --yes (-y) und --global (-g).

Verifizieren: wc -l meldet 20 Dateien:

      20

Claude Code erkennt den Skill danach als Befehl /security-audit. Im Test stand security-audit beim Start in der Befehlsliste der Sitzung, und Claude Code lud den Skill für den Auftrag aus Schritt 4 selbst.

Schritt 3: Ausgabeordner und Rechte festlegen

Der Skill schreibt seine Ergebnisse grundsätzlich außerhalb des Zielrepositorys. Einen Ordner im Projekt akzeptiert er laut SKILL.md nur, wenn Sie ihn ausdrücklich nennen und Git den ganzen Ordner ignoriert. Legen Sie deshalb einen eigenen Ordner an und halten Sie den Stand des Projekts fest, damit Sie nach dem Lauf sehen, dass der Quellcode unverändert ist.

mkdir -p ~/audits
cd ~/projekte/notizen-app
git rev-parse --short HEAD
git status --short

Zur Rolle der Sandbox: Der Skill liest den Code statisch. Builds, Tests oder Prozesse des Zielprojekts startet er nur in einer vom Betriebssystem erzwungenen Isolierung ohne Netzwerk, mit leerer Umgebung, nur lesbarem Ziel und harten Grenzen für CPU, Speicher und Laufzeit. Sonst bleibt ein Verdacht needs_validation. Die Sandbox von Claude Code (/sandbox) reicht dafür allein nicht, laut ihrer Dokumentation erben Befehle darin standardmäßig die Umgebungsvariablen und dürfen im Arbeitsverzeichnis schreiben. Im Test startete der Skill die App nicht, sondern baute die verdächtigen Stellen in kleinen Skripten nach, etwa die Suchabfrage in einer Wegwerf-SQLite im Speicher, ohne den Code des Projekts zu importieren. Ein Prüfagent installierte dafür per pip Flask in eine virtuelle Umgebung, obwohl SKILL.md das Installieren von Abhängigkeiten untersagt.

Verifizieren: git status --short liefert keine Ausgabe, das Projekt ist sauber eingecheckt. Die Kurzform des Commits notieren Sie, sie taucht später im Bericht als geprüfter Stand auf.

Schritt 4: Audit starten

Der Skill kennt zwei Betriebsarten. Bei einer Sicherheitsfrage oder einer gezielten Prüfung arbeitet er im Beratungsmodus und schreibt keine Dateien. Den vollständigen Lauf mit allen sechs Phasen startet er nur, wenn Sie ausdrücklich ein Audit, einen Pentest des Codes oder Berichtsdateien verlangen. Ist die Bitte mehrdeutig, fragt er zuerst nach.

Für einen ersten Lauf ist das Profil quick sinnvoll: eine Welle von Prüfagenten, ein abschließender Lückenprüfer und ein Verifizierer je Verdacht. Ein Budget begrenzt die Zahl der Agentenaufrufe über alle Phasen. Interaktiv starten Sie Claude Code im Projekt und schreiben:

security audit this codebase. Use the quick profile with a budget of 10 agent invocations. Output to ~/audits/notizen-app/run-1

Nicht interaktiv, ohne Rückfragen und ohne die Webwerkzeuge sieht derselbe Auftrag so aus:

cd ~/projekte/notizen-app
claude -p "security audit this codebase. Use the quick profile with a budget of 10 agent invocations. Output to $HOME/audits/notizen-app/run-1" \
  --add-dir ~/audits --permission-mode dontAsk \
  --allowedTools "Read" "Grep" "Glob" "Agent" "Edit(~/audits/**)" "Write(~/audits/**)" "Bash" \
  --disallowedTools "WebFetch" "WebSearch" \
  --output-format stream-json --verbose > ~/audits/lauf1.jsonl

dontAsk lehnt jede Aktion ab, die sonst eine Rückfrage auslösen würde und nicht ausdrücklich erlaubt ist. Edit und Write beschränken die Dateiwerkzeuge auf den Ausgabeordner. Bash muss dagegen ohne Einschränkung frei sein: Der Skill legt damit seine Unterordner an, liest den Git-Stand, ruft die Validatoren auf und baut Verdachtsfälle lokal nach. Ein erster Testlauf mit Bash nur für node und einzelne git-Befehle endete ohne Ergebnisordner. Weil der Agent mit freiem Bash im Projekt alles ausführen kann, starten Sie das Audit nur in einem Wegwerf-Checkout, also einer frischen Kopie des Repositorys ohne .env-Dateien, Zugangsdaten und Produktivdaten. Gesperrt sind nur WebFetch und WebSearch, über Bash erreicht der Agent das Netz weiterhin. Im Test dauerte der Lauf 1068 s, also knapp 18 Minuten, und startete 7 Agenten.

Nennen Sie für jeden Lauf einen neuen Ordner. Der Skill verlangt laut SKILL.md einen neuen Ausgabeordner und zählt nur bei der Vorgabe unter ~/security-audit-skill/ selbst hoch.

Verifizieren: In ~/audits/notizen-app/run-1 lagen im Test der Ordner agents und diese Dateien: FINDINGS-DETAIL.md, NEEDS-VALIDATION.md, REPORT.md, architecture.md, coverage-ledger.json, findings.json, hardening-notes.json, run-metadata.json.

In run-metadata.json stehen Abschlussstatus, verbrauchte Agenten und die Zahl der Funde (Auszug):

{
  "run_id": "notizen-app-run-1",
  "repo": "notizen-app",
  …
  "source_ref": "c22e3359238e6aff69a95ca121323e36551beb47",
  "worktree_dirty": false,
  "profile": "quick",
  …
  "budget": 10,
  …
  "run_status": "complete",
  "agents_spent": {
    "reconnaissance": 0,
    "hunters": 2,
    "final_coverage_critic": 1,
    "candidate_verifiers": 4,
    "total": 7
  },
  …
  "findings_summary": {
    "confirmed": 3,
    "needs_validation": 1,
    "rejected": 0,
    "covered_units": 2,
    "deferred_units": 3
  },
  …
}

Schritt 5: Ergebnisse lesen und prüfen

Lesen Sie zuerst REPORT.md. Der Bericht nennt Profil, Budget, geprüften Commit und ausdrücklich, dass ein quick-Lauf nur ein Teilergebnis ist. Danach folgen eine Tabelle der bestätigten Funde, die offenen Verdachtsfälle ohne Schweregrad, Härtungshinweise und eine Übersicht der geprüften Bereiche. Im Test enthielt die Fundtabelle:

| Severity | Title | Affected boundary | Observed result |
|---|---|---|---|
| **Critical** | SQL injection in `GET /api/search` (`q`) | Per-user note confidentiality + credential store | UNION dump of `users.token` for all accounts → cross-account takeover |
| **High** | Broken object-level authorization (IDOR) in `GET /api/notes/<note_id>` | Per-user note confidentiality | Any token holder reads any note's title+body by id |
| **High** | Path traversal / arbitrary file read in `GET /api/attachments` (`name`) | Filesystem confinement to `uploads/` | Read of files outside `uploads/` (incl. `notes.db` → all tokens, host files) |

Die drei Urteile bedeuten Unterschiedliches. confirmed hat eine vollständige Spur durch den Quellcode und ein begrenztes, beobachtetes Ergebnis, nur diese Funde bekommen einen Schweregrad. needs_validation nennt genau die Tatsache, die aus dem Code allein nicht zu klären ist, im Test die Frage, ob der Produktivbetrieb die App mit debug=True startet. rejected ist ein widerlegter Verdacht. Ein Eintrag aus findings.json sah im Test so aus:

  {
    "verdict": "confirmed",
    "fingerprint": "app.py:search:sqli-q-fstring",
    "title": "SQL injection in GET /api/search via q parameter (f-string query construction)",
    …
    "severity": {
      …
      "overall_severity": "critical"
    },
    …
  }

Die mitgelieferten Validatoren prüfen Aufbau und Pflichtfelder der JSON-Dateien gegen das Schema. Ob ein Fund im Code tatsächlich zutrifft, prüfen sie nicht. Führen Sie sie nach dem Lauf selbst aus:

V=~/projekte/notizen-app/.claude/skills/security-audit
node $V/validate-findings.cjs ~/audits/notizen-app/run-1/findings.json
node $V/validate-coverage-ledger.cjs ~/audits/notizen-app/run-1/coverage-ledger.json

Verifizieren: Beide Validatoren melden keinen Fehler:

PASS: 4 findings valid
PASS: 9 coverage units valid

Prüfen Sie zusätzlich mit git status --short im Projekt, dass der Quellcode unverändert ist. Im Test blieb die Ausgabe nach dem Lauf leer.

Schritt 6: Funde beheben und erneut prüfen

Für jeden bestätigten Fund nennt REPORT.md die kleinste wirksame Änderung im Quellcode, FINDINGS-DETAIL.md ergänzt ab Schweregrad medium einen Regressionsfall. Der Skill ändert den Code selbst nicht. Beheben Sie die Funde, committen Sie und starten Sie einen weiteren Lauf mit neuem Ausgabeordner, dem Sie den ersten Lauf nennen. Läufe gegen dasselbe Repository bauen aufeinander auf: Der Skill liest frühere Ergebnisse, prüft geänderte Stellen neu und übernimmt bestätigte Funde nur, wenn der betroffene Code unverändert ist. Laut Cloudflare fand ein einzelner Lauf in eigenen Tests etwa die Hälfte dessen, was wiederholte Läufe insgesamt fanden.

cd ~/projekte/notizen-app
git add -A && git commit -m "Suche mit gebundenen Parametern"

Starten Sie dann den Befehl aus Schritt 4 mit diesem Auftrag und der Ausgabe nach ~/audits/lauf2.jsonl:

security audit this codebase. Use the quick profile with a budget of 10 agent invocations. Prior run: ~/audits/notizen-app/run-1. Output to ~/audits/notizen-app/run-2

Verifizieren: Es entsteht run-2, und der neue Bericht führt den behobenen Fund nicht mehr als offen. Im Test meldete der zweite Lauf: Die SQL-Injection steht in run-2 als rejected mit dem Vermerk Result: remediated, die beiden anderen Funde bestätigte der Skill am unveränderten Code erneut (re-confirmed). Der zweite Lauf dauerte 1075 s mit 6 Agenten, der Validator meldete PASS: 4 findings valid.

Schritt 7: Skill aktualisieren

Da es keine Releases gibt, aktualisieren Sie über Git und lesen vor dem Kopieren, was sich geändert hat. Zwischen den beiden letzten Ständen vom 10. und 14.09.2026 sah das so aus:

cd ~/werkzeuge/security-audit-skill
git fetch -q origin
git log --oneline HEAD..origin/main
git diff --stat 158eb448 c1c8a8c1

 README.md                        |  2 +-
 skills/security-audit/HUNTING.md |  9 ++++++-
 skills/security-audit/SKILL.md   | 53 ++++++++++++++++++++++++++--------------
 3 files changed, 43 insertions(+), 21 deletions(-)

Passt der neue Stand, wechseln Sie mit git checkout auf den neuen Commit und kopieren den Ordner erneut wie in Schritt 2 (vorher rm -rf .claude/skills/security-audit im Projekt, damit entfernte Dateien nicht liegen bleiben).

Verifizieren: git log -1 --format='%H %cI %s' zeigt den neuen Commit, und ls .claude/skills/security-audit im Projekt listet die erwarteten Dateien.

Troubleshooting

Symptom	Ursache und Lösung
/security-audit fehlt im Menü	Ordner eine Ebene zu tief kopiert (.claude/skills/skills/security-audit) oder Claude Code in einem anderen Verzeichnis gestartet. SKILL.md muss direkt in .claude/skills/security-audit/ liegen.
env: node: No such file or directory, Exit-Code 127	Node.js fehlt oder ist nicht im Pfad. Node.js installieren, mit node --version prüfen, Validatoren erneut ausführen.
Bash is blocked in this session, kein Ergebnisordner	Die Rechteliste erlaubt Bash nur für einzelne Befehle. Der Skill braucht Bash ohne Einschränkung, deshalb "Bash" freigeben und das Audit in einem Wegwerf-Checkout laufen lassen.
Unable to connect to API (ConnectionRefused)	Eine Umgebungsvariable wie ANTHROPIC_BASE_URL zeigt auf einen Proxy, der nicht läuft. Variable mit unset entfernen und den Lauf neu starten.
Lauf endet mit budget_cannot_fund_reconnaissance_and_reserves	Das Budget deckt nicht die vier Aufklärungsagenten plus Lückenprüfer und mindestens einen Verifizierer. Budget erhöhen, Umfang auf Pfade begrenzen oder Profil quick wählen.
Skill fragt nach einem anderen Ausgabeordner	Der genannte Ordner liegt im Repository und ist nicht vollständig von Git ignoriert. Einen Ordner außerhalb nennen.
Agent antwortet nur kurz, keine Dateien	Beratungsmodus. Ausdrücklich ein Audit oder Berichtsdateien verlangen.
Funde bleiben needs_validation	Die entscheidende Tatsache steht nicht im Code, oder es fehlt eine Isolierung mit allen Kontrollen aus SKILL.md. Den genannten Punkt im eigenen Betrieb prüfen, NEEDS-VALIDATION.md nennt dafür einen sicheren Prüfweg.

Häufige Fragen

Ersetzt der Skill einen Penetrationstest?

Nein. Er prüft den Quellcode und lokale Abläufe. Betriebseinstellungen wie Proxy, Identitätsanbieter oder Netzwerktopologie sieht er nicht und markiert davon abhängige Verdachtsfälle als offen. Einen Test gegen die laufende Umgebung schließt er ausdrücklich aus.

Wohin geht mein Quellcode?

Der Skill selbst sendet nichts an Cloudflare, er besteht nur aus Anweisungen, einem Schema und zwei lokalen Prüfskripten samt Tests. Den Code liest aber das Sprachmodell Ihres Agenten, er geht also an dessen Modellanbieter, bei Claude Code in der Regel Anthropic. Für Kundencode klären Sie vorher, ob das vertraglich erlaubt ist.

Funktioniert der Skill auch mit anderen Agenten?

Laut Projekt ist er agentenneutral und braucht ein Modell mit Werkzeugnutzung und parallelen Unteragenten. Die Skills-CLI kennt neben Claude Code unter anderem Codex, Cursor und OpenCode.

Wie viele Agenten startet ein Lauf?

Das hängt vom Profil und vom Projekt ab. SKILL.md sieht vier Aufklärungsagenten, mindestens einen Lückenprüfer und mindestens einen Verifizierer je Verdacht vor, bei standard und deep zwei. Mit einem Budget legen Sie eine Obergrenze fest. Im Test übernahm der Hauptagent die Aufklärung des kleinen Projekts selbst, und der Lauf verbrauchte 7 von 10 Agenten: 2 Prüfer, 1 Lückenprüfer und 4 Verifizierer.

Fazit

Der Security Audit Skill gibt Claude Code einen klaren Ablauf für Sicherheitsprüfungen: Jeder Verdacht wird von einem zweiten Agenten gegengeprüft, und unklare Punkte bleiben als offen markiert statt als Lücke verkauft. Für kleine Teams ist das ein Einstieg, eigene Projekte vor einem Release systematisch durchzusehen. Setzen Sie einen festen Commit, beginnen Sie mit quick und einem Budget, lesen Sie die Berichte kritisch und planen Sie mehrere Läufe ein.

Weiterführende Anleitungen und Quellen

• Claude Code Plugins installieren und nutzen: Marketplace, Scopes, Sicherheit
• Superpowers für Claude Code: Coding-Agenten sauber arbeiten lassen
• KI-Agenten absichern: Prompt-Injection abwehren und LLM-Tools härten
• Container-Images auf Schwachstellen scannen mit Trivy
• GitHub: cloudflare/security-audit-skill
• SKILL.md im getesteten Stand c1c8a8c1
• Cloudflare Blog: Build your own vulnerability harness (18.06.2026)
• Claude Code Dokumentation: Skills
• Claude Code Dokumentation: Sandboxing
• Skills-CLI (vercel-labs/skills)