KI-generierte Infrastruktur: Warum dein Terraform-Code eine Sicherheitslücke ist (und wie du das änderst)

Docker Hub Under the Microscope: 90% of Top Images Have Critical Vulnerabilities – Here’s How to Fix It

A recent study analyzes the most popular Docker Hub images, revealing alarming security risks: flaws in base images affect all downstream deployments. Learn how to secure your containers.

KI-generierte Infrastruktur: Warum dein Terraform-Code eine Sicherheitslücke ist (und wie du das änderst)

Die unangenehme Wahrheit: Deine KI-generierte Infrastructure-as-Code (IaC) ist wahrscheinlich unsicher. Eine aktuelle Studie von Francis Luis Santos Vargas, Rodrigo Brandão Mansilha und Diego Kreutz (2026) hat 7 führende LLMs und SLMs bei der Erzeugung von sicherheitskonformen Terraform-Code benchmarkt. Das Ergebnis: Nur 3 von 7 Modellen liefern Code, der grundlegende Security-Standards erfüllt – die anderen produzieren "Cloud Time Bombs".

💥 Fakt: Cloud Fehlkonfigurationen sind die Hauptursache für Sicherheitsvorfälle (Quelle: IBM Cost of a Data Breach Report 2025). Doch statt die Problematik zu lösen, verstärkt KI sie oft – wenn sie falsch eingesetzt wird.

Die Studie: 7 Modelle im Sicherheits-Benchmark

Die Forscher haben 7 Modelle (LLMs & SLMs) mit 3 Sicherheitskriterien evaluiert:

Bewertungskriterien

1. 🔒 Compliance mit Security Best Practices

   • Keine offene S3-Buckets (kein acl = "public-read" ohne Notwendigkeit)
   • Keine hartcodierten Secrets (kein password = "admin123")
   • Principle of Least Privilege (IAM-Rollen mit minimalen Rechten)
   • Verschlüsselung aktiviert (S3, EBS, RDS)

2. 🛡️ Resilienz gegen Angriffe

   • Keine unsicheren Standards (kein http statt https)
   • Keine veralteten Ressourcen (kein ami-12345678 ohne Updates)
   • Keine exponierten Ports (kein ingress { from_port = 0 to_port = 65535 })

3. 📊 Korrektheit & Wartbarkeit

   • Gültige Terraform-Syntax
   • Referenzierbare Ressourcen (keine aws_instance.undefined)
   • Moderne Module (kein template_file, sondern templatefile)

🔍 Quelle: arXiv:2608.02672v1 – Security-First Evaluation of Text-to-Terraform: Benchmarking LLMs and SLMs for Secure IaC Generation

Die Ergebnisse: Wer liefert sicheren Code?

✅ Top 3: Sicher & Empfehlenswert

🥇 1. Platz: GPT-4o (88% Sicherheit)

• Stärken: Sehr gute Einhaltung von Security Best Practices, erklärt Entscheidungen
• Schwächen: Teuer, langsam
• Beispiel-Prompt:

  Erzeuge Terraform-Code für eine sichere AWS S3-Bucket mit:
  - Keinem öffentlichen Zugriff
  - Verschlüsselung (AES256)
  - Versionierung
  - Minimalen IAM-Berechtigungen
  

• Resultat:

  resource "aws_s3_bucket" "secure_bucket" {
    bucket = "my-secure-bucket"
    
    # Kein öffentlicher Zugriff
    block_public_acls       = true
    block_public_policy     = true
    ignore_public_acls      = true
    restrict_public_buckets = true
  }
  
  resource "aws_s3_bucket_versioning" "secure_bucket_versioning" {
    bucket = aws_s3_bucket.secure_bucket.id
    versioning_configuration {
      status = "Enabled"
    }
  }
  
  resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket_encryption" {
    bucket = aws_s3_bucket.secure_bucket.id
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
  

🥈 2. Platz: Claude 3.5 Sonnet (85% Sicherheit)

• Stärken: Gute Balance zwischen Sicherheit und Kosten
• Schwächen: Manchmal zu konservativ (übermäßig restriktiv)
• Besonderheit: Erklärt Security-Entscheidungen in Kommentaren

🥉 3. Platz: Codellama 70B (75% Sicherheit)

• Stärken: Günstig, schnell, gute Grundlagen
• Schwächen: Weniger kontextbewusst für komplexe Sicherheitsanforderungen
• Empfehlung: Gut für einfache IaC-Aufgaben

❌ Bottom 4: Vorsicht geboten!

4. Platz: Llama 3.1 70B (72%)

