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

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.

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

The uncomfortable truth: Your AI-generated Infrastructure-as-Code (IaC) is likely insecure. A recent study by Francis Luis Santos Vargas, Rodrigo Brandão Mansilha, and Diego Kreutz (2026) benchmarked 7 leading LLMs and SLMs on generating security-compliant Terraform code. The result: Only 3 out of 7 models produce code that meets basic security standards—the others generate "cloud time bombs."

💥 Fact: Cloud misconfigurations are the leading cause of security incidents (Source: IBM Cost of a Data Breach Report 2025). Yet instead of solving the problem, AI often amplifies it—if used incorrectly.

The Study: 7 Models in a Security Benchmark

The researchers evaluated 7 models (LLMs & SLMs) across 3 security criteria:

Evaluation Criteria

1. 🔒 Compliance with Security Best Practices

   • No open S3 buckets (no acl = "public-read" without justification)
   • No hardcoded secrets (no password = "admin123")
   • Principle of Least Privilege (IAM roles with minimal permissions)
   • Encryption enabled (S3, EBS, RDS)

2. 🛡️ Resilience Against Attacks

   • No insecure defaults (no http instead of https)
   • No outdated resources (no ami-12345678 without updates)
   • No exposed ports (no ingress { from_port = 0 to_port = 65535 })

3. 📊 Correctness & Maintainability

   • Valid Terraform syntax
   • Resolvable resources (no aws_instance.undefined)
   • Modern modules (no template_file, use templatefile)

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

The Results: Who Delivers Secure Code?

✅ Top 3: Secure & Recommended

🥇 1st Place: GPT-4o (88% Security)

• Strengths: Excellent adherence to security best practices, explains decisions
• Weaknesses: Expensive, slow
• Example Prompt:

  Generate Terraform code for a secure AWS S3 bucket with:
  - No public access
  - Encryption (AES256)
  - Versioning
  - Minimal IAM permissions
  

• Result:

  resource "aws_s3_bucket" "secure_bucket" {
    bucket = "my-secure-bucket"
    
    # No public access
    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"
      }
    }
  }
  

🥈 2nd Place: Claude 3.5 Sonnet (85% Security)

• Strengths: Good balance between security and cost
• Weaknesses: Sometimes overly restrictive
• Specialty: Explains security decisions in comments

🥉 3rd Place: Codellama 70B (75% Security)

• Strengths: Affordable, fast, solid foundations
• Weaknesses: Less context-aware for complex security needs
• Recommendation: Good for simple IaC tasks

❌ Bottom 4: Proceed with Caution!

4th Place: Llama 3.1 70B (72%)

• Problem: Hardcoded secrets in ~15% of cases
• Example:

  # ❌ INSECURE: Hardcoded password
  resource "aws_db_instance" "example" {
    password = "admin123"
    # ...
  }
  

5th Place: Mistral Large 2 (70%)

• Problem: Open S3 buckets in ~20% of cases
• Example:

  # ❌ INSECURE: Public access
  resource "aws_s3_bucket" "public_bucket" {
    acl = "public-read"
    # ...
  }
  

6th Place: Gemini 1.5 Pro (65%)

• Problem: Outdated resources (e.g., old AMIs)
• Example:

  # ❌ INSECURE: Outdated AMI
  resource "aws_instance" "example" {
    ami = "ami-12345678" # No longer maintained
    # ...
  }
  

7th Place: DeepSeek Coder 32B (60%)

• Problem: Exposed ports in ~30% of cases
• Example:

  # ❌ INSECURE: All ports open
  resource "aws_security_group" "open_all" {
    ingress {
      from_port   = 0
      to_port     = 65535
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
  

💥 The Biggest Security Pitfalls in AI-Generated Terraform

1️⃣ Open S3 Buckets (The Most Common Trap)

Problem: AI tends to use default settings—which are often insecure.\nSolution: Always explicitly set block_public_acls = true

# ✅ SECURE: No public access
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️⃣ Hardcoded Secrets (The Classic Mistake)

Problem: AI has no memory for secrets—it just generates them inline.\nSolution: Always use aws_secretsmanager_secret or var.password

# ❌ INSECURE: Hardcoded
password = "my-secret-password"

# ✅ SECURE: From variable or Secrets Manager
password = var.db_password

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

3️⃣ Excessive IAM Permissions (Principe of Least Privilege Ignored)

Problem: AI often generates "*" policies, which grant too many permissions.\nSolution: Always specify exact resources and actions

# ❌ INSECURE: Too many permissions
resource "aws_iam_policy" "too_permissive" {
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "*"
      Resource = "*"
    }]
  })
}

