KI-gestützte Schwachstellenforschung: Wenn Offensive auf Automatisierung trifft

Die emergenten Cyber-Fähigkeiten von GLM-5.3 und OpenAIs GPT-5.6-Cyber signalisieren einen Wendepunkt in der KI-gestützten Schwachstellenforschung. Hier erfahren Sie, was dies für Defensive Teams bedeutet, welche Guardrails entscheidend sind und warum graphbasiertes Attack Surface Mapping die nächste Grenze darstellt.

Terraform Drift: Erkennen, Klassifizieren, Beheben — ein Playbook nach Schweregraden

Behandeln Sie nicht jeden Drift wie einen P1 — und lassen Sie sicherheitskritische Drifts nicht im Tag-Noise untergehen.

Über mehr als 150 AWS-Terraform-Workspaces hinweg entfernte schweregradbasierte Filterung 73 % der Drift-Alarme und behielt gleichzeitig 94 % der sicherheitsrelevanten Änderungen (tfdrift, arXiv:2608.18173, Open Source unter github.com/sudarshan8417/tfdrift). Diese Zahl trifft den Kern des Problems: Drift-Erkennung ist ein gelöstes Problem, Drift-Triage nicht. Teams ignorieren Drift entweder komplett oder rufen um 3 Uhr nachts jemanden, weil sich ein Tag geändert hat. Dies ist ein Playbook für die goldene Mitte — kontinuierlich erkennen, nach Risiko klassifizieren, mit Absicht beheben.

Was Drift eigentlich ist

„Drift" fasst drei verschiedene Krankheiten zusammen, die unterschiedliche Detektoren und unterschiedliche Fixes brauchen:

1. State-Drift — die echte Infrastruktur weicht von der State-Datei ab. Jemand hat eine Security Group in der Konsole geändert, oder eine Out-of-Band-Automatisierung hat es getan.
2. Code-Drift — State-Datei und echte Infrastruktur passen zusammen, aber keine von beiden zum Main-Branch. Typische Ursache: Jemand hat Code aus einem Feature-Branch oder vom Laptop angewendet und nie gemergt.
3. Attribut-Drift — Provider-Versionen oder API-Defaults ändern still und leise Attribute, die der Code nie explizit gesetzt hat.

Wer diese drei vermischt, diskutiert endlos über „Drift-Probleme“, ohne zur Ursache zu kommen. Der erste Fall braucht eine Ownership-Entscheidung, der zweite einen Workflow-Fix, der dritte ein Versions-Pin und ein Plan-Review.

Erkennung: Plan in der CI, nicht auf Laptops

Die Kern-Primitiva ist ein Flag:

terraform plan -detailed-exitcode
# Exit 0 = keine Änderungen, 1 = Fehler, 2 = Drift/Änderung erkannt

Für die reine Drift-Inspektion ohne Änderungsvorschläge ist der Refresh-Only-Plan das richtige Werkzeug — er vergleicht die echte Infrastruktur mit der State-Datei und zeigt, was zurückgeführt würde:

terraform plan -refresh-only -detailed-exitcode

Entscheidend ist, dass dies zeitgesteuert läuft, nicht nur vor Applies. Drift, der um 14:00 Uhr entsteht, sollte spätestens um 14:30 Uhr sichtbar sein — nicht erst beim nächsten Deployment. Ein minimaler GitHub-Actions-Workflow:

name: drift-detection
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:
jobs:
  drift:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # OIDC, keine langlebigen Keys
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/terraform-readonly
          aws-region: eu-central-1
      - uses: hashicorp/setup-terraform@v3
      - name: Terraform init
        run: terraform init -input=false
      - name: Terraform drift check
        id: plan
        run: terraform plan -refresh-only -detailed-exitcode -no-color
        continue-on-error: true
      - name: Notify on drift
        if: steps.plan.outputs.exitcode == 2
        run: echo "Drift erkannt — Issue öffnen / an Slack senden"

Beachten Sie die Read-Only-Rolle sowohl beim AWS-Credential-Schritt als auch im Backend — die Erkennung braucht nirgendwo Schreibrechte. (Der setup-terraform-Wrapper liefert exitcode als Step-Output; ohne ihn müssten Sie den Exit-Code manuell parsen.)

Zwei Hygieneregeln, die zu oft übersprungen werden:

• Behandeln Sie den State als sensibel — er enthält Secrets im Klartext. Verschlüsseltes Remote-Backend, kein State in Artefakten, und nie auf öffentlichen Runnern ohne OIDC-scoped Credentials.
• Pinnen Sie Provider- und Backend-Versionen im Workflow; ein unangekündigtes Provider-Upgrade während eines Drift-Checks macht aus einem Erkennungslauf einen Änderungslauf.

Klassifizieren: Vier Risikostufen

Das tfdrift-Framework (Open Source, über 60 konfigurierbare Regeln für AWS-, Azure- und GCP-Muster) klassifiziert Drift in vier Risikostufen basierend auf Ressourcentyp und Auswirkung auf Attribute-Ebene. Die Taxonomie lässt sich mit Policy-Code gegen das Plan-JSON problemlos nachbauen:

Eine pragmatische Approximation über das Plan-JSON — ohne Machine Learning:

terraform plan -refresh-only -json > plan.json

