ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code

Der Artikel stellt ESAA-Security vor, eine ereignisgesteuerte Architektur für verifizierbare Sicherheitsaudits von KI-generiertem Code, die durch eine strikte Trennung von heuristischer Agentenlogik und deterministischer Zustandsänderung über append-only-Logs eine nachvollziehbare, reproduzierbare und beweisbare Sicherheitsprüfung gewährleistet.

Das Wesentliche

Stellen Sie sich vor, Sie bauen ein riesiges Haus, aber anstatt dass ein einzelner Architekt jeden Stein legt, nutzen Sie einen hochintelligenten Roboter-Assistenten (eine KI), der Ihnen hilft, die Pläne zu zeichnen und sogar Mauern zu setzen. Das ist toll, denn es geht viel schneller. Aber hier liegt das Problem: Der Roboter ist vielleicht sehr kreativ und schnell, aber er vergisst manchmal, ob die Tür auch wirklich abgeschlossen ist, oder er baut eine Treppe, die ins Leere führt.

Das ist genau das Szenario, das in dem Papier ESAA-Security behandelt wird. Es geht darum, wie man sicherstellt, dass KI-generierter Code nicht nur funktioniert, sondern auch sicher ist.

Hier ist die einfache Erklärung, wie ESAA-Security funktioniert, mit ein paar anschaulichen Vergleichen:

1. Das Problem: Das "Gespräch" ist nicht genug

Bisher haben viele versucht, Sicherheitslücken zu finden, indem sie einfach mit der KI ein Gespräch führten: "Hey KI, schau dir diesen Code an und sag mir, ob er unsicher ist."

Das ist wie wenn Sie einen Freund bitten, Ihr Haus zu inspizieren, während Sie ihm nur mündlich Anweisungen geben. Der Freund könnte etwas übersehen, sich später nicht mehr erinnern, was er genau gesagt hat, oder Sie könnten nicht beweisen, dass er wirklich den Keller überprüft hat. Es ist zu unstrukturiert und schwer nachzuvollziehen.

2. Die Lösung: Ein "Schwarzer Kasten" für jede Entscheidung

ESAA-Security schlägt vor, die KI nicht wie einen Gesprächspartner zu behandeln, sondern wie einen strengen Bauarbeiter in einem hochgesicherten System.

Stellen Sie sich das System wie eine unveränderliche Baustelle vor:

• Kein Radieren: Alles, was passiert, wird in ein "Schwarzes Buch" (ein sogenanntes Event-Log) geschrieben. Man kann nichts löschen oder ändern. Wenn die KI sagt: "Ich habe die Tür geprüft", steht das für immer da.
• Schritt-für-Schritt-Plan: Die KI darf nicht einfach wild herumwuseln. Sie muss einen genauen Plan (einen "Playbook") befolgen. Sie muss erst sagen: "Ich beantrage jetzt, die Elektrik zu prüfen" (Claim). Erst wenn das genehmigt ist, darf sie arbeiten.
• Der Aufseher (Orchestrator): Es gibt einen strengen Aufseher. Die KI kann keine Mauern selbst bauen. Sie muss ihre Absichten dem Aufseher zeigen. Der Aufseher prüft: "Darf das sein? Passt das zum Plan?" Wenn ja, wird es ins Schwarze Buch geschrieben. Wenn nein, wird es abgelehnt.

3. Der Ablauf: Vier Phasen wie eine Detektiv-Reise

Der Prozess ist in vier klare Etappen unterteilt, wie eine Detektivgeschichte:

1. Die Erkundung (Reconnaissance): Der Detektiv geht um das Haus herum und macht eine Liste: "Hier sind die Fenster, hier die Türen, hier ist der Stromkasten." Er sammelt Fakten, ohne noch zu urteilen.
2. Die Inspektion (Domain Audit): Jetzt geht es in die einzelnen Räume. Der Detektiv prüft systematisch: "Ist das Schloss an der Hintertür stark genug? Ist der Rauchmelder an?" Er folgt einer Checkliste mit 95 verschiedenen Punkten.
3. Die Bewertung (Risk Classification): Alle gefundenen Mängel werden gesammelt. "Okay, das Schloss ist okay, aber das Fenster im Keller ist offen." Die Mängel werden nach Wichtigkeit sortiert (Kritisch, Hoch, Mittel, Gering).
4. Der Bericht (Final Reporting): Am Ende gibt es nicht nur eine lange, verworrene Geschichte. Es gibt einen klaren, strukturierten Bericht: "Hier sind die 3 wichtigsten Dinge, die Sie sofort reparieren müssen, und hier ist genau, wie Sie das tun."

4. Warum ist das besser? (Der "Replay"-Trick)

Das Coolste an ESAA-Security ist die Wiederholbarkeit.

