Review Infrastructure-as-Code for Cloud Misconfigurations with AI

Those misconfigurations live in Terraform, CloudFormation, and Kubernetes manifests, where a policy-as-code scanner catches the known-bad patterns and an LLM does the part scanners are weak at: explaining why a flagged config is dangerous in your specific architecture, reasoning about combinations no single rule sees, and drafting the least-privilege fix. The scanner is ground truth; the model is the analyst that turns findings into decisions. This playbook pairs them.

When to reach for this

• •
  Reviewing new or changed IaC (Terraform/CloudFormation/K8s) before it provisions real infrastructure.
• •
  A scanner returned a wall of findings and you need them explained, prioritized by real exposure, and fixed.
• •
  You want to reason about cross-resource risk — a security group plus an IAM role plus a public subnet that together create a path no single finding captures.

The workflow

1. 1.

   Scan first with a policy-as-code tool. This is your grounding layer and it runs offline:

   Copy

   checkov -d infra/ --output json > /tmp/checkov.json
   # or: tfsec infra/ --format json ; trivy config infra/
   

2. 2.

   Hand the model the findings plus the IaC and ask for prioritized, explained risk:

   Copy

   You are reviewing Infrastructure-as-Code I own. Here are policy-scanner
   findings and the relevant Terraform. For each finding:
   - explain the concrete exposure in THIS architecture (who could reach
     what, and how) — not the generic rule description
   - rate real-world severity given surrounding context (is the resource
     internet-facing? does it hold sensitive data?)
   - give the minimal fix as a diff
   
   Then, separately: identify any risks that arise from COMBINATIONS of
   resources that no single finding flags.
   
   FINDINGS: <paste checkov json summary>
   TERRAFORM:
   <paste the relevant .tf>
   

   Expected output: per-finding exposure explanations grounded in your setup (e.g., "this SG opens 22 to the internet AND the instance has an IAM role with s3:* — an SSH compromise becomes bucket access"), context-adjusted severities, minimal fixes, and a combination-risk section.

3. 3.

   Focus on least privilege for IAM. IAM is where scanners are noisiest and where the real damage lives. Ask specifically: "for each policy, what's the minimal permission set the resource actually needs, based on how it's used in this config?" and treat the answer as a proposal to verify against actual usage.

4. 4.

   Apply minimal fixes and re-scan. Confirm the finding clears and no new one appears.

5. 5.

   Record accepted risks explicitly. Where a finding is a genuine, deliberate exception (a load balancer that must be public), document it with a reason — that record is your audit evidence and your defense when someone asks later.

Verify before you trust it

• Confirm a flagged misconfiguration is actually exposed before escalating. A "public" resource behind a private subnet and no route may not be reachable. Trace the actual network/permission path; downgrade what isn't reachable and escalate what is.
• Confirm a "safe" config is safe in context. Absence of a scanner finding doesn't mean secure — scanners miss logic-level and combination risks. This is why the combination-risk prompt exists; verify the paths it names by reading the resources together.
• Validate least-privilege proposals against real usage. A model's minimal IAM policy is a guess about what the resource needs. Cross-check with actual access logs / CloudTrail before you tighten, or you'll break the workload and get least-privilege blamed.
• Re-scan and plan after every fix. Run the scanner and a terraform plan — confirm the fix does what you intended and doesn't destroy-and-recreate something stateful.

Pitfalls

• Auto-accepting the model's severity or dismissal. Reachability is context-dependent; the model doesn't see your full network topology unless you show it. Verify exposure before acting on a rating.
• Over-tightening IAM blind. A least-privilege policy derived from code alone, without checking real usage, breaks production. Ground it in access data.
• Ignoring combination risk. The single most valuable output here is the cross-resource path scanners miss — don't skip that prompt because the per-finding list looked complete.
• Fixing the manifest, missing the running state. IaC review catches drift-free config; if production was changed out-of-band, the manifest looks clean while the real resource is exposed. Reconcile with the deployed state.
• Undocumented accepted risks. An exception nobody recorded looks like negligence in the next audit. Write down why.

Tools

• Checkovbroad policy-as-code coverage across Terraform/CloudFormation/K8s with JSON output ideal for the scan → explain loop.
• tfsec / Trivyfast Terraform and multi-format config scanning; Trivy also covers container and dependency layers for a fuller picture.
• An LLM (Claude-class)the analyst that explains exposure in context, reasons about resource combinations, and drafts least-privilege fixes.

Client-safe variant

IaC reveals a client's cloud architecture, account IDs, and sometimes secrets in variables. Before prompting, strip real account IDs, ARNs, hostnames, and any secret from the snippet, and keep only the resource shapes the review needs. The scanners (Checkov, tfsec, Trivy) run entirely offline, so grounding never requires an external call — only the explanatory prose does. Where the client bars public tools, use a local model for that prose. Keep accepted-risk records in the client's own repo, and get per-client approval before any config leaves their boundary.