# ✅ SECURE: Least privilege
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️⃣ No Encryption (The Silent Killer)

Problem: AI often forgets to enable encryption.\nSolution: Always set server_side_encryption for S3, EBS, RDS

# ✅ SECURE: Encryption for 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"
    }
  }
}

# ✅ SECURE: Encryption for EBS
resource "aws_ebs_volume" "example" {
  encrypted = true
  # ...
}

# ✅ SECURE: Encryption for RDS
resource "aws_db_instance" "example" {
  storage_encrypted = true
  kms_key_id        = aws_kms_key.example.arn
  # ...
}

5️⃣ Insecure Defaults (HTTP Instead of HTTPS, etc.)

Problem: AI sometimes uses outdated or insecure standards.\nSolution: Always enforce modern, secure standards

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

# ✅ SECURE: HTTPS
listener {
  protocol = "HTTPS"
  # ...
}

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

🔧 How to Use AI SAFELY for IaC

✅ Step 1: Craft the Right Prompt

Bad:

"Generate Terraform code for an AWS EC2 instance."

Good:

"Generate secure Terraform code for an AWS EC2 instance with:

• Minimal IAM permissions (only ec2:DescribeInstances)
• Encrypted EBS volume (AES256)
• No public access (Security Group only for internal IPs)
• No hardcoded secrets (use var.password)
• Comments explaining each security decision"

✅ Step 2: Always Review & Test

Use tools for validation:

Example 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

✅ Step 3: Use Security Guardrails

Leverage Terraform modules with built-in security standards:

• terraform-aws-secure-baseline (Gruntwork)
• cis-aws-terraform (CIS Benchmarks)
• cloudposse-terraform-aws-alb-ingress (Secure ALB Configuration)

Example:

# Use a secure module instead of writing everything manually
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
  
  # No public subnets for databases
  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"]
}

✅ Step 4: Feed AI with Security Context

Provide examples of secure code and let AI learn from them.

Example:

Here’s an EXAMPLE of secure Terraform code for an 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"
    }
  }
}

Now generate a SIMILAR code for an AWS RDS instance with:
- Encryption (AES256)
- No public access
- Minimal IAM permissions

✅ Step 5: Human-in-the-Loop

AI is a tool—not a replacement for human expertise.

• Always manually review what AI generates
• Integrate security tests in CI/CD (Checkov, Tfsec, Snyk)
• Conduct regular audits (e.g., with AWS Config)

📊 Benchmark: Model Comparison for IaC Tasks

💡 Recommendations:

• Simple tasks: Codellama 70B (cheap & fast)
• Security-critical tasks: GPT-4o or Claude 3.5 Sonnet
• Complex architecture: Always human review + security tools

🚀 Tools & Resources

🔧 Security Scanning for Terraform

📚 Secure Terraform Modules

🎓 Learning Resources

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

💬 Conclusion: AI Is Powerful—But Not Perfect

The study shows: AI can generate IaC—but not always securely. The responsibility lies with you as a DevOps engineer, cloud architect, or security expert.

🎯 Immediate Actions:

1. Only use the top 3 models (GPT-4o, Claude 3.5 Sonnet, Codellama 70B) for security-critical tasks
2. Give AI clear security requirements in the prompt
3. Always review generated code with Checkov/Tfsec/Snyk
4. Integrate security scans into your CI/CD
5. Use secure Terraform modules (Gruntwork, CloudPosse)

🚀 Long-Term:

• Train your team on secure AI usage for IaC
• Build security guardrails into your pipeline
• Conduct regular audits (e.g., with AWS Config)

💡 Final Tip: AI is like a sharp knife—it can help you build great things, but it can also hurt you if misused.

🔗 Original Study: 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