Difficulty

Intermediate

Read Time

15 min

A Practical Terraform Security Review with Codex and Claude Code

By Codcompass Team·2026-05-17·15 min read

A Terraform repository is not just code. It is a map of your cloud control plane.

It defines who can reach production, which services are exposed to the internet, where logs are stored, how identities are trusted, and which systems have permission to change infrastructure. That is why an infrastructure-as-code review deserves the same discipline as an application security review, and sometimes more.

AI coding tools such as Codex and Claude Code can help you review Terraform faster, but they should not replace security judgment. They are useful assistants for reading large repositories, finding risky patterns, explaining possible attack paths, and drafting better remediation notes. The accountability still stays with the security engineer.

If you are a cybersecurity engineer early in your career and someone has asked you to review a Terraform repo before production, this guide is for you. I’ll walk you through a practical workflow that keeps the review safe, structured, and useful for the infrastructure team.

We will use two AI-assisted workflows:

Codex connected to a GitHub repository for repository-aware review, GitHub workflows, and patch proposals.
Claude Code launched from a locally cloned repository for terminal-first review, validation commands, and scanner-assisted analysis.

This is not about choosing one tool as the winner. It is about using each one where it fits best, with the same security discipline.

The Use Case

You have been asked:

“Can you review this Terraform repo before we deploy it to production?”

The repository might look like this:

terraform/
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
├── modules/
│   ├── networking/
│   ├── iam/
│   ├── compute/
│   ├── storage/
│   └── eks/
├── providers.tf
├── versions.tf
├── variables.tf
└── outputs.tf

Enter fullscreen mode Exit fullscreen mode

A vague prompt such as “find security issues” is not enough. A good Terraform review needs to answer precise questions:

Which cloud assets are managed by this repo?
Which resources are reachable from the internet?
Where is IAM over-permissioned?
Is sensitive data stored, transmitted, and logged safely?
Are logs enabled for investigation and incident response?
Are secrets, state files, or sensitive outputs exposed?
Which proposed fixes could break production?
Which findings require human verification before a pull request is opened?

Here is the mindset I want you to use:

You are not just looking for bad Terraform. You are looking for future production risk.

For example, if you find an aws_security_group_rule that allows 0.0.0.0/0 to TCP/22, your job is not only to write “public SSH is bad.” Your job is to confirm where that rule is attached, who uses it, whether there is an approved bastion or VPN access path, and whether tightening the rule could block production support.

That is the difference between a basic scan and a professional security review.

First, a Clear Definition of “Local”

In this article, local repository means a normal Git clone on your workstation, laptop, jump box, or review virtual machine.

For example:

git clone git@github.com:your-org/terraform-platform.git
cd terraform-platform

Enter fullscreen mode Exit fullscreen mode

It does not mean a local AI model.

Claude Code may still use a cloud-backed AI service depending on your setup and plan. The word “local” only describes where the Terraform files live while you are reviewing them.

The two workflows look like this:

Workflow

Where the repo sits

Best for

Codex

GitHub repo connected to ChatGPT/Codex

Repository-wide review, GitHub workflows, patch proposals

Claude Code

Locally cloned repo on your workstation or review VM

Terminal-first review, Terraform validation, scanner-assisted analysis

Choose based on your company policy, repository sensitivity, access model, and how much control you need during the review.

The One Rule I Want You to Remember

Give AI tools the code they need to review, but keep production authority with humans and approved automation.

That means the tool can help you read Terraform, understand risk, suggest changes, and write review notes. Production credentials, deployment rights, and approval authority should stay outside the AI-assisted review unless your organization has explicitly approved a different operating model.

Keep these outside the AI workflow unless your security policy says otherwise:

Production cloud credentials
Terraform state files such as terraform.tfstate
Variable files containing real secrets such as prod.tfvars
Private keys
Kubeconfigs
CI/CD secrets
Vault tokens
Break-glass credentials

