KI-Sicherheitsanalyse-security-audit-skill

Einleitung

Große Sprachmodelle können Code lesen, Zusammenhänge über viele Dateien hinweg verfolgen und Werkzeuge bedienen. Damit liegt es nahe, sie für die Suche nach Sicherheitslücken einzusetzen. Offen ist, wie belastbar ihre Ergebnisse sind, denn ein falscher Befund ist in der Sicherheitsanalyse teuer.

Der Bericht folgt den vier Fragen der Seminarbeschreibung:

1. Wie funktioniert eine KI-Agent-basierte Sicherheitsanalyse?
2. Welche Werkzeuge sind verfügbar und geeignet?
3. Wo liegen Stärken, Schwächen und Kosten?
4. Können die gefundenen Schwachstellen verstanden und verifiziert werden?

Werkzeugfamilien

• Klassische statische Analyse (SAST) wie Semgrep oder CodeQL ist schnell und reproduzierbar, findet aber vor allem Muster, die vorher als Regel formuliert wurden.

• KI-Ageten wie Claude Code lesen und durchsuchen Code selbstständig. Sie erkennen auch Logikfehler über Dateigrenzen hinweg, arbeiten aber nicht deterministisch.

Ein Skill ist ein Ordner mit Anweisungen, den ein KI-Agent bei Bedarf lädt und der festlegt, wie der Agent eine Aufgabe erledigt.

Der Cloudflare security-audit skill

Der Security-audit Skill ist ein öffentliches Repository von Cloudflare (MIT-Lizenz) und laut Cloudflare der Ausgangspunkt ihres internen Systems zur Schwachstellensuche. Er ist kein Scanner, sondern besteht aus rund 5.300 Zeilen Anweisungen und zwei Prüfskripten:

Bestandteil	Zweck
SKILL.md	Einstieg: Betriebsarten, Sicherheitsregeln, Profile, Budget, Schweregrade
RECONNAISSANCE.md, HUNTING.md, ATTACK-CLASSES.md	Aufklärung, Suchaufträge und Angriffsklassen
10 Begleitdateien	Spezialwissen (z. B. Web/Authentifizierung, Client-Seite, KI/LLM), nur bei Bedarf geladen
VALIDATION-AND-REPORTING.md	Validierung, Verifikation und Bericht
report-schema.json und zwei .cjs-Skripte	JSON-Schema und deterministische Prüfung der Ausgabe

Verwendet wurde der vollständige Audit-Modus, der alle sechs Phasen durchläuft und Berichtsdatein schreibt.

Ablauf in sechs Phasen

Ablauf des Security-audit Skill

1. Aufklärung: Vier Agenten erfassen parallel Technick, Benutzerrollen, Vertrauensgrenzen und Eingabepunkte. Daraus entstehen architecture.md und das Coverage Ledger.
2. Suche: Hunter-Agenten prüfen je eine Einheit mit passenden Angriffsklassen; Kritiker-Agenten suchen ungeprüfte Bereiche.
3. Validierung: Jeder Kandidat geht an einen frischen Prüfer, der die Suche nicht kennt und den Fund zu widerlegen versucht.
4. Strukturierte Ausgabe: Die Urteile landen in findings.json und werden gegen das Schema geprüft.
5. Erneute Verifikation: Weitere frische Agenten prüfen die endgültigen Aussagen ein zweites Mal.
6. Bericht: Erst dann entstehen REPORT.md und NEEDS-VALIDATION.md, ausschließlich aus geprüften Datensätzen.

Nur der koordinierende Agent (parent) schreibt gemeinsame Dateien, alle anderen liefern strukturierte JSON-Ergebnisse zurück.

Zentrale Konzepte

Urteil	Bedeutung	Schweregrad
confirmed	Vollständige Spur durch den Code und ein lokal beobachtetes Ergebnis	ja
needs_validation	Quellcodebasierter Verdacht, bei dem genau ein Fakt fehlt; mit Prüfplan	nie
rejected	Von einem Prüfer widerlegt	nein

Herkunft

