AI-Generated Infrastructure: Why Your Terraform Code Is a Security Risk (And How to Fix It)

LLMs can generate Terraform code—but only 3 out of 7 models produce security-compliant IaC. A recent study benchmarks models for secure infrastructure generation and reveals how to use AI safely.

Testen im Zeitalter der KI

Dreißig Jahre lang war das Testen die Steuer, die man fürs Ausliefern bezahlte. Man schrieb die Funktion und danach — falls die Frist es zuließ, falls das Coverage-Gate den Release nicht um 23 Uhr blockierte — die Tests. Der Forschungskorpus erzählt heute eine andere Geschichte. Von 4.358 Software-Engineering-Papieren, die im vergangenen Jahr aufgenommen wurden, ist "automated testing" ein stetiger Keyword-Burst, und eine neue Zelle ist aus dem Nichts entstanden: agentisches Testen. Der Engpass ist nicht verschwunden. Er hat den Besitzer gewechselt.

Die Umkehrung: Wer schreibt den Test?

Das dominierende Muster von 2025–2026 ist nicht länger "ein Mensch schreibt den Test". Es lautet "ein LLM schreibt den Test, ein Mensch prüft ihn". Die Arbeit bündelt sich in drei Bewegungen.

Unit-Test-Generierung aus echtem Code. Benchmarks wie ULT (UnLeakedTestbench) existieren genau deshalb, weil die meisten früheren Benchmarks kontaminiert waren und aus strukturell trivialen Funktionen bestanden, sodass ihre Erfolgszahlen nicht verallgemeinert werden konnten. ULT ist aus echten Python-Funktionen aus der Praxis gebaut, um diesen Bias zu entfernen.

Test-Carving aus Produktions-Traffic. NL2Test, ein Experience-Paper aus Enterprise-Microservice-Teams, verwandelt eine natürlichsprachliche Szenariobeschreibung plus eine aufgezeichnete Traffic-Aufnahme in abspielbare API-Regressionstests — es bindet dynamische Werte aus den Antworten, statt sie hart zu kodieren, und erzeugt Assertions, die der Geschäftslogik folgen statt fragiler Feldgleichheit.

Assertion-Generierung. Das Schwierige war nie der Request; es war das Oracle — was "korrekt" eigentlich bedeutet. NL2Test erzeugt Assertions, die an der geschäftlichen Bedeutung ausgerichtet sind, nicht am bytegenauen Response.

Nichts davon entfernt den Menschen. Es verschiebt ihn nach vorn: vom Verfassen von Boilerplate zum Beurteilen der Intention.

Der Haken: Lesbar ist nicht korrekt

Search-basierte Werkzeuge lieferten hohe Coverage und unlesbare Tests. LLM-Werkzeuge lieferten das Gegenteil — menschenlesbare Tests, die oft nicht kompilierten oder wenig abdeckten. AdverTest formuliert das direkt: Es lässt einen Test-Generierungs-Agenten gegen einen Mutanten-Generierungs-Agenten antreten, der den Code umschreibt, um genau die Fehler einzubauen, die die Tests eigentlich finden sollen. Wenn die Tests auf dem Mutanten weiterhin bestehen, haben sie nie etwas getestet.

Zwei empirische Befunde sollten die Begeisterung kühlen.

1. Benchmarks lügen. ULT zeigt, dass kontaminierte, spielzeugartige Benchmarks jede gemeldete Zahl aufblähen. Ein "90% pass@1"-Ergebnis kann Auswendiglernen sein, keine Fähigkeit.
2. Halluzination ist der Standard. FeedbackLLM berichtet, dass Single-Shot-Prompting dazu neigt zu halluzinieren und redundante Tests auszuspucken, die wenige Zweige berühren. Die Lösung ist eine Multi-Agenten-Schleife mit Line-Coverage-Feedback — dem Modell muss gesagt werden, welche Zweige es verpasst hat.

Eine generierte Testsuite ist eine Hypothese, kein Zertifikat.

Verifikation ohne Ground Truth

Die sauberste Idee im Korpus ist ConVerTest: zuverlässige Tests synthetisieren, ohne die korrekte Implementierung zur Hand zu haben, an der man prüfen könnte. Es kombiniert Self-Consistency (mehrheitsbasierte konvergente Tests), Chain-of-Verification (argumentationsgeleitete Verfeinerung) und Dual-Execution-Agreement (Code und Tests im Konsens gegenseitig validieren). Auf BIGCODEBENCH und LBPP hebt es Testgültigkeit, Zeilenabdeckung und Mutations-Score um bis zu 39%, 28% und 18% über die Baselines. Die praktische Lesart: Man kann eine Suite allein aus einer Spezifikation wachsen lassen und sie dann durch Konsens härten.

# Ein von einem LLM generierter Test — und warum der Mutations-Score, nicht die Coverage, das echte Signal ist
def parse_version(s: str) -> tuple[int, int, int]:
    major, minor, patch = s.split(".")
    return int(major), int(minor), int(patch)

def test_parse_version():
    assert parse_version("1.2.3") == (1, 2, 3)
    assert parse_version("10.0.1") == (10, 0, 1)
    assert parse_version("0.0.0") == (0, 0, 0)  # tötet den `>` -> `>=`-Mutanten

Ein Coverage-Tool meldet 100% für diese Funktion. Ein Mutation-Tool injiziert irgendwo > → >= und fragt: Fällt damit ein Test durch? Wenn nicht, ist deine "100% Coverage" eine Geschichte, die dir das Modell erzählt hat.