A well-scoped AI review can still uncover serious issues from code alone, including public ingress, wildcard IAM, missing encryption, missing logging, exposed outputs, unsafe defaults, weak remote state configuration, and CI/CD over-permissioning.

You do not need to give an AI tool production authority to get useful security value from it.

Step 1: Prepare the Repository Before the Review

Before using Codex or Claude Code, inspect the repository for files that should not be casually shared or analyzed outside the approved review boundary.

From your review environment, run:

find . -type f \( \
  -name "*.tfstate" -o \
  -name "*.tfstate.backup" -o \
  -name "*.tfvars" -o \
  -name ".env" -o \
  -name "*.pem" -o \
  -name "*.key" -o \
  -name "kubeconfig" -o \
  -name "credentials" \
\)

Enter fullscreen mode Exit fullscreen mode

Then check for local Terraform working folders:

find . -type d -name ".terraform"

Enter fullscreen mode Exit fullscreen mode

If you find state files, private keys, credentials, or real production variable values, treat that as a security concern immediately. Raise it with the infrastructure owner before continuing.

A clean Terraform repository usually contains files such as:

main.tf
variables.tf
outputs.tf
providers.tf
versions.tf
modules/
environments/
README.md

Enter fullscreen mode Exit fullscreen mode

A repository should normally not contain:

terraform.tfstate
terraform.tfstate.backup
*.tfvars with real secrets
.terraform/
.env
*.pem
*.key
kubeconfig
credentials

Enter fullscreen mode Exit fullscreen mode

This preparation step protects both the organization and your review process.

Step 2: Create a Dedicated Review Branch

Create a separate branch for AI-assisted review work:

git checkout -b security/iac-review-ai-assisted
git push origin security/iac-review-ai-assisted

Enter fullscreen mode Exit fullscreen mode

A dedicated branch keeps your review activity separate from normal feature work. It also gives your team a clear audit trail for notes, proposed patches, scanner results, and pull request comments.

Good branch

names include:

security/iac-review-ai-assisted
security/SEC-1234-terraform-review
security/prod-iac-review

Enter fullscreen mode Exit fullscreen mode

Use the branch naming pattern your team already follows.

Step 3: Define the Review Scope

Before opening any AI tool, write down the review scope. This prevents the tool from wandering and helps you evaluate whether the output is useful.

A strong scope looks like this:

Review scope:
- Terraform files only
- AWS infrastructure
- Environments: dev, staging, prod
- Modules: IAM, networking, storage, compute, EKS
- Objective: Identify security risks and misconfigurations
- First pass: read-only assessment
- No cloud credentials used
- Findings must include file path, resource name, risk, impact, and recommended fix

Enter fullscreen mode Exit fullscreen mode

That scope is much stronger than:

Find security issues.

Enter fullscreen mode Exit fullscreen mode

A junior engineer often becomes effective faster when the question is precise. Treat the AI assistant the same way. Give it the context, the boundaries, and the output format you expect.

Step 4: Use Codex with a Connected GitHub Repository

Codex is useful when you want a repository-aware review from GitHub and you want the output to be easy to convert into issues, review comments, or pull request notes.

Use this workflow when:

The repo is already in GitHub.
Your organization allows ChatGPT/Codex GitHub integration.
You want repository-level review.
You want structured findings and possible patch proposals.
You want to keep the review tied to a branch or pull request workflow.

Product interfaces change over time. Before using this workflow in a real organization, confirm the current Codex setup steps from official documentation and your internal security policy.

4.1 Connect only the repository you need

In ChatGPT, connect GitHub through the app settings and authorize access only to the specific Terraform repository you are reviewing.

Avoid broad organization-wide access unless your company has explicitly approved it.

The principle is simple:

Give the tool the smallest repository access needed to complete the review.

4.2 Start with a read-only Codex prompt

Use this as your first prompt:

You are reviewing a Terraform repository for defensive cloud security.