Cloudflare ist ein großer Anbieter für den Schutz von Websites. Der Skill ist auf GitHub unter MIT-Lizenz veröffentlicht. Laut dem Cloudflare-Blogartikel „Build your own vulnerability harness“ war er der Ausgangspunkt für Cloudflares internes System zur Schwachstellensuche, das später zu einer großen Pipeline über mehr als 128 Repositories ausgebaut wurde.

Bestandteile

Der Skill ist kein Scanner und kein Programm. Er ist ein Ordner skills/security-audit/ mit rund 5.300 Zeilen Anweisungen und zwei Prüfskripten:

Datei	Aufgabe
SKILL.md	Einstieg: Betriebsarten, Sicherheitsregeln, Profile, Budget, Schweregradskala, verbotene Fehler
RECONNAISSANCE.md	Phase 1: Aufklärung des Projekts und Aufbau des Coverage Ledgers
HUNTING.md, ATTACK-CLASSES.md	Phase 2: Aufbau der Suchaufträge und Angriffsklassen (Injection, Zugriffskontrolle, Dateien, Kryptografie, Geschäftslogik …)
10 Begleitdateien	Spezialwissen, nur bei Bedarf geladen: Web und Authentifizierung, Client-Seite, KI/LLM, Lieferkette, Cloud, Protokolle, Ressourcenerschöpfung, Datenisolation, Desktop/Mobil, Speichersicherheit
VALIDATION-AND-REPORTING.md	Phasen 3 bis 6: Validierung, Ausgabe, zweite Verifikation, Bericht
report-schema.json	festes JSON-Schema für jedes Ergebnis
validate-findings.cjs, validate-coverage-ledger.cjs	Node.js-Skripte, die die Ausgabe mit festen Regeln prüfen

Warum die Prüfskripte wichtig sind: Ein Sprachmodell kann eine JSON-Datei schreiben, die richtig aussieht, aber unvollständig oder widersprüchlich ist. Die Skripte arbeiten ohne KI und lehnen etwa fehlende Felder, ungültige Pfade oder einen Schweregrad für einen unbestätigten Fund ab.

Zwei Betriebsarten

1. Beratungsmodus (guidance mode): Standard. Beantwortet Sicherheitsfragen, ohne Berichtsdateien zu schreiben.
2. Vollständiger Audit-Modus (full audit mode): nur bei ausdrücklicher Anfrage („security audit“, „pen-test“, „full security review“). Durchläuft alle sechs Phasen und schreibt die Berichtsdateien.

Im Projekt wurde ausschließlich der vollständige Audit-Modus verwendet.

Vier Rollen

Der Skill macht aus einem Agenten ein kleines Prüfteam mit vier Rollen:

Rolle	Name im Skill	Aufgabe
Koordinator	Parent	die Hauptsitzung in Claude Code; verteilt die Arbeit und schreibt als Einziger die gemeinsamen Dateien
Sucher	Hunter	Subagenten, die in einem zugewiesenen Codebereich und für eine Angriffsklasse nach Fehlern suchen
Prüfer	Verifier	neue Subagenten, die die Suche nicht kennen und jeden Fund zu widerlegen versuchen
Kritiker	Critic	Subagenten, die nach Codebereichen suchen, die niemand geprüft hat

Warum diese Trennung? Ein Agent, der einen Fehler findet und ihn anschließend selbst bewertet, neigt dazu, sich selbst zu bestätigen. Der Skill verbietet das: Wer findet, bewertet nicht. Das entspricht dem Vier-Augen-Prinzip beim menschlichen Code-Review.

Jeder Subagent arbeitet in einem eigenen Ordner unter agents/<agent-id>/scratch/ und gibt sein Ergebnis als strukturiertes JSON zurück. Nur der Koordinator sammelt diese Ergebnisse und schreibt sie in die gemeinsamen Dateien.

Sechs Phasen

File:Security-audit Ablauf 6 Phasen.png

Die sechs Phasen und vier Rollen des security-audit skill

Phase 1: Aufklärung (reconnaissance). Der Koordinator startet vier Agenten gleichzeitig, die nur lesen:

• Agent 1a: Produkt, Benutzer, Sprachen und Frameworks, Build- und Testbefehle;
• Agent 1b: Rollen, Berechtigungen, Anmelde- und Rechteprüfungen;
• Agent 1c: Eingabepunkte (HTTP-Anfragen, Datei-Uploads usw.) und wohin die Daten im Code fließen;
• Agent 1d: Was lässt sich lokal sicher testen, und bietet der Rechner die geforderte Sandbox?

