Cloudflare-Skill trennt Finder und Prüfer
Der MIT-lizenzierte Skill, aus dem Cloudflares Vulnerability-Harness entstand, macht gerade die Runde. Was er kann und was er nicht löst.
Cloudflare hat den Skill "security-audit" als eigenes, MIT-lizenziertes Repository veröffentlicht. Er bringt einen Coding-Agenten durch eine strukturierte Sicherheitsprüfung und trennt dabei bewusst den Agenten, der eine Lücke findet, von dem, der sie bestätigt. Auf Hacker News stand der Beitrag am 17.09.2026 mit rund 200 Punkten und 37 Kommentaren oben, veröffentlicht ist das Repository aber schon seit dem 18.06.2026.
Was der Skill tut
Laut README läuft eine vollständige Prüfung in sechs Phasen:
| Phase | Was passiert |
|---|---|
| 1. Reconnaissance | Architektur, Vertrauensgrenzen und Eingabeflächen landen in architecture.md und coverage-ledger.json |
| 2. Coverage-led Hunting | Isolierte "Hunter"-Agenten bearbeiten Einheiten aus dem Ledger, Coverage-Kritiker suchen Lücken |
| 3. Candidate Validation | Jeder Kandidat geht an einen frischen Prüfer, der versucht, ihn zu widerlegen |
| 4. Structured Output | Funde landen als confirmed, needs_validation oder rejected in findings.json, geprüft gegen ein Schema |
| 5. Independent Record Verification | Frische Agenten verifizieren jede finale Quellenangabe noch einmal unabhängig |
| 6. Target-neutral Reporting | REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md entstehen aus den verifizierten Funden |
Die Trennung zwischen Finder und Prüfer steht im README als eigenes Designprinzip: "Adversarial validation. The agent that checks a finding is never the agent that found it", heißt es im README. Ein Kandidat, der Phase 5 nicht übersteht, zählt nicht als Fund.
Was es dafür braucht
Der Skill nennt sich selbst agent-neutral, seine Begriffe ("Parent", "Task tool", "research"- und "general"-Subagenten) lesen sich aber wie Claude Codes eigenes Task-Werkzeug. Voraussetzungen laut README: ein Coding-Agent mit Tool-Use und parallelen Subagenten, Node.js für die abhängigkeitsfreien Validatoren, und zwingend eine vom Betriebssystem durchgesetzte Sandbox für alles, was Zielcode tatsächlich ausführt, also Builds, Tests, Fuzzer. Kein externes Netzwerk, ein bereinigtes Environment, Schreibrechte nur in einem zugewiesenen Scratch-Verzeichnis. Fehlt eine dieser Kontrollen, bleibt ein Fund als needs_validation stehen statt ausgeführt zu werden. Und ein Lauf reicht ohnehin nicht: Nach Cloudflares eigenen Angaben fand ein einzelner Durchlauf in ihren Tests nur etwa die Hälfte dessen, was mehrere Durchläufe zusammen fanden.
Vom Skill zur Fleet-Harness
Das Repository verweist selbst auf den Cloudflare-Blogpost "Build your own vulnerability harness". Er beschreibt, wie aus diesem anfangs rund 450 Zeilen langen Skill über sechs Wochen eine fleet-weite Pipeline für 128 interne Repositories wurde, mit eigener Datenbank, Deduplizierung und zwei getrennten Modellen für Fund und Prüfung. Wichtig für die Einordnung: Veröffentlicht ist nur der ursprüngliche Skill für ein einzelnes Repository, nicht die interne Fleet-Infrastruktur.
Einwände aus der Diskussion
Die Kommentare sind kein reines Lob. Mehrere Nutzer berichten von hohem Tokenverbrauch, etwa 150.000 Tokens für ein kleineres FastAPI-Projekt oder, in einem anderen Fall, "1M tokens for nothing" bei einer mittelgroßen Codebase. Ein Kommentator merkt an, dass Skills mit explizitem Security-Framing bei manchen Modellen eher Refusals auslösen als neutral formulierte Bug-Class-Prompts. Mehrfach kritisiert wird zudem, wie viele einzelne Skills Cloudflare inzwischen veröffentlicht, mit dem Vorschlag, sie zu einem einzigen mit progressiver Offenlegung zusammenzufassen. Ein Cloudflare-Mitarbeiter antwortete im Thread, das sei bereits in Arbeit.
Was das mit KIberschutz zu tun hat
Wir betreiben mit KIberschutz einen eigenen Service in genau diese Richtung: Open-Source-Projekte halb-autonom prüfen, Funde adversarial von einem getrennten Prüfer bestätigen lassen, dann verantwortungsvoll an die Maintainer melden. Dass ein Anbieter in Cloudflares Größenordnung beim selben Prinzip landet, Finder und Prüfer strikt zu trennen und nur belegte Funde zu zählen, bestätigt uns in diesem Ansatz.
Was ein Skill allein nicht löst, zeigt unser eigener erster Fall bei logtide genauso wie dieser Beitrag zur Bugonomics-Verschiebung: Das Finden ist der billige Teil geworden. Triage beim Maintainer, die Wahl des Disclosure-Wegs und vor allem die Kapazität, tatsächlich zu patchen, bleiben menschliche Engpässe. Cloudflares eigene Zahlen zeigen das deutlich. Von 20.799 rohen Kandidaten überstanden laut Blogpost rund 12.057 die Validierung, also knapp 60 Prozent. Die gemeinsame Triage-Datenbank hält inzwischen 13.841 Funde aus 145 Repositories, und Cloudflare nennt das Abarbeiten dieser Menge selbst ein eigenes großes Engineering-Problem. Wer nur den Hunt-Teil kopiert, baut sich vor allem eine Fundflut. Wie kurz das Zeitfenster zwischen einem öffentlich werdenden Fund und dem ersten Angriffsversuch inzwischen sein kann, steht in Zehn Minuten vom Patch zum Angriff.
Was das für euch heißt
Für den eigenen Code lohnt sich so ein Skill am ehesten dort, wo ihr die Funde auch selbst versteht und patchen könnt, etwa vor einem Release oder als regelmäßiger Backlog-Sweep statt als Pflichtprüfung bei jedem Pull Request. Cloudflare selbst schreibt, ein voller Lauf über ein komplexes Repository dauere Stunden, der langsamste knapp vierzehn. Das ist kein Werkzeug für die schnelle Pipeline-Prüfung.
Für fremden Code, also Abhängigkeiten oder Open-Source-Projekte, die ihr einsetzt, aber nicht pflegt, bringt der Skill wenig, wenn niemand die Funde verantwortungsvoll weiterträgt. Ohne einen sauberen Meldeweg zum Maintainer bleibt jeder Fund entweder ungenutzt oder wird zum öffentlichen Steilpass für Angreifer, sobald er irgendwo auftaucht.
Bevor ihr startet, braucht es eine echte Sandbox mit den im README beschriebenen Kontrollen, kein Nebenbei-Setup, und ein Tokenbudget, das ihr vorher kennt statt erst nach dem ersten 150.000-Token-Lauf zu lernen. Dazu kommt der Teil, den der Skill nicht automatisiert: Jemand muss jeden Fund noch einmal lesen, bevor er als Bugreport oder Advisory rausgeht. Der zweite Agent als Prüfer senkt den Aufwand für dieses Review, er macht es nicht überflüssig.