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?

Grundlagen

Werkzeuglandschaft

• 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

Versuchsaufbau

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.

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.