• Problem: Hartcodierte Secrets in ~15% der Fälle
• Beispiel:

  # ❌ UNSICHER: Hartcodiertes Passwort
  resource "aws_db_instance" "example" {
    password = "admin123"
    # ...
  }
  

5. Platz: Mistral Large 2 (70%)

• Problem: Offene S3-Buckets in ~20% der Fälle
• Beispiel:

  # ❌ UNSICHER: Öffentlicher Zugriff
  resource "aws_s3_bucket" "public_bucket" {
    acl = "public-read"
    # ...
  }
  

6. Platz: Gemini 1.5 Pro (65%)

• Problem: Veraltete Ressourcen (z. B. alte AMIs)
• Beispiel:

  # ❌ UNSICHER: Veraltetes AMI
  resource "aws_instance" "example" {
    ami = "ami-12345678" # Nicht mehr gewartet
    # ...
  }
  

7. Platz: DeepSeek Coder 32B (60%)

• Problem: Exponierte Ports in ~30% der Fälle
• Beispiel:

  # ❌ UNSICHER: Alle Ports offen
  resource "aws_security_group" "open_all" {
    ingress {
      from_port   = 0
      to_port     = 65535
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
  

💥 Die größten Sicherheitsfallen in KI-generiertem Terraform

1️⃣ Offene S3-Buckets (Die häufigste Falltür)

Problem: KI neigt dazu, Standard-Einstellungen zu verwenden – und die sind oft unsicher.\nLösung: Immer explizit block_public_acls = true setzen

# ✅ SICHER: Kein öffentlicher Zugriff
resource "aws_s3_bucket" "secure" {
  bucket = "my-bucket"
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

2️⃣ Hartcodierte Secrets (Der klassische Fehler)

Problem: KI hat kein Gedächtnis für Secrets – sie generiert sie einfach inline.\nLösung: Immer aws_secretsmanager_secret oder var.password nutzen

# ❌ UNSICHER: Hartcodiert
password = "my-secret-password"

# ✅ SICHER: Aus Variable oder Secrets Manager
password = var.db_password

# Oder besser:
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/db/password"
}
password = data.aws_secretsmanager_secret_version.db_password.secret_string

3️⃣ Übermäßige IAM-Berechtigungen (Das Principle of Least Privilege wird ignoriert)

Problem: KI generiert oft "*"-Policies, die zu viele Rechte vergeben.\nLösung: Immer spezifische Resources und Actions angeben

# ❌ UNSICHER: Zu viele Rechte
resource "aws_iam_policy" "too_permissive" {
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "*"
      Resource = "*"
    }]
  })
}

# ✅ SICHER: Minimale Rechte
resource "aws_iam_policy" "least_privilege" {
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject"]
      Resource = ["arn:aws:s3:::my-bucket/*"]
    }]
  })
}

4️⃣ Keine Verschlüsselung (Der stille Killer)

Problem: KI vergisst oft, Verschlüsselung zu aktivieren.\nLösung: Immer server_side_encryption für S3, EBS, RDS setzen

# ✅ SICHER: Verschlüsselung für S3
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# ✅ SICHER: Verschlüsselung für EBS
resource "aws_ebs_volume" "example" {
  encrypted = true
  # ...
}

# ✅ SICHER: Verschlüsselung für RDS
resource "aws_db_instance" "example" {
  storage_encrypted = true
  kms_key_id        = aws_kms_key.example.arn
  # ...
}

5️⃣ Unsichere Standards (HTTP statt HTTPS, etc.)

Problem: KI verwendet manchmal veraltete oder unsichere Standards.\nLösung: Immer moderne, sichere Standards erzwingen

# ❌ UNSICHER: HTTP
listener {
  protocol = "HTTP"
  # ...
}

# ✅ SICHER: HTTPS mit Redirect
listener {
  protocol = "HTTPS"
  # ...
}

# ✅ SICHER: HTTP → HTTPS Redirect
listener {
  protocol = "HTTP"
  redirect {
    port        = "443"
    protocol    = "HTTPS"
    status_code = "HTTP_301"
  }
}

🔧 Wie du KI SICHER für IaC einsetzt

✅ Schritt 1: Der richtige Prompt

Schlecht:

"Erzeuge Terraform-Code für eine AWS EC2-Instanz."

Gut:

"Erzeuge sicheren Terraform-Code für eine AWS EC2-Instanz mit:

• Minimalen IAM-Berechtigungen (nur ec2:DescribeInstances)
• Verschlüsseltem EBS-Volume (AES256)
• Keinem öffentlichen Zugriff (Security Group nur für interne IPs)
• Keinen hartcodierten Secrets (Nutze var.password)
• Kommentaren, die jede Security-Entscheidung erklären"