Perform a read-only security assessment first. Leave files unchanged.

Review only Terraform and Terraform-related CI/CD files.

Focus on:
- IAM over-permissioning
- Public network exposure
- Security group ingress and egress
- Public storage exposure
- Missing encryption
- Missing logging
- Sensitive Terraform outputs
- Unsafe variable defaults
- Remote state security
- Kubernetes or EKS exposure if present
- CI/CD permissions used for Terraform deployment

For each finding, provide:
- Severity: High, Medium, or Low
- File path and Terraform resource name
- Risk and likely attack path
- Business impact
- Recommended fix
- Possible production impact
- Confidence level

Mark anything you cannot confirm from code as “needs human verification.”

Enter fullscreen mode Exit fullscreen mode

This prompt does three important things:

It starts with assessment instead of modification.
It focuses on Terraform security risks that matter in production.
It forces the output to include evidence and impact.

4.3 Follow up with targeted reviews

After the first pass, ask focused questions by control area.

IAM review

Review all IAM policies, roles, users, groups, and service accounts.

Flag:
- Wildcard actions
- Wildcard resources
- Privilege escalation paths
- Cross-account trust risks
- Over-permissioned CI/CD roles
- Roles that can modify infrastructure or security controls

For each issue, suggest the minimum permission change that reduces risk without breaking the intended workload.

Enter fullscreen mode Exit fullscreen mode

Network review

Review all security groups, NACLs, load balancers, subnets, route tables, and EKS public endpoint settings.

Identify any path from the public internet to:
- Administrative services
- Databases
- Internal APIs
- Kubernetes control-plane access
- Management ports
- Sensitive internal workloads

For each finding, explain the exposed asset, likely attack path, and safer access pattern.

Enter fullscreen mode Exit fullscreen mode

Storage review

Review all object storage, block storage, databases, and backups.

Identify:
- Public access
- Missing encryption
- Missing versioning
- Missing access logging
- Weak bucket policies
- Overly broad KMS key access
- Sensitive outputs
- Backup exposure risks

For each finding, explain the risk and the Terraform-level remediation.

Enter fullscreen mode Exit fullscreen mode

State and backend review

Review Terraform backend and state configuration.

Check for:
- Remote state usage
- Encryption
- Locking
- Least-privilege access
- Separation between dev, staging, and prod
- Exposure of sensitive values
- Backend access from CI/CD

List what is confirmed from code and what needs human verification.

Enter fullscreen mode Exit fullscreen mode

4.4 Ask for patches only after validating the findings

After Codex gives you findings, review them yourself. Compare them against the actual Terraform files, existing architecture, and business context.

When you are ready for patch suggestions, use a narrow prompt:

Create proposed Terraform changes for confirmed High-risk findings only.

Requirements:
- Keep changes minimal.
- Preserve resource names.
- Avoid resource replacement unless no safe alternative exists.
- Explain any change that may affect availability, connectivity, IAM access, or deployment flow.
- Avoid module refactoring.
- Avoid unrelated formatting changes.
- Provide a pull request summary suitable for security review.

Enter fullscreen mode Exit fullscreen mode

This keeps the fix focused. Terraform changes can replace resources, block network paths, or break IAM assumptions. A secure-looking patch still needs engineering review.

Step 5: Use Claude Code with a Locally Cloned Repository

Claude Code is useful when you want a terminal-first workflow. It works well when you want to review Terraform files, run validation commands, inspect scanner output, and iterate from your local development environment or a controlled review VM.

Here, local clone means the GitHub repository has been cloned onto your machine or review VM. It does not mean a local AI model.

Use this workflow when:

You want to run terraform validate, terraform plan, Checkov, tfsec, or Trivy locally.
The repository cannot be connected to ChatGPT/Codex.
You need a controlled review environment.
You want to pair AI analysis with terminal evidence.
You want to inspect changes before anything becomes a pull request.

