terraform-audit

Terraform Audit Skill

Perform a comprehensive audit of a Terraform codebase across four dimensions: security & compliance, cost optimization, code quality, and architecture design. The audit produces a structured Markdown report with findings classified by severity. Rules are grounded in the CIS AWS Foundations Benchmark and the AWS Well-Architected Framework, with a primary focus on AWS resources.

Description

Perform a comprehensive audit of a Terraform codebase covering four dimensions: security and compliance, cost optimization, code quality, and architecture design. Based on the CIS AWS Foundations Benchmark and the AWS Well-Architected Framework, output a structured Markdown audit report for AWS resources classified by Critical / Important / Minor severity levels.

---

Execution Guidelines

• Scan the project structure before auditing; determine scale by the number of .tf files (Small / Medium / Large) and choose the corresponding strategy
• Execute the four dimensions in order: Security -> Cost -> Quality -> Architecture, reading the corresponding sub-module checklist for each
• Every finding must include a severity level, affected file and line number, and specific remediation advice (including HCL code)
• Use the report-template.md template for the report, saved to the project root directory
• When cross-dimensional complementary rules exist (e.g., Multi-AZ in both architecture and cost), annotate the cross-reference context

---

Examples

Bad

# S3 bucket with no encryption, no versioning, public access
resource "aws_s3_bucket" "data" {
  bucket = "my-data-bucket"
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

✅ Good

resource "aws_s3_bucket" "data" {
  bucket = "${var.project}-${var.environment}-data"
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.main.arn
    }
  }
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

---

Audit Workflow

Copy this checklist and update it as you progress:

Audit Progress:
- [ ] Step 1: Scan project structure
- [ ] Step 2: Security & compliance audit
- [ ] Step 3: Cost optimization audit
- [ ] Step 4: Code quality audit
- [ ] Step 5: Architecture design audit
- [ ] Step 6: Generate report

---

Step 1: Scan Project Structure

Use Glob to find all **/*.tf files in the target project. Then determine:

• Module structure: Identify root module, nested modules, and shared/reusable modules.
• Backend configuration: Check for remote state backend (S3, GCS, Terraform Cloud, etc.) and state locking.
• Provider usage: List providers and their version constraints.
• Terraform version: Check required_version in terraform {} blocks.
• Project scale:
  • Small: < 10 .tf files — audit all files in a single pass.
  • Medium: 10-30 .tf files — group by module, audit each module.
  • Large: 30+ .tf files — prioritize root module and shared modules first, then environment-specific configs.

Record the scale; it determines the audit strategy in later steps.

---

Step 2: Security & Compliance Audit

Read security-checklist.md and apply each rule to the scanned codebase.

Categories covered: IAM policies & roles, S3 bucket configuration, networking (security groups, NACLs, public access), encryption at rest and in transit, logging & monitoring, secrets management.

Classify every finding as Critical, Important, or Minor per the severity table below.

---

Step 3: Cost Optimization Audit

Read cost-optimization.md and apply each rule to the scanned codebase.

Categories covered: Compute right-sizing, storage tiering & lifecycle, database instance sizing & reserved capacity, networking costs (NAT gateways, data transfer), tagging & cost governance.

Classify every finding as Critical, Important, or Minor.

---

Step 4: Code Quality Audit

Read code-quality.md and apply each rule to the scanned codebase.

Categories covered: Modularity & reuse, naming conventions, variable & output hygiene, state management, provider & module version pinning, DRY principle adherence, file & directory structure.

Classify every finding as Critical, Important, or Minor.

---

Step 5: Architecture Design Audit

Read architecture-review.md and apply each rule to the scanned codebase.

Categories covered: High availability, disaster recovery, network design (VPC layout, subnet strategy, connectivity), environment isolation, scalability & auto-scaling readiness.

Classify every finding as Critical, Important, or Minor.

---

Issue Severity Classification

Level	Definition	Examples
Critical	Immediate security risk or data loss potential	Hardcoded secrets, publicly accessible S3 buckets, wildcard IAM permissions
Important	Best practice violation with significant impact	Missing state locking, no version pins, oversized instances
Minor	Style or optimization suggestion	Naming inconsistencies, missing variable descriptions

---

Step 6: Generate Report

Read report-template.md for the exact output format.

• Save the report to {project_root}/terraform-audit-report.md.
• Within each dimension, sort findings by severity: Critical first, then Important, then Minor.
• The executive summary must include total finding counts per severity level and an overall assessment (PASS / NEEDS ATTENTION / CRITICAL ISSUES).

---

Project Scale Adaptation

Scale	Strategy
Small (< 10 .tf files)	Audit every file directly in one pass.
Medium (10-30 files)	Group files by module. Audit each module as a unit.
Large (30+ files)	Audit root module and shared modules first. Then audit environment-specific configurations. Summarize cross-cutting concerns at the end.