Daraus entstehen architecture.md (Lagebild, höchstens etwa 1.000 Wörter) und coverage-ledger.json.

Phase 2: Suche (hunting). Der Koordinator zerlegt die Arbeit in Prüfeinheiten und gibt jedem Hunter eine oder mehrere Einheiten samt der passenden Angriffsklassen-Anweisungen im Wortlaut. Der Hunter verfolgt eine Eingabe vom Eingabepunkt über alle Prüfungen bis zur kritischen Stelle (sink), etwa einer Datenbankabfrage oder einem Befehlsaufruf, und liefert sein Ergebnis als JSON. Danach sucht ein Kritiker nach ungeprüften Bereichen; gefundene Lücken werden als neue Einheiten aufgenommen, sofern das Budget eine weitere Welle erlaubt.

Phase 3: Validierung (validation). Der Kern des Skills: Jeder Kandidat geht an einen neuen Prüfer, der die Suche nicht gesehen hat. Er liest jede zitierte Codezeile erneut, sucht nach übersehenen Schutzmechanismen und versucht, den Fund zu widerlegen. Dann entscheidet er sich für eines von drei Urteilen.

Phase 4: Strukturierte Ausgabe (structured output). Alle Urteile werden in findings.json geschrieben, und die Prüfskripte kontrollieren das Format.

Phase 5: Zweite Verifikation (independent record verification). Weitere neue Agenten prüfen die endgültigen Aussagen ein zweites Mal. Ändert einer von ihnen etwas Wesentliches, prüft ein zusätzlicher Agent die Änderung.

Phase 6: Bericht (reporting). Erst jetzt entstehen REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, ausschließlich aus geprüften Datensätzen. Der Bericht darf kein Urteil verändern.

Endbedingung: Ein Lauf darf nicht mitten in einer Phase enden. Entweder sind alle Berichtsdateien geschrieben und beide Skripte bestanden, oder der Lauf wird als „incomplete“ mit genauem Grund markiert.

Drei Urteile

Urteil	Bedeutung	Schweregrad?
confirmed	vollständige Spur im Code vom Eingabepunkt bis zur kritischen Stelle und ein lokal beobachtetes Ergebnis, z. B. ein fehlschlagender Test	ja
needs_validation	codebasierter Verdacht, bei dem genau ein Fakt fehlt; mit Prüfplan	nein, nie
rejected	von einem Prüfer widerlegt	nein

Einträge mit needs_validation heißen in diesem Bericht Verdachtsfälle (leads). Entscheidend: Für „confirmed“ muss der Code ausgeführt und das Ergebnis beobachtet werden. Dass der Code fehlerhaft aussieht, genügt nicht.

Schweregradskala

Nur bestätigte Funde erhalten einen Schweregrad:

• critical: Ein nicht angemeldeter Angreifer führt Code aus, erhält vollen Datenbankzugriff oder übernimmt beliebige Konten.
• high: Eine Sicherheitskontrolle wird mit echten Folgen vollständig umgangen, z. B. Anmeldung umgangen oder fremde Daten gelesen.
• medium: echte Grenzverletzung mit begrenzter Wirkung oder seltenen Voraussetzungen.
• low: Preisgabe nicht geheimer interner Informationen.
• informational: bestätigt, aber mit minimaler Wirkung.

Coverage Ledger

Das Coverage Ledger zerlegt das Projekt in Prüfeinheiten. Jede Einheit ist eine Kombination aus vier Teilen:

Eingabepunkt × Vertrauensgrenze × Teilsystem × Angriffsklasse

Beispiel: „POST /login“ × „Passwortprüfung“ × „Server“ × „SQL-Injection“.

Status	Bedeutung
planned	geplant, noch nicht begonnen
in_progress	ein Hunter arbeitet daran
covered	geprüft, kein Fund
candidate	enthält einen validierten Verdachtsfall
blocked	geprüft, enthält aber nur ungeprüfte Hinweise
deferred	zurückgestellt, meist wegen des Budgets
out_of_scope, not_applicable	außerhalb des Umfangs bzw. nicht zutreffend