Product interfaces change over time. Before using Claude Code in a company environment, confirm the current setup steps from official documentation and your internal AI/security policy.

5.1 Start Claude Code from the Terraform repository root

First, clone the repo:

git clone git@github.com:your-org/terraform-platform.git
cd terraform-platform

Enter fullscreen mode Exit fullscreen mode

Confirm you are in the repository root. You should see files or folders such as:

main.tf
providers.tf
versions.tf
modules/
environments/

Enter fullscreen mode Exit fullscreen mode

Then create a review branch:

git checkout -b security/iac-review-ai-assisted

Enter fullscreen mode Exit fullscreen mode

Now start Claude Code from that same folder:

claude

Enter fullscreen mode Exit fullscreen mode

The full flow looks like this:

git clone git@github.com:your-org/terraform-platform.git
cd terraform-platform
git checkout -b security/iac-review-ai-assisted
claude

Enter fullscreen mode Exit fullscreen mode

When you run claude from the repository root, Claude Code starts a terminal session with that project as the working context. That is what people often mean when they say “open Claude Code inside the repo.”

A more precise phrase is:

Start Claude Code from the Terraform repository root.

5.2 Add project instructions with `CLAUDE.md`

For a serious IaC review, create a CLAUDE.md file at the repository root. This gives Claude Code persistent project instructions.

Create the file:

touch CLAUDE.md

Enter fullscreen mode Exit fullscreen mode

Add this content:

# Terraform Security Review Instructions

Review objective:
Identify defensive cloud security risks, prioritize them by impact, and explain production consequences before suggesting changes.

Operating boundaries:
- Start with a read-only assessment.
- Work without cloud credentials.
- Leave deployment actions such as terraform apply outside the AI session.
- Wait for explicit approval before editing files.
- Treat state files, tfvars, private keys, kubeconfigs, and credentials as sensitive.
- Mark unconfirmable conclusions as “needs human verification.”

Focus areas:
- IAM least privilege
- Public network exposure
- Encryption
- Logging and monitoring
- Secrets handling
- Terraform state security
- Kubernetes or EKS exposure
- CI/CD Terraform permissions
- Sensitive outputs
- Environment-specific misconfiguration

Finding format:
- Severity
- File path
- Terraform resource name
- Risk
- Likely attack path
- Business impact
- Recommended fix
- Possible production impact
- Confidence level

Enter fullscreen mode Exit fullscreen mode

Check with your team before committing CLAUDE.md. Some teams commit it because it documents the review method. Others keep it only in a temporary review branch.

5.3 First Claude Code prompt: map the repo before judging it

Inside the Claude Code terminal session, paste this prompt:

Perform a read-only Terraform security review of this repository.

Start by mapping the repository structure:
1. Identify environments.
2. Identify reusable modules.
3. Identify providers and backend configuration.
4. Identify IAM, networking, storage, compute, Kubernetes, and CI/CD components.

Then produce a prioritized security review with:
- High-risk findings
- Medium-risk findings
- Low-risk findings
- Items that need human verification
- Questions for the infrastructure owner

For each finding, include:
- File path
- Terraform resource name
- Risk
- Likely attack path
- Business impact
- Recommended fix
- Possible production impact
- Confidence level

Keep the first pass as an assessment only.

Enter fullscreen mode Exit fullscreen mode

This prompt tells Claude Code to understand the repository before making recommendations. That matters because Terraform risk is often contextual. A rule that looks risky in isolation may be acceptable when there is a compensating control, and a rule that looks minor may become serious when attached to a production workload.

5.4 Run local validation commands

Claude Code can help you plan and interpret validation, but your evidence should come from real tools.

Run:

terraform fmt -check -recursive
terraform validate
checkov -d .
tfsec .
trivy config .

Enter fullscreen mode Exit fullscreen mode

If your environment is safe for planning and backend access is properly controlled, also run:

terraform plan

Enter fullscreen mode Exit fullscreen mode

