PS Product SecurityKnowledge Base

🧱 TerraGoat — IaC Misconfiguration Lab

Intro: TerraGoat is one of the most valuable labs for teams that want to improve cloud security before deployment. It is less about runtime exploitation and more about learning how insecure Terraform looks in review, scanning, and policy enforcement.

What this page includes

  • what TerraGoat is best used for;
  • how to deploy it and when not to deploy it;
  • how to use it for Checkov, policy-as-code, and review training;
  • how to connect it to your platform guardrails.

What it is

TerraGoat is a deliberately vulnerable Terraform repository created to demonstrate how common misconfigurations reach production cloud environments.

Its real value is not “hacking Terraform.” Its value is helping teams practice:

  • misconfiguration recognition;
  • policy-as-code design;
  • pre-commit scanning;
  • CI-based IaC review;
  • cloud platform guardrails.

Why it is valuable

TerraGoat is one of the cleanest labs for DevSecOps learning because it makes insecure infrastructure visible in code, not only after deployment.

This is the right lab when you want to train:

  • Terraform reviewers;
  • platform security engineers;
  • cloud security newcomers;
  • teams rolling out Checkov or similar policy enforcement.

Best fit

Persona Fit Why
Platform security engineer Very high Excellent for policy-as-code training
DevSecOps engineer Very high Ideal for pre-commit and CI gate practice
Cloud Security engineer High Great for review and guardrail design
AppSec engineer Medium More useful if you review IaC regularly

Run model

TerraGoat can be used in two different ways:

Mode 1 — code-only review lab

The safest and often most useful mode. You:

  • clone the repo;
  • run static scanners;
  • write review notes;
  • never deploy the infrastructure.

Mode 2 — deployed cloud lab

Useful when you want to see how misconfigurations materialize in the real provider, but only in a disposable environment.

git clone https://github.com/bridgecrewio/terragoat
cd terragoat
checkov -d terraform/

If your goal is guardrails, policy-as-code, or reviewer enablement, this is the highest-value starting point.

AWS deployment example

export TERRAGOAT_STATE_BUCKET="mydevsecops-bucket"
export TF_VAR_company_name=acme
export TF_VAR_environment=mydevsecops
export TF_VAR_region="us-west-2"

aws s3api create-bucket --bucket $TERRAGOAT_STATE_BUCKET   --region $TF_VAR_region   --create-bucket-configuration LocationConstraint=$TF_VAR_region

cd terraform/aws/
terraform init   -backend-config="bucket=$TERRAGOAT_STATE_BUCKET"   -backend-config="key=$TF_VAR_company_name-$TF_VAR_environment.tfstate"   -backend-config="region=$TF_VAR_region"
terraform apply

Only use the deployed mode in a throwaway training account.

What to practice with TerraGoat

Review discipline

  • identify the insecure resource definition;
  • explain the business impact;
  • name the missing preventative control;
  • recommend where to enforce the guardrail.

Policy-as-code

Use the repo to compare:

  • inline linters;
  • pre-commit hooks;
  • Checkov or similar static scanners;
  • policy engines or organization-level controls.

Release and approval design

Use the repo to decide:

  • what should block in pre-commit;
  • what should block in merge/CI;
  • what should block only in production deployment;
  • which exceptions need formal review.

Suggested study sequence

  1. scan the repo with Checkov or your preferred IaC scanner;
  2. group findings into identity, storage, network, logging, and data exposure themes;
  3. write one-page remediation guidance for each theme;
  4. convert the most important findings into policy-as-code or review-checklist rules.

Best pairings in this KB

Common mistakes

  • deploying it when a code-only review would already meet the learning goal;
  • focusing on tool output without writing human-readable review notes;
  • failing to decide where a control belongs: developer workstation, CI, or cloud org policy;
  • forgetting that intentionally vulnerable resources should not coexist with real workloads.

Cleanup

If you deployed it, destroy from the same provider directory:

terraform destroy

Then remove the training state backend if you created it only for the lab.

References

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.