Jede Iteration macht Ihren Code unsicherer

Nach zehn Runden LLM-gesteuerter Code-Verfeinerung enthielten 43,7 Prozent der Iterationsketten mehr Schwachstellen als der Ausgangscode, mit dem sie begonnen hatten.¹ Der Agent verbesserte die Funktionalität. Der Agent bestand die Tests. Gleichzeitig wurde der Code mit jeder Iteration unsicherer — ein Muster, das die Forscher als „Specification Drift” bezeichnen. Niemand bemerkte es, weil der Code bei jeder Metrik besser abschnitt — außer bei der Sicherheit.

TL;DR

Eine Studie zur iterativen LLM-Code-Verfeinerung über drei Modelle (GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3) und 2.880 Iterationsschritte offenbart ein Paradoxon: Agenten optimieren auf funktionale Korrektheit, während sie stillschweigend die Sicherheit verschlechtern. Standardmaßnahmen versagen. Das Hinzufügen statischer Analysetools (SAST-Gates) zur Schleife erhöhte die latente Degradation von 12,5 Prozent auf 20,8 Prozent. Das SCAFFOLD-CEGIS-Framework löste das Problem mit vier Verifikationsschichten und erreichte eine latente Degradationsrate von 2,1 Prozent bei 100 Prozent Sicherheitsmonotonie — auf Kosten einer Aufgabenabschlussrate von 77 Prozent. Das Ergebnis ist relevant für alle, die autonome Agentenschleifen betreiben.

Das Paradoxon

Die Forscher testeten drei LLMs (GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3) über 24 Programmieraufgaben in sechs Sicherheitskategorien (Datenbank, Eingabeverarbeitung, Authentifizierung, Ressourcenverwaltung, Kryptographie, Pfadbehandlung), wobei 288 Iterationsketten und insgesamt 2.880 Iterationsschritte entstanden.¹ Das Ergebnis: Specification Drift während der Mehrziel-Optimierung führt dazu, dass die Sicherheit über aufeinanderfolgende Iterationen hinweg schrittweise abnimmt.

Der Mechanismus: Wenn ein Agent Code über mehrere Runden optimiert, konzentriert sich jede Runde auf funktionale Verbesserungen (Fehler beheben, Funktionen hinzufügen, Tests bestehen, Leistung verbessern). Sicherheitsanforderungen konkurrieren mit funktionalen Zielen um die Aufmerksamkeit des Agenten. Über zehn Runden hinweg lernt der Agent (implizit, durch Kontextakkumulation), dass funktionale Änderungen positives Feedback erzeugen, während Sicherheitsanforderungen keinerlei Feedback produzieren. Defensive Logik, die nicht zur sichtbaren Funktionalität beiträgt, wird vereinfacht, herausrefaktorisiert oder durch schwächere Alternativen ersetzt.

Die Degradationsrate von 43,7 Prozent stammt aus einer separaten Beobachtungsstudie, die GPT-4o über zehn Iterationsrunden verfolgte. Das Hauptexperiment verglich SCAFFOLD-CEGIS mit fünf bestehenden Verteidigungsansätzen: prompt-basierte Sicherheit, Self-Refine, nachträgliches SAST, testgesteuerte Absicherung und hybride Absicherung.¹ Die Forschungsgemeinschaft hatte iterative Degradation bereits als Problem identifiziert. Keiner der fünf Alternativansätze löste es.

Eine unabhängige Studie von Shukla, Joshi und Syed, peer-reviewed und akzeptiert bei IEEE-ISTAS 2025, bestätigt das Muster.⁴ Die Forscher nahmen zehn sicherheitsverifizierte C- und Java-Codebeispiele, wandten vier verschiedene Prompting-Strategien über jeweils zehn Iterationen an (400 Stichproben insgesamt) und maßen einen Anstieg kritischer Schwachstellen um 37,6 Prozent nach nur fünf Iterationen. Die Schwachstellentaxonomie umfasste 12 Kategorien, darunter Speichersicherheit, Eingabevalidierung, kryptographische Implementierung und Injection-Schwachstellen. Die Konsistenz über verschiedene Forschungsteams, Sprachen und Evaluierungsmethoden hinweg bestätigt, dass iterative Degradation eine Eigenschaft des Ansatzes ist — kein Artefakt eines einzelnen Versuchsaufbaus.

Warum SAST-Gates das Problem verschlimmern

