AI Auto-Fixing IaC
Misconfigurations:
From tfsec Finding to Merged PR.

The IaC Misconfiguration Challenge

IaC scanning tools like tfsec, Checkov, and KICS are excellent at identifying misconfigurations. They are not good at fixing them. The typical workflow: scanner flags an issue, a security engineer opens a JIRA ticket, an infrastructure engineer eventually addresses it — weeks later. Misconfigurations age in backlogs while the infrastructure they describe remains vulnerable.

IaC misconfigurations are actually excellent candidates for automated remediation: the "correct" fix is often unambiguous. An unrestricted cidr_blocks = ["0.0.0.0/0"] on an SSH ingress rule should be restricted. Encryption not enabled on an S3 bucket should be enabled. These are deterministic fixes, not judgment calls.

The AI IaC Fix Pipeline

The pipeline for an IaC misconfiguration auto-fix:

1. Finding ingestion — tfsec/Checkov finding with: rule ID, affected resource, file path, line range
2. Resource context extraction — read the full resource block, including all attributes, variable references, and module context
3. Intent analysis — AI determines what the resource is trying to do (a bastion host SSH rule needs SSH access from the corporate IP range, not the world)
4. Fix generation — generate the corrected HCL, using context from the rest of the file (e.g., using a variable reference if one already exists for allowed CIDRs)
5. Plan validation — run terraform plan on the patched code to verify no syntax errors and no unexpected resource changes
6. PR creation — open a PR with the finding, the fix rationale, and the plan output showing no unexpected changes

Terraform Validation

The terraform plan step is critical for IaC auto-fixes. It validates:

• The HCL syntax is valid
• All variable references are resolved
• The change affects only the resources intended by the fix
• No unexpected resource replacements or deletions are triggered

A clean plan output — showing only the resource attribute change the fix intended — is strong evidence the fix is correct. If the plan shows unexpected changes, the auto-fix pipeline stops and routes to human review.

Common Auto-Fix Patterns

Unrestricted ingress rules

cidr_blocks = ["0.0.0.0/0"]  # tfsec: HIGH - unrestricted ingress

cidr_blocks = var.allowed_ssh_cidr_blocks  # AI uses existing var if present

Missing encryption

• S3: add server_side_encryption_configuration block with AES256
• RDS: set storage_encrypted = true
• EBS: set encrypted = true

Missing logging

• S3: add logging block pointing to a log bucket
• CloudTrail: set enable_log_file_validation = true
• ALB: add access_logs block

Limits and Caveats

• Context-dependent fixes — "restrict this CIDR" requires knowing what the correct restricted CIDR is. If no context exists in the file (no variable, no comment), the AI must make a judgment call that requires human verification.
• Module outputs — misconfigurations in module outputs cannot always be fixed in the consuming module; the fix may need to go in the module source.
• Drift from state — the Terraform code may not match the actual deployed state. A plan that looks clean may still cause drift remediation when applied.
• Organisation-specific policies — some fixes require knowledge of your organisation's security policy (what CIDRs are approved, which KMS keys are authorised). The AI needs access to this context.