Zuerst wird ein Ledger angelegt: jede untersuchbare Einheit der Codebasis bekommt eine Kennung und einen Prüfstatus. Erst danach beginnt die Suche. Isolierte Agenten arbeiten die Einheiten ab, eine zweite Gruppe sucht Lücken im Prüfplan, und jeder vorläufige Befund geht an einen Prüfer, dessen Auftrag das Widerlegen ist.
Cloudflare hat diesen Ablauf als offenes Skill für Coding-Agenten auf GitHub veröffentlicht. security-audit-skill ist eine Sammlung von Anweisungen, Schemata und Prüfskripten, die einen Agenten durch sechs Phasen führt: Aufnahme, Abdeckung, Kandidatenprüfung, strukturierte Ausgabe, unabhängige Nachprüfung und Bericht. Nach Angaben des Projekts ist es das Skill, aus dem Cloudflares Vulnerability-Discovery-Harness hervorgegangen ist. Der Harness wurde daraus zu einem mehrstufigen, flottenweiten System ausgebaut; dieses Repository ist der Ausgangspunkt für ein einzelnes Projekt.
Das Vorgehen erinnert an die Trennung von Bauausführung und Prüfstatik. Wer die Wand gemauert hat, nimmt sie nicht selbst ab. Diese Trennung ist hier nicht als Empfehlung formuliert, sondern in den Ablauf eingebaut. Das unterscheidet den Ablauf von einem Scanner, den man einmal über ein Repository laufen lässt.
Einen Agenten nach einem Sicherheitsaudit zu fragen und den ersten Bericht als Ergebnis zu nehmen, ist verständlich, aber meistens zu optimistisch. Ein Sprachmodell produziert plausiblen Text. Plausibilität ist das Gegenteil von Beweis. Der folgende Durchgang zeigt, wie das Skill dagegen arbeitet.
Ein Ledger statt Bauchgefühl: wie die Aufnahme den Prüfumfang festlegt
Die erste Phase heißt Reconnaissance und hat wenig mit Suchen zu tun, sondern viel mit Kartieren. Der Agent erfasst Architektur, Vertrauensgrenzen und Eingabeoberflächen, dazu frühere Befunde und die deterministisch bekannte Abdeckung. Zwei Dateien entstehen dabei: architecture.md für das Bild des Systems und coverage-ledger.json für das Verzeichnis aller Einheiten, die geprüft werden müssen oder bereits geprüft wurden. Das Ledger ist kein Protokoll im Nachhinein, sondern der Prüfplan, gegen den später abgerechnet wird.
Phase zwei folgt diesem Plan. Aus den Einheiten des Ledgers werden isolierte Hunter zugewiesen, jeder mit einem begrenzten Auftrag, und jeder Hunter trägt seine durchgeführten Checks zurück ins Ledger ein. Danach kommen Coverage-Critics zum Einsatz, deren einzige Aufgabe es ist, Lücken zu finden: Stellen, die im Ledger fehlen oder nur scheinbar abgedeckt sind. Damit unterscheidet sich der Ablauf von der freien Suche. Nicht der Fund steuert den Fortgang, sondern die Frage, was noch nicht angesehen wurde.
Damit das Ledger nicht selbst zur Behauptung verkommt, läuft nach dem Anlegen und nach jeder späteren Aktualisierung ein Prüfskript darüber. validate-coverage-ledger.cjs arbeitet ohne Abhängigkeiten und prüft die Struktur der Datei in den Phasen eins bis fünf. Ein Eintrag, der formal nicht stimmt, fällt auf, bevor er die weiteren Phasen verzerrt.
Falsifikation statt Bestätigung: der Finder prüft sich nicht selbst
In Phase drei bekommt jeder eindeutige Kandidat einen frischen Prüfer. Dessen Auftrag ist nicht, den Befund zu bestätigen, sondern ihn zu widerlegen. Doppelte Kandidaten werden vorher zusammengeführt, damit nicht fünf Prüfer dieselbe Beobachtung fünfmal abnicken. Der Prüfer ist ein separater Agent, ohne den Fundweg des ersten. Er sieht das Ergebnis und die Quelle, nicht die Überlegung, die dazu geführt hat.
Das Projekt formuliert es als Designprinzip: Der Agent, der einen Befund prüft, ist nie der Agent, der ihn gefunden hat. In der Praxis entscheidet das darüber, ob ein automatischer Audit brauchbar ist. Ein Modell, das seinen eigenen Fund nachbewertet, bestätigt ihn fast immer, weil die Begründung schon im Kontext liegt. Ein zweiter Durchlauf ohne diesen Kontext hat diese Bequemlichkeit nicht.
Dazu kommen Regeln, die den Begriff der Schwachstelle schärfen. Bestätigt wird nur ein etablierter Grenzübertritt, also ein nachvollziehbarer Bruch einer Vertrauensgrenze mit beobachtbarer Wirkung. Eine Lücke in der Defense-in-Depth ist keine Schwachstelle: Wenn Schutzschicht A den Angriff verhindert, ist das Fehlen von Schutzschicht B ein Härtungshinweis und wandert nicht in die Befundliste. Die Schwere eines Befunds verlangt einen Impact, berechnet aus Wahrscheinlichkeit mal Auswirkung, nicht aus der Abweichung von einer Checkliste.
Ein blockierter, aber quellenbelegter Hinweis wird nicht weggelassen und nicht hochgestuft. Er bleibt als needs_validation stehen, mit dem exakten ungelösten Fakt, der zu seiner Klärung fehlt. Solche Einträge bleiben offen, das ist unbequem. Ein glatter Befund ohne Belege wäre schlechter.
Drei Urteile, ein Schema und zwei Validatoren
Phase vier übersetzt die Prüfergebnisse in eine maschinenlesbare Datei namens findings.json. Jeder Eintrag trägt eines von drei Urteilen. confirmed bedeutet: vollständiger Quellennachweis und ein begrenztes, tatsächlich beobachtetes Ergebnis. needs_validation bedeutet: ein exakter, ungelöster Fakt und ausdrücklich keine Schweregradeinschätzung. rejected dokumentiert einen widerlegten Kandidaten. Auch das ist ein Ergebnis, weil es verhindert, dass dieselbe Spur beim nächsten Lauf wieder aufgemacht wird.
Gegen das Schema report-schema.json prüft validate-findings.cjs, wieder ohne Abhängigkeiten. Das Skript läuft in Phase vier und erneut nach jeder Ersetzung in Phase fünf, damit kein nachträglich geänderter Datensatz ungeprüft stehen bleibt. Zu beiden Validatoren gehören Testdateien, die unter anderem prüfen, ob erzeugte Datensätze zum Schema passen.
Die Befunde sind keine Prosa, die man von Hand aus einem Langtext zieht. Sie sind Datensätze mit Quelle, Urteil und Begrenzung, die sich in ein Ticketsystem, eine Pipeline oder ein Prüfprotokoll übernehmen lassen. Einen zehnseitigen Scan-Bericht in Arbeitsschritte zu zerlegen, ist mühsam. Ob ein Audit weiterverarbeitet oder nur abgeheftet wird, hängt davon ab, ob die Befunde maschinenlesbar sind.
Unabhängige Nachprüfung und der additive Lauf über mehrere Durchgänge
Phase fünf setzt eine weitere Schicht darauf. Dort verifizieren frische Agenten die endgültigen Quellenaussagen, also die Behauptung, dass eine bestimmte Stelle im Code tatsächlich das tut, was der Befund ihr zuschreibt. Wird ein Eintrag inhaltlich ersetzt, bekommt er einen weiteren unabhängigen Prüfer. Erst danach entstehen in Phase sechs die Berichte: REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, abgeleitet aus den verifizierten Datensätzen und dem Coverage-Ledger. Die Berichte leiten sich aus den Datensätzen ab, sie sind nicht die Quelle der Wahrheit.
Mehrere Durchläufe gegen dasselbe Repository addieren sich. Frühere Ledger und Befunde werden genutzt, um gezielt Lücken anzugehen, geänderten Quellcode neu zu prüfen und belegte Aussagen zum aktuellen Code mitzunehmen. Veraltete oder ungelöste Arbeit wird dabei ausdrücklich nicht als erledigt behandelt. Ein Audit ist hier kein einmaliger Termin.
Cloudflare nennt für die eigenen Testläufe eine Zahl: Ein einzelner Durchlauf fand ungefähr die Hälfte der Schwachstellen, die wiederholte Läufe zusammen fanden. Ein mehrphasiger Sicherheitsaudit mit KI-Agent ist also nicht deshalb gründlich, weil er schlau ist, sondern weil er mehrfach und mit Gedächtnis läuft. Ein einmaliger Scan erreicht das nicht.
Angriffsklassen als Nachschlagewerk für verschiedene Zieltypen
Das Skill besteht nicht nur aus Ablauflogik, sondern aus einer Reihe von Wissensdateien. SKILL.md beschreibt Einrichtung, Grundprinzipien und Anti-Muster eines Audits, RECONNAISSANCE.md die Aufnahme, HUNTING.md die Orchestrierung der Suche, VALIDATION-AND-REPORTING.md die Phasen drei bis sechs. Dazu kommen Angriffsklassen als eigene Dateien.
Für native Ziele gibt es MEMORY-SAFETY-AND-BINARY.md mit Speichersicherheit, Binär- und Kernel-Klassen. Für Systeme mit Sprachmodellen liegt AI-AND-LLM.md bereit, mit Prompt-Injection, Agenten- und Werkzeuggrenzen sowie der Behandlung von Modellausgaben. Weitere Dateien decken HTTP-Protokoll und Authentifizierung, clientseitige Themen von DOM-Injection bis Prototype-Pollution, Supply Chain und Release, Cloud und Deployment, RPC und Messaging, Ressourcenerschöpfung, Mandantentrennung und Datenlebenszyklus sowie Desktop-, Mobile- und lokale IPC-Flächen ab. Die Reihenfolge ist keine Rangfolge, sondern eine Auswahlhilfe je nach Ziel.
Solche Prüfungen scheitern üblicherweise an einem Muster: Ein Agent, der „finde Schwachstellen“ liest, greift auf das Offensichtliche zu und verteilt seine Aufmerksamkeit dünn über alles. Ein Katalog verschiebt die Arbeit von allgemeinem Verdacht zu konkreten Klassen mit bekannten Mustern. Ein Sprachmodell prüft hier ein System, das selbst Sprachmodelle enthält. Prompt-Injection betrifft beide Seiten.
Installation, Sandbox-Pflicht und was das im Alltag bedeutet
Die Installation läuft über die Skills-CLI. Ein Aufruf wie npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit bindet das Skill ein, mit dem Zusatz --global gilt es benutzerweit statt nur im aktuellen Projekt. Für Auswahl des Agenten und nicht-interaktive Varianten gibt die Hilfe der CLI Auskunft. Danach startet man den Coding-Agenten im zu prüfenden Repository und bittet um ein Security Audit; das Skill aktiviert sich, wenn die Anfrage zu seinen Auslösern passt.
Zwei Betriebsarten sind vorgesehen. Eine gezielte Frage oder eine einzelne Schwachstellenanalyse läuft im Guidance-Modus, ein vollständiger Audit- oder Pen-Test-Auftrag im Full-Audit-Modus. In diesem Modus landen die Ergebnisse ohne Angabe eines Verzeichnisses unter einem Benutzerpfad mit Repo-Namen und laufender Nummer; in das Repository selbst wird nur geschrieben, wenn ausdrücklich ein ignoriertes Verzeichnis gewählt wurde. So liegen Audit-Artefakte nicht ungewollt im Versionskontrollsystem.
Die Anforderungen sind nüchtern, mit einer harten Kante: Gebraucht wird ein Coding-Agent, dessen Modell Werkzeugnutzung und parallele Unteragenten beherrscht, dazu Node.js für die Validatoren. Vor allem aber braucht es eine vom Betriebssystem erzwungene Sandbox für alles, was vom Ziel gesteuert wird: Builds, Tests, Prozesse, Browser, Emulatoren und Fuzzer. Diese Sandbox muss externes Netzwerk abschalten, eine bereinigte Umgebung mit Erlaubnisliste verwenden, Ressourcengrenzen durchsetzen und Schreibzugriffe auf zugewiesene Pfade begrenzen. Fehlen diese Kontrollen, führt der Ablauf den Code des Ziels nicht aus, sondern belässt den Hinweis als needs_validation.
Ein automatisiertes Audit, das fremden Build-Code ohne Netzwerksperre und ohne Ressourcengrenzen ausführt, verschiebt das Risiko vom Prüfling zum Prüfer. Der Workflow nimmt dafür lieber einen offenen Eintrag in Kauf, als diese Grenze zu überschreiten. Das Skill ist unter MIT-Lizenz veröffentlicht, Rückmeldungen laufen über eine Cloudflare-Adresse für Sicherheitsforschung mit KI.
Wer einen Coding-Agenten für Schwachstellenanalyse einsetzen will, sollte auf den Ablauf achten, nicht auf das Modell: ein Prüfplan mit Kennungen, getrennte Finder und Prüfer, drei klar definierte Urteile und Datensätze, die eine Pipeline lesen kann. Ein Sicherheitsaudit wird damit zu einem wiederkehrenden Vorgang mit wachsendem Ledger statt zu einem einmaligen Knopfdruck. Ein einzelner Durchlauf findet etwa die Hälfte aller Schwachstellen. Der Rest braucht weitere Läufe.
Quelle: github.com