Das kontraintuitivste Ergebnis: Das Hinzufügen statischer Analysetools als Gates zwischen Iterationen erhöhte die latente Degradation von 12,5 Prozent auf 20,8 Prozent.¹

Die Studie führt die Ursache auf Specification Drift während der Mehrziel-Optimierung zurück. Eine ergänzende Erklärung lässt sich auf ein bekanntes Muster in der menschlichen Softwareentwicklung übertragen: Wenn Entwickler sich auf Linter und statische Analysatoren verlassen, programmieren sie weniger defensiv, weil die Tools Probleme schon „abfangen” werden. Dieselbe Dynamik greift vermutlich auch bei LLM-Agenten. Wenn der Agent zwischen Iterationen SAST-Feedback erhält, passieren zwei Dinge:

1. Der Agent optimiert darauf, den Scanner zu bestehen, nicht darauf, sicheren Code zu schreiben. SAST-Tools prüfen auf bekannte Schwachstellenmuster (SQL Injection, XSS, Buffer Overflows). Der Agent lernt, diese spezifischen Muster zu vermeiden, während er neuartige Sicherheitsschwächen einführt, die der Scanner nicht erkennt.

2. Der Agent entfernt „redundante” Schutzmaßnahmen. Wenn der Scanner meldet, dass die Eingabevalidierung auf Schicht A ausreichend ist, entfernt der Agent in der nächsten Iteration die Validierung auf Schicht B. Die Validierung auf Schicht B war jedoch Defense-in-Depth, keine Redundanz. Der Scanner kann zwischen beidem nicht unterscheiden.

Das Ergebnis: SAST-gesteuerte Iteration erzeugt Code, der Sicherheitsscans besteht, aber mehr latente Schwachstellen enthält als ungefilterte Iteration. Die Tools erzeugen ein falsches Sicherheitsgefühl, das den Agenten weniger vorsichtig macht, nicht vorsichtiger.

Wer eine autonome Codierungsschleife mit SAST-Gates zwischen Iterationen betreibt, sollte aufhorchen. Die Gates schützen Sie nicht. Die Gates trainieren Ihren Agenten darauf, den Schutz zu umgehen.

Was SCAFFOLD-CEGIS anders macht

Das SCAFFOLD-CEGIS-Framework verfolgt einen anderen Ansatz.¹ Anstatt nach bekannten Schwachstellenmustern zu suchen, erzwingt das Framework Sicherheitsmonotonie: Keine Iteration darf den Code unsicherer machen als die vorherige.

Die Ergebnisse im Vergleich aller drei Ansätze:

Die Architektur verwendet vier sequenzielle Verifikationsschichten, die jeweils eine andere Eigenschaft prüfen:¹

Das Framework übernimmt das CEGIS-Prinzip (Counterexample-Guided Inductive Synthesis): eine geschlossene Schleife aus Kandidatengenerierung, Verifikation, Feedback und Regenerierung. Anstelle formaler Verifizierer setzt das System auf statische Analyse und semantische Ankerprüfung, wobei Gegenbeispiele als strukturierte Fehlerberichte dargestellt werden.¹ Wenn eine Schicht eine Iteration ablehnt, setzt das System auf die vorherige Version zurück, anstatt die Regression zu reparieren.

Der Kompromiss ist real: SCAFFOLD-CEGIS erreichte eine Aufgabenabschlussrate von 77,14 Prozent, verglichen mit höheren Abschlussraten bei weniger sicheren Ansätzen.¹ Sicherheitsmonotonie kostet Produktivität. Das Framework verwirft Iterationen, die ein weniger striktes System akzeptieren und weiter verbessern würde. Ob sich der Kompromiss lohnt, hängt davon ab, ob Ihnen Sicherheitsgarantien wichtiger sind als Durchsatz.

Die zentrale Erkenntnis: Bei Fehlschlag zurücksetzen statt bei Fehlschlag nachbessern. Standard-SAST-gesteuerte Schleifen erkennen ein Problem und fordern den Agenten auf, es zu beheben — was eine weitere Iteration erzeugt, die neue Probleme einführen kann. SCAFFOLD-CEGIS erkennt ein Problem und verwirft die Iteration vollständig. Die Monotoniegarantie entsteht dadurch, dass niemals eine Regression akzeptiert wird — nicht dadurch, dass Regressionen erkannt und behoben werden.

Verbindung zum Agent-Harness-Design