Warum das wichtig ist: Die meisten Werkzeuge sagen, was sie gefunden haben, aber nicht, was sie nicht geprüft haben. Das Ledger macht Lücken in der Abdeckung sichtbar. Niemand kann „alles geprüft“ behaupten, solange Einheiten zurückgestellt sind.

Fingerabdruck

Jede Grundursache erhält eine feste Kennung, den Fingerabdruck (fingerprint), z. B. juice-shop/routes/login/raw-sql-string-interpolation. Er enthält keine Zeilennummer und bleibt daher auch bei kleinen Codeänderungen gleich. Damit lassen sich Läufe vergleichen.

Profile und Budget

Profil	Bedeutung
quick	eine Suchwelle, ein abschließender Kritiker, ein Prüfer pro Kandidat; für einen ersten Überblick
standard	Standard: Suchwellen, bis die Kritiker keine Lücken mehr finden oder das Budget aufgebraucht ist; zwei Kritiker, zwei getrennte Prüfer pro Fall
deep	für große, kritische Projekte: feinere Einheiten, zusätzliche unabhängige Prüfung

Das Budget ist die Höchstzahl der Agentenaufrufe über alle Phasen. Vor der Suche reserviert der Skill Aufrufe für Kritiker und Prüfer, damit die Hunter nicht das ganze Budget verbrauchen und am Ende niemand mehr prüfen kann.

Sicherheitsregel: ohne Sandbox keine Ausführung

Der untersuchte Code kann gefährlich sein, denn er enthält ja Lücken. Deshalb erlaubt der Skill die Ausführung von Zielcode nur in einer vom Betriebssystem erzwungenen Sandbox mit allen folgenden Eigenschaften:

• keine Verbindung zum externen Netzwerk;
• leere Umgebung, ohne Variablen oder Passwörter des Rechners;
• Zielcode nur lesbar;
• Schreiben nur in einen eigenen Arbeitsordner;
• harte Grenzen für CPU, Speicher, Prozesse und Laufzeit.

Fehlt eine Eigenschaft, führt der Skill nichts aus, vermerkt den Grund als Blocker (blocker) und belässt den Fund bei „needs_validation“. Weitere Regeln: keine Anfragen an produktive Systeme, keine Installation von Abhängigkeiten, keine echten Zugangsdaten, keine Änderungen am Zielcode. Der Skill beschreibt Korrekturen nur.

Mehrere Läufe bauen aufeinander auf

Kennt ein zweiter Lauf den Ort des ersten, liest er dessen Ledger und Ergebnisse. Er konzentriert sich dann auf zurückgestellte Einheiten und ungeprüfte Hinweise und prüft alte Ergebnisse erneut. Laut Cloudflare findet ein einzelner Lauf etwa die Hälfte dessen, was wiederholte Läufe zusammen finden.

Versuchsdesign

Merkmal	Lauf 1	Lauf 2
Profil	quick	standard
Budget	25 Agentenaufrufe	60 Agentenaufrufe
Vorwissen	keins	Lauf 1 (nur lesend)
Ausführung von Zielcode	nein	nein
Commit	5658473c	5658473c

Das Zielprojekt

OWASP Juice Shop ist ein absichtlich unsicherer Webshop für Sicherheitstrainings (TypeScript, Express, Angular, SQLite). Er liefert mit data/static/challenges.yml einen Lösungsschlüssel von 116 beabsichtigten Schwachstellen. Damit lässt sich prüfen, was die KI findet und was sie übersieht. Alle Läufe nutzen Version 20.2.0, Commit 5658473c.

Merkmal	Lauf 1	Lauf 2
Umgebung	Claude Code , Claude Pro, macOS
Profil	Quick	Standard
Budget	25 Agentenaufrufe	60 Agentenaufrufe
Vorwissen	keins	Lauf 1 (nur lesend)

Zwischen den Läufen änderten sich nur Breite und Vorwissen. Beide Läufe arbeiteten nur am Quellcode: Juice Shop ist absichtlich verwundbar und sollte nicht auf einem privaten Rechner laufen. Zudem kann macOS die geforderte Sandbox nicht bereitstellen. Das Urteil confirmed war damit grundsätzlich nicht erreichbar. Die genauen Aufträge stehen im Anhang.