Stellen Sie sich vor, jemand zweifelt später an Ihrem Sicherheitsbericht. Bei einer normalen KI-Inspektion müssten Sie hoffen, dass die KI sich noch daran erinnert, was sie getan hat. Bei ESAA-Security können Sie den gesamten Prozess wie ein Video zurückspulen.

Da jede einzelne Handlung (jeder "Event") im unveränderlichen Schwarzen Buch steht, kann man den Prozess exakt neu abspielen. Man sieht genau:

• Welcher Schritt wurde wann gemacht?
• Wer hat ihn genehmigt?
• Welche Beweise lagen vor?

Das macht den Bericht unbestechlich. Man kann nicht behaupten, die KI hätte etwas erfunden, weil der "Beweis" (der Eintrag im Log) da ist.

Zusammenfassung in einem Satz

ESAA-Security verwandelt das chaotische "Gespräch" mit einer KI in einen strengen, nachvollziehbaren und dokumentierten Sicherheitsprozess, bei dem jeder Schritt wie ein unveränderlicher Eintrag in einem Tagebuch festgehalten wird, damit man später genau nachvollziehen kann, warum das Haus (oder der Code) sicher ist – oder wo genau die Lücke ist.

Es geht also nicht darum, ob die KI Fehler findet, sondern darum, wie sie sie findet und ob man dem Ergebnis vertrauen kann, weil der Weg dorthin lückenlos dokumentiert ist.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code" auf Deutsch.

1. Problemstellung

Die zunehmende Nutzung von KI-gestützter Softwareentwicklung (insbesondere durch Large Language Models, LLMs) hat die Entwicklungsgeschwindigkeit erhöht, jedoch ein bestehendes ingenieurtechnisches Problem verschärft: Systeme können funktional korrekt, aber strukturell unsicher sein.

Die aktuellen Ansätze zur Sicherheitsprüfung mittels Prompting mit LLMs leiden unter folgenden Mängeln:

• Uneinheitliche Abdeckung: Die Prüfung ist oft willkürlich und nicht vollständig.
• Schwache Reproduzierbarkeit: Ergebnisse lassen sich schwer wiederholen.
• Fehlende Nachvollziehbarkeit: Es gibt keinen unveränderlichen Prüfpfad (Audit Trail).
• Unstrukturierte Ergebnisse: Befunde werden oft als freie Prosa geliefert, was eine konsistente Risikobewertung und Nachverfolgung erschwert.
• Governance-Lücke: Bei agentic Workflows (autonome Agenten) über lange Zeiträume führen veränderlicher Zustand (mutable state) und unvollständiger Kontext zu operativen Risiken.

Das Kernproblem ist nicht nur das Finden von Schwachstellen, sondern die fehlende Fähigkeit, den Audit-Prozess selbst als einen überprüfbaren, nachvollziehbaren und staatlich konsistenten Prozess zu gestalten.

2. Methodik: Die ESAA-Security-Architektur

Das Paper stellt ESAA-Security als domänenspezifische Spezialisierung der allgemeinen ESAA-Architektur (Event-Sourced, Agent-Assisted) vor. Der Ansatz verschiebt den Fokus von einer „freien Konversation" mit einem LLM hin zu einem governed execution pipeline (gesteuerten Ausführungsprozess).

Kernprinzipien:

• Event Sourcing & CQRS: Der „Wahrheitsquell" (Source of Truth) ist nicht ein momentaner Snapshot des Repositorys, sondern ein append-only Event-Log. Der aktuelle Zustand wird deterministisch durch Replay und Projektion dieser Events rekonstruiert.
• Getrennte Zuständigkeiten:
  • Agenten: Emittieren strukturierte Absichten (Intentions) unter strengen Verträgen (Contracts).
  • Orchestrator: Validiert diese Absichten, persistiert akzeptierte Outputs im Event-Log und baut abgeleitete Ansichten (Views) neu auf.
• Strukturierte Outputs: Agenten dürfen keine direkten Zustandsänderungen vornehmen. Sie müssen strukturierte Daten emittieren, die gegen Schemata validiert werden.

Der Audit-Prozess (4 Phasen, 26 Aufgaben, 16 Domänen, 95 Checks):
Der Workflow ist in vier klar definierte Phasen unterteilt:

1. Reconnaissance (Aufklärung): Identifikation des Tech-Stacks, der Architektur, Datenflüsse und Angriffsvektoren.
2. Domain Audit Execution: Ausführung von playbook-gesteuerten Audits pro Sicherheitsdomäne (z. B. Authentifizierung, Autorisierung, Eingabevalidierung, KI-Sicherheit).
3. Risk Classification: Konsolidierung der Befunde in Schwachstelleninventare, Zuweisung von Schweregraden (Critical bis Info) und Erstellung von Risikomatrizen.
4. Final Reporting: Generierung technischer Remediationsanleitungen, Best-Practice-Leitfäden, Executive Summaries und des finalen Berichts (Markdown/JSON).