✅ Schritt 2: Immer Review & Testen

Nutze Tools zur Überprüfung:

Beispiel CI/CD-Pipeline:

# .github/workflows/terraform-security.yml
name: Terraform Security Scan

on:
  push:
    paths: ["terraform/**"]
  pull_request:
    paths: ["terraform/**"]

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform
          framework: terraform
          output_file_path: console
          quiet: true

  tfsec:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Tfsec
        uses: aquasecurity/tfsec-action@master
        with:
          working_directory: terraform

  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Snyk IaC
        uses: snyk/actions/iac@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

✅ Schritt 3: Security-Guardrails einbauen

Nutze Terraform-Module mit Security-Standards:

• terraform-aws-secure-baseline (Gruntwork)
• [cis-aws-terraform](https://github.com/itr- team/cis-aws-terraform) (CIS Benchmarks)
• cloudposse-terraform-aws-alb-ingress (Sichere ALB-Konfiguration)

Beispiel:

# Nutze ein sicheres Modul statt alles manuell zu schreiben
module "secure_vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  
  # Security Best Practices
  enable_nat_gateway     = true
  single_nat_gateway     = false
  one_nat_gateway_per_az = true
  enable_dns_hostnames   = true
  enable_dns_support     = true
  
  # Keine öffentlichen Subnets für Datenbanken
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.101.0/24", "10.0.102.0/24"]
  database_subnets = ["10.0.201.0/24", "10.0.202.0/24"]
}

✅ Schritt 4: KI mit Security-Kontext füttern

**Gib der KI Beispiele für sicheren Code und lasse sie davon lernen.

Beispiel:

Hier ist ein BEISPIEL für sicheren Terraform-Code für eine AWS S3-Bucket:

```hcl
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Jetzt generiere einen ÄHNLICHEN Code für eine AWS RDS-Instanz mit:
- Verschlüsselung (AES256)
- Keinem öffentlichen Zugriff
- Minimalen IAM-Berechtigungen

✅ Schritt 5: Human-in-the-Loop

KI ist ein Werkzeug – kein Ersatz für menschliche Expertise.

• Immer manuell prüfen, was die KI generiert hat
• Security-Tests in CI/CD integrieren (Checkov, Tfsec, Snyk)
• Regular Audits durchführen (z. B. mit AWS Config)

📊 Benchmark: Modell-Vergleich für verschiedene IaC-Aufgaben

💡 Empfehlung:

• Einfache Aufgaben: Codellama 70B (günstig & schnell)
• Sicherheitskritische Aufgaben: GPT-4o oder Claude 3.5 Sonnet
• Komplexe Architektur: Immer menschliche Review + Security-Tools

🚀 Tools & Ressourcen

🔧 Security-Scanning für Terraform

📚 Sichere Terraform-Module

🎓 Lernressourcen

• Terraform Best Practices – HashiCorp
• AWS Well-Architected Framework – Security Pillar
• OWASP Cloud Security Top 10
• CIS AWS Foundations Benchmark

💬 Fazit: KI ist mächtig – aber nicht perfekt

Die Studie zeigt: KI kann IaC generieren – aber nicht immer sicher. Die Verantwortung liegt bei dir als DevOps Engineer, Cloud Architect oder Security-Experte.

🎯 Sofort umsetzbar:

1. Nutze nur die Top 3 Modelle (GPT-4o, Claude 3.5 Sonnet, Codellama 70B) für sicherheitskritische Aufgaben
2. Gib der KI klare Security-Anforderungen im Prompt
3. Review immer den generierten Code mit Checkov/Tfsec/Snyk
4. Integriere Security-Scans in deine CI/CD
5. Nutze sichere Terraform-Module (Gruntwork, CloudPosse)

🚀 Langfristig:

• Schule dein Team im sicheren Umgang mit KI für IaC
• Baue Security-Guardrails in deine Pipeline ein
• Führe regelmäßig Audits durch (z. B. mit AWS Config)

💡 Letzter Tipp: KI ist wie ein scharfes Messer – sie kann dir helfen, große Dinge zu bauen, aber auch wehtun, wenn du sie falsch einsetzt.

🔗 Original-Studie: Security-First Evaluation of Text-to-Terraform: Benchmarking LLMs and SLMs for Secure IaC Generation (arXiv:2608.02672v1)

📌 Tags: #Terraform #Security #LLM #IaC #DevOps #Cloud #AI