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:
- Wie funktioniert eine KI-Agent-basierte Sicherheitsanalyse?
- Welche Werkzeuge sind verfügbar und geeignet?
- Wo liegen Stärken, Schwächen und Kosten?
- 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
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 Modi
- Anleitungsmodus (guidance mode): Standard. Beantwortet Sicherheitsfragen, ohne Berichtsdateien zu schreiben.
- 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
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 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 | ja |
needs_validation |
codebasierter Verdacht, bei dem genau ein Fakt fehlt, mit Prüfplan | nein |
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 |
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.
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.
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 |
Lauf 1 (quick)
Auftrag
Run a full security audit of this codebase using the security-audit skill. Profile: quick. Budget: 25 agent invocations. Source-only: do not execute target code; record anything that needs execution as needs_validation. Output to ~/ITS/audits/juice-shop/run-1
Der Auftrag enthält die ausdrückliche Bitte um ein vollständiges Audit (damit der Audit-Modus greift), Profil, Budget, die Regel „nur Quellcode“ und den Ausgabeort.
Ablauf
Lauf 1 dauerte 26 Minuten und nutzte 24 von 25 Aufrufen:
| Rolle | Aufrufe |
|---|---|
| Aufklärung | 4 |
| Hunter | 6 |
| abschließender Kritiker | 1 |
| Prüfer | 12 |
| erneute Prüfung eines geänderten Datensatzes | 1 |
Budgetentscheidung: Damit genug Aufrufe für die Validierung blieben, begrenzte der Koordinator jeden Hunter auf zwei Kandidaten. Weitere Funde wurden als „ungeprüfte Hinweise“ (unvalidated leads) im Ledger vermerkt, insgesamt 23. Sie sind keine Ergebnisse, sondern Ansatzpunkte für spätere Läufe.
Ein Prüfer korrigiert einen Hunter: Ein Hunter behauptete eine Pfadtraversierung unter Windows mit ..\. Der Prüfer stellte fest, dass eine andere Bibliothek (serve-index) genau diese Form blockiert, absolute Pfade wie C:\… aber nicht. Er formulierte die Aussage enger und genauer, und ein dritter Agent prüfte die Änderung. Das zeigt den Nutzen der Rollentrennung.
Ergebnis
- 12 Verdachtsfälle, alle
needs_validation; - 0 bestätigt, wie wegen der Regel „nur Quellcode“ erwartet;
- 0 verworfen;
- Coverage Ledger: 22 Einheiten, davon 11 mit Verdachtsfall, 1 blockiert, 10 zurückgestellt.
Eigene Kontrolle
Die Prüfskripte wurden von Hand erneut ausgeführt, statt der Aussage des Agenten zu vertrauen:
node .claude/skills/security-audit/validate-findings.cjs audits/juice-shop/run-1/findings.json PASS: 12 findings valid node .claude/skills/security-audit/validate-coverage-ledger.cjs audits/juice-shop/run-1/coverage-ledger.json PASS: 22 coverage units valid
Lauf 2 (standard)
Auftrag
/security-audit Full audit of ~/ITS/targets/juice-shop. Profile: standard. Budget: 60 agent invocations. Source-only: do not execute target code; record anything needing execution as needs_validation. Prior run: ~/ITS/audits/juice-shop/run-1 (coverage-ledger.json, findings.json); do not modify run-1. Output: ~/ITS/audits/juice-shop/run-2
Der Ort von Lauf 1 musste angegeben werden, weil der Skill frühere Läufe nur in seinem Standardordner ~/security-audit-skill/ selbst findet.
Ratenlimit: 20 Agenten abgebrochen
In Phase 3 startete der Koordinator etwa 20 Agenten gleichzeitig (19 Prüfer und einen Kritiker). Das Pro-Abonnement hat ein Sitzungslimit (rate limit); es wurde überschritten, und alle 20 Agenten wurden beendet, bevor sie ein Ergebnis lieferten (HTTP 429).
Der Skill riet nicht, sondern hielt an und fragte, wie die Fehlstarts auf das Budget anzurechnen seien. Er bot drei Möglichkeiten an: nicht anrechnen und neu starten, streng anrechnen und den Lauf als unvollständig beenden, oder das Budget erhöhen. Entschieden wurde: nicht anrechnen, aber offen in run-metadata.json und im Bericht dokumentieren. Nach dem Zurücksetzen des Limits wurden die Agenten in Gruppen von höchstens fünf neu gestartet.
Begründung: Das Budget misst nützliche Prüfarbeit. Die abgebrochenen Agenten haben keine Arbeit geleistet; sie scheiterten an der Grenze des Abonnements, nicht am Werkzeug.
Sicherheitsfilter beim Bericht
Beim Schreiben von REPORT.md hielt ein Sicherheitsfilter (safety classifier) den ersten Entwurf an, vermutlich wegen zu konkreter Angriffsdetails. Der Agent schrieb den Bericht daraufhin auf einer höheren Ebene neu, mit Übersichtstabellen und Korrekturvorschlägen, aber ohne Angriffsdaten. Die vollständigen Spuren blieben in NEEDS-VALIDATION.md.
Gebundenes Budget
Die 12 Verdachtsfälle aus Lauf 1 brauchten je zwei Prüfer (Phase 3 und Phase 5), also 24 der 60 Aufrufe. Für Neues blieb wenig übrig, deshalb durfte jeder Hunter nur einen Kandidaten einreichen. 33 Ursachen blieben als ungeprüfte Hinweise im Ledger.
Ablauf
Lauf 2 dauerte 3 Stunden 13 Minuten, davon 1 Stunde 37 Minuten Modellzeit, der Rest Wartezeit. und nutzte 57 von 60 Aufrufen:
| Rolle | Aufrufe |
|---|---|
| Aufklärung | 4 |
| Hunter | 9 |
| Kritiker | 2 |
| Prüfer Phase 3 | 21 |
| Prüfer Phase 5 | 21 |
| Summe erfolgreich | 57 von 60 |
| Fehlstarts durch Ratenlimit (nicht gezählt) | 20 |
- 21 Verdachtsfälle: Alle 12 aus Lauf 1 kamen mit demselben Urteil zurück, 9 sind neu. Von den neuen waren 5 in Lauf 1 schon als ungeprüfte Hinweise notiert, 4 sind neue Ursachen.
- Coverage Ledger: 53 Einheiten, davon 4 abgedeckt, 21 mit Verdachtsfall, 20 blockiert, 8 zurückgestellt.
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 |
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 |
Die vier wichtigsten Verdachtsfälle
Nr. 13: Unvollständiger Schutz im sicheren Modus. Der untersuchte Commit sollte laut seiner Nachricht eine fehlende Absicherung für den sicheren Modus ergänzen. Der Entwickler fügte eine Bedingung in den if-Zweig ein: „Diesen Teil nicht ausführen, wenn die Challenge abgeschaltet ist.“ Der else-Zweig blieb jedoch unverändert und reicht den vom Benutzer gesendeten Wert layout weiterhin an die Template-Engine (hbs) weiter. Sperrliste und Kürzung der Antwort gab es zudem nur im if-Zweig. Gerade der Modus, der schützen soll, öffnet damit den Weg ohne Einschränkungen. Das ist eine echte Regression im neuesten Commit, die regelbasierte Werkzeuge kaum finden würden.
Nr. 3: Codeausführung über YAML-Upload. Juice Shop nutzt js-yaml in Version 3. Dort verwendet load das vollständige Schema, das bestimmte Tags in echte JavaScript-Funktionen umwandelt. Anschließend ruft der Code JSON.stringify auf das Ergebnis auf, wodurch eine dieser Funktionen automatisch ausgeführt wird. Der Upload ist ohne Anmeldung erreichbar. Eine passende Challenge gibt es nicht.
Nr. 8: Passwort-Hashes auf der Fotowand. Der öffentliche Endpunkt GET /rest/memories liefert zu jedem Foto die vollständigen Benutzerdaten des Besitzers, einschließlich Passwort-Hash. An anderen Stellen blendet der Code diese Felder bewusst aus; die Preisgabe hier ist also nicht beabsichtigt.
Vergleich mit dem Lösungsschlüssel
| Zeitpunkt | Gemeldete Challenges (ungefähr) | Anteil |
|---|---|---|
| nach Lauf 1 | ca. 29 von 116 | ca. 25 % |
| nach beiden Läufen | ca. 37 von 116 | ca. 32 % |
Warum der Anteil niedrig ist: Viele Challenges sind durch Lesen von Code grundsätzlich nicht auffindbar, etwa die Ortsbestimmung eines Fotos, eine in einem Bild versteckte Nachricht, das Erraten eines schwachen Passworts oder versteckte Easter Eggs. Bezogen auf die im Code auffindbaren Challenges wäre der Anteil höher; diese Abgrenzung steht noch aus. Die Zuordnung wurde von Hand vorgenommen und ist daher eine Näherung.
Bemerkenswert: Beide Läufe zusammen fanden 12 Verdachtsfälle außerhalb des Katalogs (oder nur teilweise darin). Einer davon (Nr. 7) erwies sich später als falsch.
Verifikation der Ergebnisse
Dieser Teil beantwortet die vierte Seminarfrage. Unterschieden werden drei Ebenen:
| Ebene | Prüfung | Stand | Ergebnis |
|---|---|---|---|
| 1. Format | Entsprechen die Dateien Schema und Regeln? | durchgeführt | beide Skripte bestanden, in beiden Läufen; sagt nichts über die Echtheit einer Lücke |
| 2. Quellcode | Existieren die zitierten Stellen und tun sie, was behauptet wird? | durchgeführt, nur lesend | 320 von 320 Referenzen korrekt; 5 offene Fragen geklärt, 1 Fall widerlegt |
| 3. Laufzeit | Funktioniert der Angriff auf einer laufenden Kopie? | nicht durchgeführt | erfordert eine isolierte Umgebung |
Vorgehen auf Ebene 2
Die Prüfung fand in einer getrennten Cloud-Umgebung statt, unabhängig vom eigenen Rechner und ausschließlich lesend:
- Juice Shop wurde auf genau dem Commit
5658473causgecheckt. - Ein Skript prüfte jede Angabe „Datei:Zeile“ aus
findings.json. Ergebnis: 110 von 110 in Lauf 1 und 210 von 210 in Lauf 2. Keine erfundene Datei, keine erfundene Zeile. Das war wichtig, weil Halluzinationen die größte Sorge waren. - Für die meisten Verdachtsfälle wurden die entscheidenden Codezeilen von Hand gelesen.
- Viele Fälle hingen an einer Frage zum Verhalten einer Bibliothek. Die Agenten konnten sie nicht klären, weil die Abhängigkeiten (
node_modules) nicht installiert waren und der Skill eine Installation verbietet. Die Bibliotheken wurden deshalb mitnpm packheruntergeladen, was den Code lädt, ohne ihn auszuführen, und anschließend gelesen.
Ergebnisse aus dem Bibliothekscode
| Fall | Offene Frage der KI | Bibliothek | Antwort |
|---|---|---|---|
| Nr. 13 | Liest die Template-Engine layout aus den Optionen? |
hbs 4.3.1 | ja, ohne Pfadbegrenzung → gestützt |
| Nr. 3 | Erzeugt load ausführbare Funktionen? |
js-yaml 3.15.2 | ja (new Function) → gestützt
|
| Nr. 2 | Wird der Algorithmus aus dem Token-Kopf übernommen? | jsonwebtoken 0.4.0 → jws 0.2.6 → jwa 0.0.1 | ja, auch „none“ mit leerer Signatur → gestützt |
| Nr. 4 | Werden ../-Pfade aus dem Archiv bereinigt? |
unzipper 0.12.5 | nein; der Schutz steckt nur in extract(), das Juice Shop nicht nutzt → gestützt
|
| Nr. 7 | Gibt es eine PATCH-Route? | finale-rest 1.2.2 | nein, Aktualisierungen nur über PUT → widerlegt |
Beispiel: Ein Verdachtsfall ist kein Befund (Nr. 7)
Die Behauptung: In Lauf 2 meinte ein Hunter, die Benutzerdatensätze seien gegen PUT und DELETE geschützt, vielleicht aber nicht gegen PATCH. Akzeptiere die REST-Bibliothek finale-rest PATCH, könne jeder Besucher Passwort oder Rolle beliebiger Benutzer ändern.
Die Prüfer: Zwei unabhängige Prüfer behielten den Fall und markierten ihn korrekt als needs_validation. Sie benannten genau, was fehlte: „Registriert die Bibliothek eine PATCH-Route?“ Beantworten konnten sie es nicht, weil der Bibliothekscode nicht vorhanden war.
Die Tatsache: Laut Code registriert finale-rest 1.2.2 Aktualisierungen standardmäßig nur für put, außer die Option updateMethod wird gesetzt, und Juice Shop setzt sie nicht. Eine PATCH-Route existiert nicht, der Verdachtsfall ist falsch.
Die Lehre: Das Werkzeug war ehrlich und hat genau benannt, was es nicht weiß. Trotzdem war der Fall falsch. Die Genauigkeit darf man nicht annehmen, man muss sie messen. Zudem haben die Prüfer in 33 Entscheidungen keinen einzigen Kandidaten verworfen, obwohl mindestens einer falsch war. Fehlen ihnen Informationen, neigen sie offenbar zur Nachsicht.
Warum keine Laufzeitprüfung?
- Juice Shop ist absichtlich gefährlich und sollte nicht auf einem privaten Rechner laufen.
- macOS bietet die geforderte Sandbox nicht; der Skill selbst verweigert die Ausführung.
- Ziel des Seminars ist die Bewertung des Ansatzes, nicht die Behebung von Lücken in Juice Shop.
Für jeden Verdachtsfall enthält NEEDS-VALIDATION.md einen fertigen lokalen Prüfplan, meist auf Basis der vorhandenen Tests des Projekts. Diese Pläne sind die Grundlage für einen späteren Lauf mit Ausführung.
Antwort auf die vierte Seminarfrage
- Verstehen: ja. Jeder Verdachtsfall nennt Angreifer, Eingabe, fehlende Kontrolle, Codespur, fehlende Information und Prüfplan.
- Am Quellcode verifizieren: weitgehend. Alle Referenzen stimmen; der Bibliothekscode klärte fünf Fragen und widerlegte einen Fall.
- Zur Laufzeit verifizieren: noch nicht.
Teil 10: Stärken, Schwächen und Kosten
Stärken
- Genau: keine von 320 Code-Referenzen erfunden.
- Ehrlich: kein Schweregrad ohne Beweis; der Bericht betont, dass „keine bestätigten Funde“ nicht „sicher“ bedeutet.
- Stabil: alle Ergebnisse aus Lauf 1 kehrten in Lauf 2 wieder.
- Über das Lehrbuch hinaus: 12 Verdachtsfälle außerhalb des Challenge-Katalogs, darunter eine Regression im neuesten Commit.
- Gegenseitige Prüfung wirkt: Ein Prüfer korrigierte die Aussage eines Hunters (Pfadtraversierung unter Windows).
- Sichtbare Lücken: Das Ledger zeigt genau, was nicht geprüft wurde.
- Sicheres Scheitern: Beim Ratenlimit und beim Berechtigungsproblem hielt das Werkzeug an und fragte nach, statt zu raten.
Schwächen
- Keine Bestätigung ohne Sandbox: Auf einem Mac bleibt jedes Ergebnis ein Verdacht.
- Fehlender Bibliothekscode: Fragen, die sich in Minuten klären ließen, blieben offen.
- Nachsichtige Prüfer: 0 von 33 verworfen, trotzdem war einer falsch.
- Das Budget bestimmt das Ergebnis: Wie viel validiert wird, hängt von der Budgetplanung ab, nicht vom Code. 23 bzw. 33 Ursachen blieben ungeprüft.
- Hoher Ressourcenbedarf: Die Parallelität (20 Agenten gleichzeitig) übersteigt das Limit eines Pro-Abonnements.
- Nicht deterministisch: Ein einzelner Lauf ist eine Stichprobe, keine Messung.
Kosten
| Posten | Lauf 1 | Lauf 2 |
|---|---|---|
| Dauer | 26 Minuten | 3 Stunden 13 Minuten |
| Agentenaufrufe | 24 | 57, dazu 20 Fehlstarts |
| Geschätzte Kosten zu API-Listenpreisen | nicht gemessen | 51,65 USD |
| Wöchentliches Pro-Kontingent | 23 % | 44 % (+21 Prozentpunkte) |
| Kosten je neuem Verdachtsfall | – | ca. 5,70 USD |
Die Dollarangabe ist eine Schätzung, die Claude Code mit dem Befehl /usage zu offiziellen API-Preisen anzeigt. Im Pro-Abonnement wird sie nicht berechnet, macht die Läufe aber vergleichbar. Der größte versteckte Kostenfaktor ist die Zeit des Menschen, der die Ergebnisse prüfen muss.
Teil 11: Fazit und nächste Schritte
Fazit
Der Cloudflare security-audit skill ist heute ein genauer und ehrlicher „Generator von Verdachtsfällen“, aber noch keine „Urteilsmaschine“. Er findet echte, nachvollziehbare Probleme, auch außerhalb jedes Katalogs, und sagt offen, was er nicht beweisen kann. Damit aus einem Verdachtsfall ein bestätigter Befund wird, braucht es eine Ausführung in einer isolierten Umgebung oder einen prüfenden Menschen. Genau dort liegen die größten Kosten.
Antworten auf die vier Fragen
| Frage | Antwort |
|---|---|
| Wie funktioniert es? | Ein Koordinator zerlegt das Projekt in Einheiten, Hunter suchen parallel, unabhängige Prüfer versuchen zu widerlegen, feste Skripte prüfen die Ausgabe. |
| Welche Werkzeuge sind geeignet? | Der Skill eignet sich gut für belastbare Verdachtsfälle. Ein Vergleich mit klassischer statischer Analyse steht noch aus. |
| Stärken, Schwächen, Kosten? | genau, ehrlich, stabil; aber ohne Sandbox keine Bestätigung, budgetabhängig, ca. 52 USD geschätzt für Lauf 2. |
| Verstehen und verifizieren? | Verstehen ja; am Quellcode weitgehend; zur Laufzeit noch nicht. |
Nächste Schritte
Jede Option verändert genau eine Größe:
- Ausführung in einer isolierten Linux-VM: Der Skill kann Verdachtsfälle dort bestätigen oder verwerfen. Erst damit lässt sich die Genauigkeit messen.
- Ein zweites, kleines reales Projekt: Es zeigt, ob sich die Ergebnisse von einer Trainingsanwendung auf echten Code übertragen lassen. Das entspricht am ehesten der Seminarvorgabe „eher kleine Projekte“.
Quellen
- Cloudflare: security-audit-skill. github.com/cloudflare/security-audit-skill
- Cloudflare Blog: Build your own vulnerability harness. blog.cloudflare.com
- OWASP Juice Shop, Commit 5658473c, inkl.
challenges.yml. github.com/juice-shop/juice-shop - Claude Code Dokumentation: Kosten und
/usage. code.claude.com/docs/en/costs - Claude Code Dokumentation: Skills. code.claude.com/docs/en/skills