Teil 4: Das Zielprojekt OWASP Juice Shop

Was ist Juice Shop?

OWASP Juice Shop ist ein fiktiver Webshop für Säfte, der absichtlich voller Sicherheitslücken ist und für Sicherheitstrainings verwendet wird:

• Server: TypeScript, Node.js, Express; SQLite über Sequelize sowie die In-Memory-Datenbank MarsDB;
• Oberfläche: Angular;
• Anmeldung: JWT-Tokens.

Warum dieses Projekt?

Juice Shop enthält einen Lösungsschlüssel: Die Datei data/static/challenges.yml listet 116 Challenges, also 116 beabsichtigte Schwachstellen. Das liefert eine Referenz (ground truth), mit der sich messen lässt, was das Werkzeug gefunden und was es übersehen hat. Ein gewöhnliches Projekt bietet so etwas nicht. Juice Shop ist zwar nicht klein, dieser Vorteil überwiegt aber.

Der sichere Modus (safetyMode)

Juice Shop hat eine Einstellung safetyMode. Ist sie aktiv, werden etwa 19 gefährliche Challenges wie Codeausführung oder Dateizugriff abgeschaltet, sobald die Anwendung in Docker oder auf Heroku läuft. Diese Einstellung ist für einen der wichtigsten Funde (Nr. 13) entscheidend.

Untersuchte Version

Alle Läufe verwenden denselben Stand: Version 20.2.0, Commit 5658473c vom 10. August 2026 mit der Commit-Nachricht „Add missing guard around lfrChallenge for safe mode“. Dieser Commit sollte also den Schutz im sicheren Modus verbessern.

Warum ein fester Stand? Ändert sich der Code zwischen zwei Läufen, ist nicht erkennbar, ob ein Unterschied an der KI oder am Code liegt.

Durchführung

Lauf 1 dauerte 26 Minuten und nutzte 24 von 25 Aufrufen (4 Aufklärung, 6 Hunter, 1 Kritiker, 13 Prüfer). Um Budget für die Validierung zu behalten, begrenzte der koordinierende Agent jeden Hunter auf zwei Kandidaten, 23 weiter Ursachen blieben als ungeprüfte Hinweise im Ledger. Ein Prüfer widerlegte die ursprüngliche Angriffsidee eines Hunter und präzisierte die Aussage.

Lauf 2 dauerte 3 Stunden 13 Minuten und nutzte 57 von 60 Aufrufen (4 Aufklärung, 9 Hunter, 2 Kritiker, 42 Prüfer). Drei Ereignisse prägten ihn:

• Ratenlimit: Rund 20 gleichzeitig gestartete Agenten wurden vom Sitzungslimit des Pro-Abonnements abgebrochen. Der Skill hielt an und fragte nach. Die Fehlstarts wurden nicht auf das Budget angerechnet, aber offengelegt, und die Agenten in Fünfergruppen neu gestartet.
• Budgetbindung: Die 12 übernommenen Verdachtsfälle aus Lauf 1 banden 24 Prüferaufrufe. Jeder Hunter durfte daher nur einen Kandidaten einreichen; 33 Ursachen blieben ungeprüft.
• Sicherheitsfilter: Der erste Berichtsentwurf wurde angehalten und ohne konkrete Angriffsdaten neu geschrieben.

Ergebnisse

Überblick

Kennzahl	Lauf 1	Lauf 2
Validierte Verdachtsfälle	12	21 (12 übernommen, 9 neu)
Bestätigt / verworfen	0 / 0	0 / 0
Ungeprüfte Hinweise	23	33
Prüfeinheiten im Ledger	22	53
Prüfskripte (selbst nachgeprüft)	bestanden	bestanden

Status der Prüfeinheiten: Lauf 2 prüfte deutlich mehr Einheiten, die meisten neuen blieben aber blockiert, weil das Budget die Validierung nicht abdeckte.

Lauf 2 brachte vor allem mehr Breite, aber keinen zusätzlichen Beweis. Die Ergebnisse sind stabil: Alle 12 Fälle aus Lauf 1 kamen mit demselben Urteil zurück. Von den 9 neuen Fällen waren 5 in Lauf 1 schon als ungeprüfte Hinweise notiert, 4 sind neue Ursachen.