Be careful with terraform plan if the repo requires production backend access or credentials. In many organizations, plan execution is restricted to CI/CD or a controlled automation role.

After running scanners, paste the results into Claude Code:

Review the Checkov, tfsec, and Trivy config scan results below.

Tasks:
- Group duplicate findings.
- Identify likely false positives.
- Prioritize issues that should block production deployment.
- Map scanner findings back to Terraform files and resources.
- Explain the recommended fix and possible production impact.

Enter fullscreen mode Exit fullscreen mode

This is where Claude Code can be very useful. Scanner output is often noisy. A good assistant can help group, explain, and prioritize findings, while you keep final judgment.

5.5 Ask for minimal patches

Once you confirm a finding is real, ask for a focused patch.

Example:

Prepare a minimal patch for the confirmed High-risk finding related to public ingress.

Requirements:
- Modify only the affected files.
- Preserve resource names.
- Avoid module refactoring.
- Explain whether the change may affect existing connectivity.
- Stop after preparing the patch for review.

Enter fullscreen mode Exit fullscreen mode

Then validate the change:

git diff
terraform fmt -recursive
terraform validate
terraform plan

Enter fullscreen mode Exit fullscreen mode

A clear explanation is useful. A safe Terraform plan is stronger evidence.

Step 6: Choose the Right Tool for the Review

Use this table as a starting point:

Review need

Better starting point

Repo-scoped GitHub review with PR workflow

Codex

Codex Security or GitHub review features

Codex

Terminal-first review with local scanner tools

Claude Code

Validation with terraform validate and terraform plan

Claude Code

Repo cannot be connected to ChatGPT/Codex

Claude Code with local clone

Review must stay inside a controlled review VM

Claude Code with local clone

Prepare clear PR comments after validation

Either

Generate patch suggestions after human review

Either

Mature teams may use both:

Codex for repository-level discovery.
Claude Code for local validation and scanner interpretation.
Human review for final approval.
CI/CD for policy enforcement and deployment control.

The tool is not the control. The process is the control.

Step 7: Validate Before You Trust

AI findings are not final evidence. They are review inputs.

Before accepting a finding or a proposed patch, run the relevant checks:

terraform fmt -check -recursive
terraform validate
terraform plan
checkov -d .
tfsec .
trivy config .
git diff

Enter fullscreen mode Exit fullscreen mode

For each proposed fix, ask:

Does this reduce a real risk?
Does the finding have evidence in the Terraform code?
Could the change force resource replacement?
Could the change block legitimate traffic?
Could the change break IAM access used by applications, CI/CD, or support teams?
Does the infrastructure owner need to approve the change?
Does the team need a state migration?
Is this an exception that needs documentation rather than immediate change?

This is where you build judgment. The AI may flag a public security group rule. You must decide whether that rule is truly unnecessary, temporarily approved, protected by another control, or an urgent production blocker.

Step 8: Write Findings That Engineers Can Act On

A weak finding looks like this:

Security group is insecure.

A strong finding looks like this:

High – Public SSH ingress on aws_security_group.admin_access in modules/networking/security_groups.tf.

Risk: Allows TCP/22 from 0.0.0.0/0. An attacker can attempt direct SSH if the security group is attached to administrative hosts.

Business impact: Increased likelihood of unauthorized administrative access and incident response exposure.

Recommended fix: Restrict SSH ingress to an approved bastion, VPN CIDR, or identity-aware access path.

Production impact: May affect current administrative workflows. Confirm the approved access path with the infrastructure owner before applying.

That is the quality bar.

The finding gives the infrastructure team:

The exact resource.
The risk.
The likely attack path.
The business impact.
The Terraform-level fix.
The operational consideration.

That is how you move from “AI found something” to “the team can safely fix this.”

Step 9: Use One Final Report Prompt

After discovery, validation, and human review, use this prompt in either Codex or Claude Code:

Act as a senior cloud security reviewer.

Prepare the final Terraform IaC security review report for this repository.