# jeder neue weltoffene INGRESS ist kritisch — Egress 0.0.0.0/0 ist der
# harmlose Default, deshalb auf den Regel-Typ filtern
jq '.resource_changes[] | select(.type == "aws_security_group_rule")
    | select(.change.after.type == "ingress")
    | select(.change.after.cidr_blocks // [] | index("0.0.0.0/0"))' plan.json

Die tfdrift-Evaluation stützt den Ansatz: Stufenbasierte Filterung senkt das Alarmvolumen um 73 % und behält 94 % der sicherheitsrelevanten Änderungen — vergleichbare Präzision wie ML-basierte Filter bei einem Bruchteil der Betriebskosten.

Beheben: Entscheiden, wer recht hat — dann Wahrheit herstellen

Jeder Drift löst sich in einen von drei Ausgängen auf:

Die Infrastruktur hat recht. Jemand hat die Realität korrekt angepasst — dann übernehmen statt bekämpfen. Seit Terraform 1.5 geht das deklarativ mit Import-Blocks und generierter Konfiguration:

import {
  to = aws_instance.web
  id = "i-0abc1234def5"
}

terraform plan -generate-config-out=generated.tf

Der Code hat recht. Erneut anwenden. Aber war der Drift manuell verursacht und ist es schon das zweite Mal, haben Sie ein Berechtigungsproblem, kein Terraform-Problem — die Konsolenzugriffe fixen (siehe Prävention unten).

Beides ist falsch. Zuerst den Code fixen, dann einmal anwenden. terraform apply niemals als Drift-Wecker ohne den Code-Fix benutzen — genau so kehrt derselbe Drift nächste Woche zurück.

Ein Anti-Pattern verdient einen eigenen Absatz: manuelle State-Operationen als erste Reaktion. Zu terraform state rm oder handeditiertem State zu greifen, um „die Warnung loszuwerden", verwandelt ein Operations-Ärgernis in eine Disaster-Recovery-Übung. State-Chirurgie ist für echte State-Korruption gedacht — mit unmittelbar vorher gezogenem Backup und Rollback-Plan, nicht für einen Dienstagmittag.

Prävention: Den Schreibpfad verkleinern

Prävention ist unspektakulär und wirksam:

• GitOps als einziger Schreibpfad. Alle Infrastrukturänderungen laufen über PR → Plan → Apply. Atlantis, Terraform Cloud oder eine schlichte CI-Pipeline mit OIDC — das Werkzeug ist zweitrangig gegenüber der Einschränkung, dass niemand vom Laptop aus applied.
• Read-Only-Konsolen für Menschen in der Produktion. SSO-Rollen mit reinen Leserechten; eine Break-Glass-Rolle mit Ablaufzeit und Alerting für echte Notfälle.
• Policy as Code. OPA- oder Sentinel-Regeln, die jeden Plan ablehnen, der kritische Attribute wieder einführt (öffentlicher Ingress, deaktivierte Verschlüsselung, öffentliche Buckets).
• Drift als SLO tracken. Kritischer Drift älter als 24 Stunden ist ein Incident — auf denselben Dashboards wie Ihre Availability-Metriken; den Stack dazu finden Sie im Artikel zur Self-Hosted Observability.

Wo LLMs passen (mit Vorsicht)

Zwei Forschungsergebnisse aus 2026 sollte man kennen, bevor einem „KI-gestützte Drift-Remediation" verkauft wird:

• RIVA (arXiv:2603.02345) zeigt: Agentische Drift-Verifikation bricht zusammen, wenn Tools falsche Daten liefern — die Task-Accuracy eines naiven ReAct-Agents fällt auf 27,3 %. Ihre Verifier-/Tool-Generation-Agents mit Cross-Validation holen die Accuracy auf 50,0 %. Lehre: LLM-Pipelines erben jeden Fehlermodus der Tools, die sie aufrufen.
• Die OpenSentinel-These (RIT, 2026) skizziert die richtige Architektur für Teams mit Souveränitätsanforderungen: selbst gehostete LLMs erhalten strukturierte, lokitätsbewusste Plan-Kontexte, schlagen Remediation-Patches vor, Terraform selbst bleibt die autoritative Detektionsinstanz, jeder Vorschlag wird mit einem Refresh-Only-Plan validiert, und Menschen mergen den PR. Das LLM schlägt vor; Terraform verfügt.

Das passt direkt zu den Überlegungen in Text-zu-Terraform und Sicherheit: Generierter Infrastrukturcode ist ein Entwurf fürs Review, nie ein autonomer Schreibpfad.

Das Playbook, komprimiert

• Zeitgesteuerter Refresh-Only-Plan in der CI, Exit-Code 2 löst Triage aus
• Detektion läuft mit Read-Only-Credentials, State liegt verschlüsselt im Backend
• Plan-JSON durch einen Stufen-Klassifikator (kritisch → Alarm, kosmetisch → ignorieren)
• Import-Blocks und -generate-config-out für die Übernahme beabsichtigter Drifts
• Code-Fix vor jedem Reconciliation-Apply — keine Blind-Reverts
• Einziger Schreibpfad via GitOps; Read-Only-Konsolen mit Break-Glass
• Drift-Alter-Metrik auf demselben Dashboard wie Availability

Drift verschwindet nie — Infrastruktur wird mit Kollegen, Vendoren und Cloud-Automatisierung geteilt, die Ihre Repositories nicht lesen. Das Ziel ist nicht Null Drift, sondern kritischer Drift, der Stunden lebt, nicht Wochen — und ein Alarmkanal, den niemand stummgeschaltet hat.