View source for KI-Sicherheitsanalyse-security-audit-skill

__TOC__

== 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?

== 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: 

{| class="wikitable"
! Bestandteil !! Zweck
|-
| <code>SKILL.md</code> || Einstieg: Betriebsarten, Sicherheitsregeln, Profile, Budget, Schweregrade
|-
| <code>RECONNAISSANCE.md</code>, <code>HUNTING.md</code>, <code>ATTACK-CLASSES.md</code> || Aufklärung, Suchaufträge und Angriffsklassen
|-
| 10 Begleitdateien || Spezialwissen (z. B. Web/Authentifizierung, Client-Seite, KI/LLM), nur bei Bedarf geladen
|-
| <code>VALIDATION-AND-REPORTING.md</code> || Validierung, Verifikation und Bericht
|-
| <code>report-schema.json</code> und zwei <code>.cjs</code>-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 ===
[[File:Ablauf 6 Phasen.png|800px|thumb|center|Ablauf des Security-audit Skill]]
# '''Aufklärung:''' Vier Agenten erfassen parallel Technick, Benutzerrollen, Vertrauensgrenzen und Eingabepunkte. Daraus entstehen <code>architecture.md</code> und das Coverage Ledger.
# '''Suche:''' ''Hunter''-Agenten prüfen je eine Einheit mit passenden Angriffsklassen; ''Kritiker''-Agenten suchen ungeprüfte Bereiche.
# '''Validierung:''' Jeder Kandidat geht an einen frischen ''Prüfer'', der die Suche nicht kennt und den Fund zu widerlegen versucht.
# '''Strukturierte Ausgabe:''' Die Urteile landen in <code>findings.json</code> und werden gegen das Schema geprüft.
# '''Erneute Verifikation:''' Weitere frische Agenten prüfen die endgültigen Aussagen ein zweites Mal.
# '''Bericht:''' Erst dann entstehen <code>REPORT.md</code> und <code>NEEDS-VALIDATION.md</code>, 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 ===
{| class="wikitable"
! Urteil !! Bedeutung !! Schweregrad
|-
| <code>confirmed</code> || Vollständige Spur durch den Code '''und''' ein lokal beobachtetes Ergebnis || ja
|-
| <code>needs_validation</code> || Quellcodebasierter Verdacht, bei dem genau ein Fakt fehlt; mit Prüfplan || nie
|-
| <code>rejected</code> || Von einem Prüfer widerlegt || nein
|}

== Versuchsaufbau ==
== Ergebnisse ==
== Verifikation der Ergebnisse ==
== Bewertung ==
== Fazit ==
== Quellen ==
== Anhang: Verwendete Aufträge ==