Use only evidence from:
- Terraform files and CI/CD files in this repo
- Scanner results I provide
- Terraform validation or plan output I provide

Report structure:
1. Review scope
2. Executive summary
3. High-risk findings
4. Medium-risk findings
5. Low-risk findings
6. Items requiring human verification
7. Recommended remediation order
8. Changes that may affect production
9. Suggested pull request description

For each finding include:
- File path
- Terraform resource name
- Plain-language risk
- Likely attack path
- Business impact
- Terraform-level recommendation
- Production impact statement
- Confidence level

Avoid generic advice. Label unproven claims as “needs human verification.”

Enter fullscreen mode Exit fullscreen mode

This gives you a clean final report without losing the evidence trail.

Step 10: What I Expect from a Junior Security Engineer

If you were on my team using these tools, I would expect five things.

1. Protect sensitive material

State files, secrets, credentials, private keys, kubeconfigs, and production variable files are not casual inputs. Spotting them in a repo is already a security finding.

2. Start with read-only review

Understand the repository before suggesting changes. Map environments, modules, providers, backends, IAM, networking, storage, Kubernetes, and CI/CD.

3. Ask precise questions

Review IAM, networking, storage, state, and CI/CD separately. Precise questions produce better findings.

4. Validate with real tools

Terraform, Checkov, tfsec, Trivy, scanner output, git diff, and code review are your evidence. AI explanations are helpful, but they are not proof by themselves.

5. Communicate like a professional

Every finding should explain risk, attack path, business impact, recommended fix, production impact, and confidence level.

That is how you earn trust with infrastructure teams.

Practical Checklist

Copy this into your review notes before submitting your review.

Repository preparation
[ ] Review branch created
[ ] State files, tfvars, private keys, and kubeconfigs removed or flagged
[ ] Git status is clean before AI-assisted review
[ ] Review scope documented

AI review setup
[ ] Codex has access only to the required GitHub repo
[ ] Claude Code started from the correct Terraform repository root
[ ] CLAUDE.md or project instructions created where appropriate
[ ] First prompt requests read-only assessment
[ ] Findings include file path and resource name

Terraform validation
[ ] terraform fmt checked
[ ] terraform validate completed
[ ] terraform plan reviewed where safe and approved
[ ] Scanner results reviewed
[ ] False positives documented

Security review quality
[ ] IAM reviewed for least privilege
[ ] Network reviewed for internet exposure
[ ] Storage reviewed for encryption and public access
[ ] Logging reviewed for investigation readiness
[ ] Secrets and outputs reviewed
[ ] Remote state security reviewed
[ ] CI/CD Terraform permissions reviewed

Change management
[ ] High-risk fixes reviewed with infrastructure owner
[ ] Production impact documented
[ ] Resource replacement risk checked
[ ] Pull request includes security context
[ ] Human approval completed before merge

Enter fullscreen mode Exit fullscreen mode

Final Thought

Codex and Claude Code can make Terraform security reviews faster, but speed is not the real win. The real win is consistency.

A good cybersecurity engineer uses AI to read more carefully, ask better questions, validate more thoroughly, and write clearer findings. A careless reviewer generates a long report and hopes it is correct.

Be the first kind.

When you review Terraform, you are looking at future production permissions, network paths, logging coverage, blast radius, and incident response conditions. Treat the repo with that gravity. Use AI as a skilled assistant, keep the evidence visible, keep humans accountable, and make every finding useful enough that the infrastructure team can act on it with confidence.

🎉 Mid-Year Sale — Unlock Full Article

Base plan from just $4.99/mo or $49/yr

7-day free trial · Cancel anytime · 30-day money-back

The Use Case

First, a Clear Definition of “Local”

The One Rule I Want You to Remember

Step 1: Prepare the Repository Before the Review

Step 2: Create a Dedicated Review Branch

🎉 Mid-Year Sale — Unlock Full Article

Production Bundle