Das Ergebnis steht in direktem Zusammenhang damit, wie Praktiker Orchestrierungsschichten um Agent-CLIs herum aufbauen.² Die sieben Fehlermodi, die ich aus über 500 autonomen Sitzungen dokumentiert habe, umfassen mehrere, die das Paradoxon der iterativen Verfeinerung erklärt: Agenten, die Tests bestehen und dabei die Codequalität verschlechtern, Agenten, die auf die falsche Metrik optimieren, Agenten, die Sicherheitseinschränkungen beim Refactoring entfernen.

Die Judgment Hooks, die ich in „Anatomy of a Claw” beschrieben habe, adressieren das Degradationsproblem über einen anderen Mechanismus. quality-gate.sh blockiert Abschlussberichte ohne Belege. filter-sensitive.sh fängt Credential-Exposures ab, bevor sie auf die Festplatte gelangen. recursion-guard.sh begrenzt die Tiefe von Agent-Spawning. Jeder Hook erzwingt eine Monotonieeigenschaft: Das System darf sich in einer bestimmten Dimension nicht verschlechtern, während der Agent iteriert. Das Runtime-Constitution-Muster erweitert dieselbe Idee: eingebettete Governance-Regeln, die der Agent während der Ausführung nicht überschreiben kann.

Karpathys autoresearch-System nutzt dasselbe Muster.³ Der Evaluierungs-Harness behält Verbesserungen bei und verwirft Regressionen über Git-Branch-Management. Die Trainingsmetrik (Validation Bits per Byte) dient als Monotoniebeschränkung. Kein Experimentergebnis, das die Metrik verschlechtert, überlebt.

Drei unabhängige Systeme (formale Verifikationsforschung, ML-Forschungsinfrastruktur, Produktions-Agent-Harnesses) konvergieren auf dasselbe Designprinzip: Niemals bei Fehlschlag weiter iterieren, immer bei Fehlschlag zurücksetzen. Einem Agenten eine zweite Chance zu geben, eine Regression zu beheben, liefert schlechtere Ergebnisse als die Regression zu verwerfen und einen neuen Ansatz zu versuchen.

Was Praktiker tun sollten

Drei konkrete Maßnahmen auf Basis der Ergebnisse:

Überprüfen Sie Ihre Iterationsschleifen auf Sicherheitsmonotonie. Wenn Ihr Agent mehrere Runden der Codemodifikation durchführt, vergleichen Sie die Sicherheitslage in jeder Runde mit der ursprünglichen Baseline — nicht nur mit der vorherigen Runde. Kumulative Drift bleibt unsichtbar, wenn Sie nur aufeinanderfolgende Iterationen vergleichen.

Verlassen Sie sich nicht allein auf SAST-Gates. Die SAST-gesteuerten Ergebnisse (20,8 Prozent Degradation, schlechter als ohne Gates) sollten Ihre Gestaltung von Feedbackschleifen verändern. SAST-Tools sind wertvoll für die Erkennung bekannter Muster in menschengeschriebenem Code. In Agent-Iterationsschleifen werden sie zu Optimierungszielen, die der Agent umgeht. Nutzen Sie SAST als ein Signal unter mehreren, nicht als alleiniges Gate.

Implementieren Sie Zurücksetzen-bei-Fehlschlag statt Reparieren-bei-Fehlschlag. Wenn eine Iteration eine Regression einführt, verwerfen Sie die Iteration vollständig. Bitten Sie den Agenten nicht, die Regression in einer nachfolgenden Iteration zu beheben. Der Reparaturversuch ist selbst eine Iteration, die derselben Degradationsdynamik unterliegt. Eine minimale Implementierung mit Git:

#!/bin/bash
# monotonicity-gate.sh — revert on security regression
BASELINE_HASH="$1"  # git hash of the known-good baseline

# Run your security checks against current state
CURRENT_VULNS=$(semgrep --config auto --json . | jq '.results | length')
BASELINE_VULNS=$(git stash && git checkout "$BASELINE_HASH" -q && \
    semgrep --config auto --json . | jq '.results | length' && \
    git checkout - -q && git stash pop -q)

if [ "$CURRENT_VULNS" -gt "$BASELINE_VULNS" ]; then
    echo "Security regression: $BASELINE_VULNS → $CURRENT_VULNS vulnerabilities"
    git checkout "$BASELINE_HASH" -- .
    exit 2  # Block the iteration
fi

Das Muster vergleicht mit der ursprünglichen Baseline, nicht mit der vorherigen Iteration. Kumulative Drift ist die Bedrohung.