Die 21 Verdachtsfälle

„Katalog“ zeigt, ob der Fall einer beabsichtigten Juice-Shop-Challenge entspricht. „Eigene Prüfung“ ist das Ergebnis meiner Quellcodeprüfung. Angriffsdaten werden bewusst nicht genannt.

Nr.	Verdachtsfall	Katalog	Eigene Prüfung
1	JWT-Signierschlüssel fest im Code und öffentlich abrufbar	ja	gestützt
2	JWT-Algorithmus nicht festgelegt	ja	gestützt
3	YAML-Upload erlaubt Codeausführung	nein	gestützt
4	Zip-Slip beim Datei-Upload	ja	gestützt
5	Benutzername wird per eval ausgewertet (Template-Injection)	ja	Codezeile stimmt
6	SQL-Injection in Login und Produktsuche	ja	nicht geprüft
7	Methodensperren über PATCH umgehbar	nein	widerlegt
8	Öffentlicher Endpunkt liefert Passwort-Hashes der Fotowand	nein	Code stimmt
9	Öffentliche Zugriffsprotokolle enthalten Passwörter	teilweise	gestützt
10	SSRF über Profilbild-URL	ja	Codezeile stimmt
11	SSRF über Chatbot-Nachrichten	nein	nicht geprüft
12	JavaScript-Injection über MarsDB-$where	ja	nicht geprüft
13	Unvollständiger Sicherheitsschalter im neuesten Commit	nein	gestützt
14	Sitzungen laufen nie ab und werden nie widerrufen	nein	Code stimmt
15	Adressen ohne Eigentümerprüfung änderbar	nein	Route stimmt
16	Bewertungen massenhaft änderbar (NoSQL)	ja	nicht geprüft
17	Datenexport schreibt fremde Texte als HTML	nein	Codezeile stimmt
18	DOM-XSS über Suchparameter	ja	Codezeile stimmt
19	Unbehandelter Fehler kann den Server beenden	nein	plausibel
20	Pfadtraversal mit Backslash (nur Windows)	nein	Codezeile stimmt
21	Chatbot-Verläufe bleiben nach Abmeldung erhalten	nein	Code stimmt

Besondersauffällig ist Nr. 13 Der neueste Commit fügt einen Schalter für den sicheren Modus nur in einem Codezweig ein, im anderen fehlen Sperrliste und Kürzung. Dies ist eine Regression genau in dem Modus, der die Anwendung absichern soll. Nr. 3 erlaubt Codeausführung über einen anonymen Upload, wofür es keine Challenge gibt. Nach einer Bestätigung zur Laufzeit wären beide nach Juice Shops SECURITY.md vertaulich an den Maintainer zu melden.

Vergleich mit dem Challenge-Katalog

Nach Lauf 1 erschienen ca. 29, nach beidenLäufen ca. 37 der Challenges (rund 32 %) als Verdachtsfall, ungeprüfter Hinweis oder Härtungshinweis. Viele Challenges sind durch Code-Lesen grundsätzlich nicht auffindbar (z. B. Foto-Geolokalisierung, Steganografie, schwache Passwörter). Dafür fanden die Läufe 12 Verdachtsfälle außerhalb des Katalogs, von denen einer (Nr. 7) später widerlegt wurde.

Verifikation der Ergebnisse

Ebene	Prüfung	Ergebnis
1. Format	Ausgabe entspricht Schema und Ledger-Regeln	beide Prüfskripte bestanden (z. B. PASS: 21 findings valid); sagt nichts über echte Fehler
2. Quellcode	Zitierte Stellen existieren und tun, was behauptet wird	320 von 320 Referenzen korrekt; 5 offene Fragen geklärt, 1 Fall widerlegt

Vorgehen auf Ebene 2: Jede zitierte Datei und Zeile wurde geprüft, also ausgewählte Stellen wurden von Hand gelesen. Wo ein Fall an einer Frage zum Bibliotheksverhalten hing, wurde das Paket mit npm pack geladen und nur gelesen, nicht ausgeführt:

Anhang: Verwendete Aufträge

Lauf 1: Lauf 2: