Cloudflares Audit-Agent ist offen: Der Widerspruch ist das Produkt

Cloudflare hat diese Woche einen Skill veröffentlicht, der einen Coding-Agenten in einen Sicherheitsprüfer verwandelt, und er ist zum am schnellsten wachsenden Repository der GitHub-Wochenliste geworden: rund 16,400 Sterne in sieben Tagen, 51.000 insgesamt. Die Selbstdarstellung des Unternehmens ist ungewöhnlich bescheiden: Dies sei der Ein-Repository-Ausgangspunkt, aus dem sein internes Werkzeug zur Suche nach Schwachstellen hervorgegangen ist, veröffentlicht, damit andere ihr eigenes bauen können.

Lesenswert ist nicht der Katalog der Angriffsklassen, so umfangreich er auch ist. Lesenswert ist der Teil darüber, wie Befunde zerlegt werden.

Sechs Phasen, eine davon ist reine Buchhaltung

Der Ablauf ist strukturiert statt dialogisch, und das ist das Erste, was ihn von „bitte Claude, Bugs zu finden“ unterscheidet.

Phase eins ist Aufklärung: Architektur, Vertrauensgrenzen und Eingabeoberflächen kartieren und, das ist der ungewöhnliche Teil, in architecture.md und coverage-ledger.json festhalten. Phase zwei teilt isolierte Jäger den Einheiten aus diesem Register zu, hält fest, was jeder geprüft hat, und lässt dann Coverage-Kritiker laufen, die suchen, was niemand angesehen hat. Phase drei übergibt jeden einzelnen Kandidaten an einen frischen Verifizierer, dessen Aufgabe es ist, ihn zu widerlegen. Phase vier schreibt confirmed-, needs_validation- oder rejected-Einträge in findings.json und validiert sie gegen ein JSON-Schema. Phase fünf lässt frische Agenten die abschließenden Aussagen über den Quellcode prüfen, und jeder materielle Austausch bekommt einen weiteren unabhängigen Verifizierer. Phase sechs leitet die Berichte aus den geprüften Einträgen ab.

Die beiden Validatoren sind schlichte Node-Skripte ohne Abhängigkeiten: validate-coverage-ledger.cjs läuft nach dem Anlegen des Registers und nach jeder Aktualisierung, validate-findings.cjs in Phase vier und erneut nach jedem Austausch in Phase fünf. Sie sind die uninteressantesten Dateien im Repository und der Grund, warum der Rest zusammenhält. Ein Agent, der keinen schema-konformen Befund erzeugen kann, kann auch keinen behaupten.

Die drei Urteile sind das eigentliche Design

Die meisten Sicherheitswerkzeuge für Agenten haben zwei Ausgaben: eine Liste von Bugs oder nichts. Dieses hat drei, und in der mittleren Kategorie steckt das Nachdenken.

confirmed bedeutet einen vollständigen Quellcode-Nachweis plus ein begrenztes, beobachtetes Ergebnis. needs_validation bedeutet einen exakt benannten, ungelösten Sachverhalt und keine zugewiesene Schwere. rejected bedeutet einen aktiv widerlegten Kandidaten, festgehalten statt gelöscht.

Das dritte ist ungewöhnlich und, wie ich finde, richtig. Ein widerlegter Kandidat ist ein Beleg über die Codebasis: Er sagt dem nächsten Lauf, dort keine Zeit zu investieren, und er sagt einem Prüfer, was erwogen wurde. Die meisten Werkzeuge werfen das weg.

Das darunterliegende Konstruktionsprinzip steht unverblümt im README: Nur etablierte Grenzverletzungen bestätigen, und wenn eine im Quellcode belegte Spur blockiert ist, sie als needs_validation mit dem exakten ungelösten Sachverhalt belassen, statt sie zum Befund hochzustufen. Dazu gehört eine verwandte Regel: Lücken in der Defense-in-Depth sind keine Schwachstellen. Blockiert Schicht A den Angriff, ist das Fehlen von Schicht B eine Härtungsnotiz.

Wer schon einmal einen maschinell erzeugten Schwachstellenbericht gelesen hat, weiß genau, warum diese Regeln existieren. Der Fehlermodus von LLM-Sicherheitsprüfungen ist nicht das Übersehen von Bugs. Es ist selbstsicherer Lärm: Muster, die wie Schwachstellen aussehen, mit hoher Schwere gemeldet, die eine Woche eines Triage-Teams verbrennen.

Adversarische Validierung, wörtlich genommen

Der wichtigste Satz: Der Agent, der einen Befund prüft, ist nie der Agent, der ihn gefunden hat.

Das ist keine Prompt-Anweisung, sondern eine Einschränkung der Orchestrierung, und es ist der einzige Weg, auf dem diese Art von Werkzeug etwas Vertrauenswürdiges produziert. Ein LLM, das über seine eigene Ausgabe gefragt wird, ob der Befund stimmt, wird sich selbst zustimmen. Gebt ihm einen frischen Kontext, eine andere Agenteninstanz und die ausdrückliche Aufgabe zu widerlegen, und das Ergebnis kommt einem Code-Review näher.

Phase fünf dehnt das aus: Frische Agenten prüfen die abschließenden Aussagen über den Quellcode, und wird eine Aussage materiell ersetzt, prüft ein weiterer unabhängiger Verifizierer den Ersatz. Zwischen dem Jäger und dem Eintrag, der überlebt, liegen zwei Stufen der Trennung.

Die ehrliche Zahl

Tief in den Konstruktionsprinzipien steht: In Cloudflares Testläufen fand ein einzelner Lauf etwa die Hälfte der Schwachstellen, die wiederholte Läufe insgesamt fanden.

Das zu veröffentlichen ist eine Entscheidung. Sie sagt, dass das Werkzeug eine Abdeckungsmaschine ist und kein Orakel, und sie rahmt den Ablauf neu: Man lässt es nicht einmal vor einem Release laufen, sondern wiederholt, und lässt die Register anwachsen. Das Repository unterstützt das ausdrücklich: Mehrere Läufe gegen dasselbe Repository sind additiv, sie nutzen frühere Register und Befunde, um Lücken zu zielen, prüfen geänderten Quellcode erneut und tragen Belege des aktuellen Codes weiter, ohne veraltete Arbeit als abgedeckt zu behandeln.

Die Hälfte ist auch für menschliche Prüfer im ersten Durchgang eine plausible Schätzung, was je nach Blick auf den Beruf beruhigend oder vernichtend ist.

Die Anforderung, an der die meisten scheitern

Das README nennt eine harte Voraussetzung, die die meisten überlesen und dann einholen: eine vom Betriebssystem erzwungene Sandbox für Builds, Tests, Prozesse, Browser, Emulatoren, Fuzzer und Fixtures, mit deaktiviertem externem Netzwerk, bereinigter Allowlist-Umgebung, erzwungenen Ressourcenlimits und Schreibzugriff nur auf Scratch-Pfade.

Ohne diese Kontrollen hält der Ablauf die Spur in needs_validation, statt Zielcode auszuführen. Das ist die richtige Entscheidung, man lässt schließlich die Vorschläge eines Sprachmodells gegen eine Codebasis laufen, aber es bedeutet, dass das Werkzeug für alle ohne Container-Infrastruktur zu einer Übung aus statischer Analyse und Schlussfolgern verkommt.

Es bedeutet auch, dass dies kein Laptop-Werkzeug ist, trotz der npx-Installationszeile. Die Installation ist ein Befehl:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

Und die Nutzung besteht aus einer Frage:

security audit this codebase

Ein seltsamer Kontrast: Der Aufruf ist ein Satz, die Voraussetzung ist eine Sandbox-Richtlinie. In diese Lücke wird der größte Teil des Einführungsaufwands fließen.

Wie die Ausgabe tatsächlich aussieht

Drei Artefakte, abgeleitet statt geschrieben: REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, dazu das zugrunde liegende findings.json und das Coverage-Register.

Diese Trennung ist nützlicher, als sie klingt. Ein einzelner Schwachstellenbericht zwingt jeden Befund in dieselbe Tonlage, und so landet eine kritische SQL-Injection neben einem fehlenden CSP-Header. Bestätigte Befunde, offene Fragen und abgeleitete Zusammenfassungen zu trennen heißt: Wer NEEDS-VALIDATION.md liest, weiß, dass er Arbeit sieht und keine Ergebnisse.

Das Standard-Ausgabeverzeichnis ist ~/security-audit-skill/<repo-name>/run-<N>, und der Ablauf schreibt nur dann in das Ziel-Repository, wenn man ihn ausdrücklich auf ein gitignoriertes Verzeichnis zeigt. Kleines Detail, richtiger Instinkt: Audit-Artefakte im Repository werden versehentlich committet, und eine committete Liste ungepatchter Schwachstellen ist ihr eigener Vorfall.

Woran man erkennt, ob es funktioniert hat

Zweimal laufen lassen. Das ist der Test, den das README andeutet, ohne ihn zu nennen: Weil Läufe additiv sind und ein einzelner Lauf etwa die Hälfte findet, ist der zweite Lauf gegen denselben Commit eine direkte Messung der Abdeckung des Werkzeugs auf der eigenen Codebasis. Kommt beim zweiten Lauf nichts Neues, ist entweder der Code sauber oder die Jagdklassen passen nicht zum Stack.

Dann das Rejection-Log prüfen. Ein Lauf, der fünf Probleme bestätigt und vierzig Kandidaten verwirft, macht seine Arbeit. Ein Lauf, der vierzig bestätigt und keinen verwirft, hat aufgehört zu verifizieren, und man sollte diese vierzig von Hand lesen, bevor man einem davon glaubt.

Was das über die Kategorie aussagt

Drei Dinge, kurz.

Agent-Skills werden zu Distributionsformen. Das ist keine Bibliothek, die man importiert, sondern ein Ordner mit Markdown und zwei Validator-Skripten, die ein Modell zur Laufzeit liest. Das Repository sind rund zwanzig Anweisungsdateien plus Angriffskataloge, getrennt nach Zieltyp: Speichersicherheit und Binäres, LLM- und Agenten-Oberflächen, Webprotokoll und Authentifizierung, Clientseite, Lieferkette, Cloud und Deployment, RPC und Messaging, Ressourcenerschöpfung, Datenisolation, Desktop und lokale IPC. Diese Struktur ist das Produkt.

Verifikation wird zum Unterscheidungsmerkmal. Jeder Anbieter kann inzwischen einen plausiblen Befund erzeugen. Fast keiner kann sagen, welche einen adversarischen Durchgang überlebt haben, schema-konform geschrieben wurden und die widerlegten eingeschlossen.

Und die Gewohnheit der ehrlichen Zahl breitet sich aus. Ein Anbieter, der veröffentlicht, dass er die Hälfte gefunden hat, ist ein Anbieter, dessen nächste Behauptung glaubwürdiger ist.

Das Repository steht unter MIT-Lizenz. Die interessante Frage ist also nicht, ob es funktioniert, sondern ob sich Ihr Team die Sandbox leisten kann, die es für den ordnungsgemäßen Betrieb braucht.