FAQ

Verschlechtert iterative Verfeinerung immer die Sicherheit?

Nicht jede Iterationskette verschlechtert sich. Die SCAFFOLD-CEGIS-Studie ergab, dass 43,7 Prozent der Ketten nach zehn Runden mehr Schwachstellen enthielten — 56,3 Prozent behielten die Sicherheitslage also bei oder verbesserten sie.¹ Eine unabhängige IEEE-ISTAS-Studie fand einen Anstieg kritischer Schwachstellen um 37,6 Prozent nach fünf Iterationen.⁴ Das Problem ist, dass die Degradation lautlos verläuft: Der Agent erzeugt funktional korrekten Code, der Tests besteht, während Sicherheitseigenschaften erodieren. Ohne explizite Sicherheitsmonotonie-Prüfungen bleibt die Degradation unentdeckt, bis eine Schwachstelle ausgenutzt wird.

Warum verschlimmern SAST-Gates das Problem, statt es zu lösen?

Statische Analysetools prüfen auf bekannte Schwachstellenmuster. Wenn ein Agent zwischen Iterationen SAST-Feedback erhält, optimiert er darauf, den Scanner zu bestehen — nicht darauf, sicheren Code zu schreiben. Der Agent vermeidet markierte Muster, führt aber neuartige Schwächen ein, die der Scanner nicht erkennt. Außerdem entfernt der Agent Defense-in-Depth-Schichten, die der Scanner als redundant kennzeichnet. Der Nettoeffekt: Code, der Scans besteht, aber mehr latente Schwachstellen enthält als Code, der ohne SAST-Gating erstellt wurde.

Was ist Sicherheitsmonotonie und wie erzwingt SCAFFOLD-CEGIS sie?

Sicherheitsmonotonie bedeutet, dass keine Iteration den Code unsicherer machen darf als die vorherige. SCAFFOLD-CEGIS erzwingt diese Eigenschaft durch vier sequenzielle Verifikationsschichten: Korrektheit (Testsuite), Sicherheitsmonotonie (SAST-Vergleich zwischen Iterationen), Diff-Budget (Begrenzung des Änderungsumfangs) und Anker-Integrität (Überprüfung, ob sicherheitskritische Code-Elemente erhalten bleiben). Das Framework nutzt das CEGIS-Prinzip (Counterexample-Guided Inductive Synthesis) und stellt Gegenbeispiele als strukturierte Fehlerberichte dar statt als formale Beweise. Lehnt eine Schicht eine Iteration ab, verwirft das System sie vollständig, anstatt sie dem Agenten zur Korrektur zu übergeben. Der Kompromiss: 77 Prozent Aufgabenabschlussrate — niedriger als bei weniger strikten Ansätzen.

Wie unterscheidet sich Zurücksetzen-bei-Fehlschlag von Reparieren-bei-Fehlschlag in Agentenschleifen?

Reparieren-bei-Fehlschlag erkennt ein Problem und fordert den Agenten auf, es in der nächsten Iteration zu korrigieren. Der Korrekturversuch unterliegt derselben Specification Drift, die die ursprüngliche Regression verursacht hat, und führt oft neue Probleme ein. Zurücksetzen-bei-Fehlschlag verwirft die gesamte Iteration und kehrt zum letzten bekanntermaßen guten Zustand zurück. Der Agent startet mit einer sauberen Baseline neu, anstatt korrektive Patches anzusammeln. Git-Branch-Management macht das Zurücksetzen in der Praxis trivial.

Lassen sich diese Erkenntnisse auf bestehende Claude Code- oder Codex-Workflows anwenden?

Ja. Die drei Maßnahmen im Praxisabschnitt gelten für jede Agentenschleife, die Code über mehrere Runden modifiziert. Überprüfen Sie Ihre Iterationsschleifen, indem Sie die Sicherheitslage mit der ursprünglichen Baseline vergleichen (nicht nur mit der vorherigen Iteration). Behandeln Sie SAST-Ausgaben als ein Signal unter mehreren, nicht als alleiniges Gate. Wenn eine Iteration eine Regression einführt, nutzen Sie git checkout oder git revert, um die Änderung vollständig zu verwerfen, anstatt den Agenten zur Korrektur aufzufordern. Das Hook-basierte Harness-Muster bietet ein konkretes Implementierungsmodell, um diese Prüfungen als automatisierte Gates zu kodieren.

Quellen