Ausführungsprotokoll & Invarianten:
Um die Integrität zu gewährleisten, gelten strikte Invarianten:

• Claim-before-work: Eine Aufgabe muss zuerst beansprucht werden, bevor Arbeit geleistet wird.
• Complete-after-work: Der Abschluss erfolgt nur mit Verifizierungsnachweisen.
• Lock Ownership: Nur der aktuelle Akteur darf eine Aufgabe abschließen.
• Done Immutability: Ein abgeschlossener Task kann nicht stillschweigend neu geöffnet werden; Korrekturen erfordern explizite Issue-Flows.
• Fail-Closed-Validierung: Ungültige Übergänge oder Schema-Verletzungen werden abgelehnt, bevor sie den Zustand beeinflussen.

3. Wichtige Beiträge

Das Paper liefert vier wesentliche Beiträge:

1. Spezialisierung: Einführung von ESAA-Security als domänenspezifische Architektur für evidenzbasierte Sicherheitsaudits von KI-generiertem Code.
2. Governed Pipeline: Definition eines Audit-Prozesses, der strukturierte Agenten-Outputs, append-only Event-Persistenz, deterministische Reprojektion und Replay-basierte Verifizierung kombiniert.
3. Operationalisierung: Umsetzung der Sicherheitsprüfung in ein konkretes Schema mit 4 Phasen, 26 Aufgaben, 16 Sicherheitsdomänen (inkl. OWASP Top 10, ASVS und spezifische KI-Risiken) und 95 ausführbaren Checks.
4. Neue Evaluierungsrahmen: Verschiebung des Evaluierungsziels von der bloßen Anzahl gefundener Schwachstellen hin zu Traceability (Nachverfolgbarkeit), Reproduzierbarkeit, expliziter Abdeckung, Vollständigkeit der Artefakte und Nützlichkeit der Remediation.

4. Ergebnisse und Outputs

Das Framework generiert keine freien Textberichte als primäres Produkt, sondern leitet diese aus einem verifizierten Event-Stream ab. Die Outputs umfassen:

• Strukturierte Befunde: Auf Check-Ebene gebundene Objekte (ID, Status, Schweregrad, Code-Evidenz, Erklärung, Lösung).
• Schwachstelleninventar & Risikomatrix: Systemweiter Sicherheitszustand, sortiert nach Schweregrad und Auswirkung (CIA-Prinzip).
• Empfehlungsschicht: Konkrete technische Fixes und domain-spezifische Best Practices.
• Finaler Bericht: Ein maschinenlesbarer (JSON) und menschlesbarer (Markdown) Bericht, der lückenlos auf die zugrundeliegenden Events und Artefakte zurückführbar ist.

Ein entscheidendes Ergebnis ist, dass der finale Bericht nur dann autoritativ ist, wenn er die Projektion einer zulässigen Sequenz von Zustandsübergängen darstellt.

5. Bedeutung und Implikationen

Die Bedeutung von ESAA-Security liegt in einem fundamentalen Paradigmenwechsel für die KI-gestützte Sicherheit:

• Vom Prompting zum Governance-Problem: Sicherheitsaudits sollten nicht als Prompting-Herausforderung, sondern als gesteuertes Ausführungsproblem betrachtet werden.
• Vertrauenswürdigkeit durch Architektur: Das Vertrauen verschiebt sich von der „Meinung des Modells" hin zu einem „protokollvaliden, replay-verifizierbaren Audit-Zustand".
• Nachhaltigkeit für KI-Software: Da KI-generierter Code oft schnell und ohne traditionelle Sicherheitskontrollen entsteht, bietet ESAA-Security einen Mechanismus, um Sicherheit in den Entwicklungsprozess zu integrieren, ohne die Geschwindigkeit zu opfern, aber mit der nötigen Nachvollziehbarkeit.

Einschränkungen:
Das Paper räumt ein, dass die Qualität der Playbooks entscheidend ist (schlechte Playbooks führen zu gut governierten, aber inhaltlich schwachen Audits). Zudem ersetzt das System keine Penetrationstests oder Zertifizierungen, sondern dient als maturer interner Audit-Mechanismus.

Fazit:
ESAA-Security bietet einen architektonischen Rahmen, der die Nachvollziehbarkeit, Reproduzierbarkeit und Struktur von Sicherheitsaudits in der Ära der KI-generierten Software sicherstellt. Es transformiert den Audit von einer subjektiven Analyse in einen überprüfbaren, datengesteuerten Prozess.