Die DORA- und SonarQube-Daten stimmen zu: oberhalb von etwa 80% Coverage ist notwendig, aber nicht hinreichend für geringere Defektdichte in hyperskalierbaren Systemen.

Agentisches Testen und das Oracle-Problem

Das Testen von KI-Systemen holt ein Problem zurück, das das klassische Testen für gelöst hielt: das Oracle. Wenn das System unter Test ein LLM oder ein Agent ist, ist "korrekte Ausgabe" unscharf. Der Korpus antwortet in zwei Richtungen.

• Ausführungs-gegroundete Oracles. Nexus synthetisiert Test-Oracles, indem es Code ausführt, statt zu raten.
• Vision-Language-Oracles. VISOR testet Roboter, indem es beobachtet, was sie tun, nicht nur indem es Zustand liest.

Und das Meta-Muster: The Rise of Agentic Testing beschreibt Multi-Agenten-Systeme, in denen ein Generator, ein Kritiker und ein Runner darüber streiten, ob ein Test taugt. FeedbackLLM macht das Gleiche mit spezialisierten Feedback-Agenten pro Belang. SAINT hebt es auf die Service-Ebene und erzeugt Endpoint- und Szenario-Tests für Enterprise-Java aus statischer Analyse plus LLM-Agenten.

Den Tester testen: Zu viel Vertrauen ist das echte Risiko

Zwei Papers benennen die Gefahr präzise. (Over)Reliance on Test Agents in AI-Assisted Software Testing zeigt, dass Teams KI-generierten Tests mehr vertrauen, als sie sollten. On the risk of coding before testing ist eine empirische Studie, die genau das Anti-Pattern findet, vor dem ihr Titel warnt: Code und Tests gemeinsam zu erzeugen liefert selbstbewusste, falsche Suites.

Der Fehlermodus ist subtil. Ein KI schreibt eine Funktion und einen Test, die miteinander übereinstimmen. Sie sind konsistent, nicht korrekt. Der Test besteht; der Bug wird ausgeliefert. TestLoop, ein Prozessmodell, setzt den Menschen bewusst wieder in die Schleife: Die Maschine schlägt vor, der Mensch verfügt.

KI-Systeme selbst testen

Die zweite Hälfte des Titels ist die neuere Disziplin. Du testest nicht nur mit KI; du testest die KI.

• Prompt-Injection und Halluzination. Harmless Yet Harmful zeigt neutrale Prompts, die unauffällig Halluzinationen steuern — unsichtbar für naive Filter.
• Guardrails. Symbolische Guardrails für domänenspezifische Generierung schlagen probabilistische, wenn Sicherheit auf dem Spiel steht.
• RAG-Faithfulness. SecureRAG-RTL misst, ob abgerufener Kontext die Antwort tatsächlich groundet.
• Risk-Index. Der LLM Scalability Risk Index (LSRI) verwandelt "ist dieses Modell sicher auslieferbar?" in ein bewertetes Framework.
• Können LLMs TUIs testen? Eine Studie von 2026 fragt, ob Modelle überhaupt Terminal-Interfaces ausüben können — die Antwort lautet "manchmal, und noch nicht verlässlich".

Auch die sichere Code-Generierung hat ihr eigenes Red Team: adversarielle Prompts, die LLM-Defenses auf die Probe stellen. Die Lektion wiederholt sich — Evaluation muss adversariell sein, nicht zeremoniell.

Eine Doktrin fürs Zeitalter der KI

Wenn du eine Sache mitnimmst: Der Test ist jetzt ein Artefakt erster Klasse, das du wie Code reviewst. Konkret.

1. Behalte TDD. Schreib die Intention — Spec oder Test — zuerst, lass dann die KI die Implementierung füllen. Das kehrt "coding before testing" in "testing before coding" um, die Richtung, die die empirische Arbeit bevorzugt.
2. Behandle die KI als Junior-Pair, nicht als Oracle. Sie wird mit sich selbst übereinstimmen. Deine Aufgabe ist die Uneinigkeit.
3. Gate auf Mutations-Score, nicht Coverage. Coverage ist der Boden; der Mutations-Score ist die Decke, die dich kümmert.
4. Reviewe das Oracle, nicht nur die Assertion. Ein Test, der das Falsche behauptet, ist schlimmer als gar kein Test — er fabriziert Vertrauen.
5. Lass generierte Tests durch die CI wie jeden anderen Code laufen. Schneide aus, benenne um, lösche. Eine Suite, die nur wächst, ist eine Last.
6. Scheitere ehrlich. Geliehen aus der Stoischen Unix-Disziplin: ein wahrer Satz, der korrekte Exit-Code, nie ein Stack-Trace für eine Umgebungsbedingung. Tests sind, wie dein System die Wahrheit über sich selbst sagt.

# Quality-Gate: Build fehlschlagen lassen, wenn der Mutations-Score fällt
- name: Mutations-Score
  run: |
    mutmut run --paths-to-mutate=src/
    score=$(mutmut results | compute_score)
    test "$score" -ge 80   # Schwache Tests sichtbar machen, nicht verstecken

Testen ist nicht einfacher geworden. Es ist eine Stufe nach oben gewandert. Du testest nicht mehr nur den Code; du testest die Tests, und du testest den Tester. Die Teams, die gewinnen, sind nicht die mit den meisten KI-generierten Tests. Es sind die, die sie reviewen.