PS Product SecurityKnowledge Base

🐐 Vulnerable Learning Labs and Goat Environments

Intro: Reading is necessary, but labs are what convert theory into judgment. Deliberately vulnerable environments give Product Security, AppSec, Cloud Security, and DevSecOps engineers a safe place to practice review discipline, exploit-path thinking, runtime investigation, and hardening.

What this page includes

  • which intentionally vulnerable environments are worth your time;
  • when to choose a Docker-only lab vs a full cloud lab;
  • how to sequence labs without drowning in complexity;
  • where each lab maps into the rest of this knowledge base.

Why these environments matter

A strong training stack should let you practice three different muscles:

  1. Application review and exploitation awareness — input validation, authz, sessions, and business logic.
  2. Pipeline and artifact trust — CI/CD runners, build provenance, secrets, and release integrity.
  3. Cloud and Kubernetes attack paths — IAM, metadata abuse, registry trust, workload identity, and runtime drift.

The best labs are not always the most realistic. The best lab for a beginner is the one that teaches one or two ideas cleanly.

Order Lab Best for Typical run model Why start here
1 OWASP Juice Shop AppSec and API beginners Docker, Node.js, or Vagrant Fastest path to hands-on web and API security practice
2 CI/CD Goat DevSecOps and pipeline trust Docker Compose on a VM or workstation Shows how build systems become attack surfaces
3 TerraGoat IaC scanning and policy-as-code Terraform in a lab cloud account Teaches misconfiguration prevention before runtime
4 Kubernetes Goat Kubernetes and runtime learners Existing cluster, Kind, K3s, or managed K8s Excellent for scenario-based Kubernetes practice
5 AWSGoat AWS AppSec plus cloud path learners Terraform in AWS Connects web flaws to AWS misconfiguration and privilege paths
6 CloudGoat Cloud pentest and IAM-heavy learning Python CLI or Docker image controlling AWS scenarios Scenario variety is very high and modular
7 OWASP EKS Goat Advanced cloud-native learners Real AWS EKS lab Strong attack-plus-defense coverage for EKS

Quick selection guide

Choose Juice Shop when you want to learn:

  • OWASP Top 10 style issues;
  • auth, session, XSS, IDOR, and API flaws;
  • how scanners and manual testing behave against a realistic web app.

Choose CI/CD Goat when you want to learn:

  • why runners, build agents, and token scopes matter;
  • how Git, CI, artifact, and deploy trust chains break;
  • how to translate supply-chain theory into an actual learning environment.

Choose TerraGoat when you want to learn:

  • how insecure Terraform looks in code review;
  • how Checkov, policy-as-code, and pre-commit controls fit into practice;
  • how to teach platform teams before misconfigurations ship.

Choose Kubernetes Goat when you want to learn:

  • container escape and cluster abuse patterns;
  • how Kubernetes misconfigurations look from attacker and defender viewpoints;
  • how runtime and cluster-audit tools fit together.

Choose AWSGoat or CloudGoat when you want to learn:

  • IAM privilege escalation paths;
  • SSRF-to-metadata-to-credential theft chains;
  • how web flaws and cloud misconfigurations amplify each other.

Choose OWASP EKS Goat when you want to learn:

  • EKS-specific IAM and image-trust failure chains;
  • attack plus defense in one environment;
  • how registry, IAM, cluster RBAC, and runtime detections connect.

Broad environment alternative — DevSecOps-Studio

If the goal is not a single vulnerable target but a broad local training distribution, use DevSecOps-Studio.

It is not a perfect modern reference stack, but it is still useful when you want:

  • one local virtual environment that demonstrates multiple DevSecOps stages;
  • a workshop or classroom-style setup that can be reproduced on a workstation;
  • a bridge from older DevSecOps tooling to a modern 2026 toolchain.

Use it as a learning sandbox, not as a production architecture template.

Safety rules

  • Never deploy these labs in production or in an account that contains sensitive data.
  • Use a disposable cloud account/subscription/project whenever a lab creates real cloud resources.
  • Tag resources aggressively and plan teardown before deployment.
  • Keep training credentials separate from your day-to-day admin identities.
  • Treat screenshots, findings, and notes as training artifacts and keep them out of customer systems.

Suggested study method

Method 1 — read, run, review, harden

  1. Read the lab overview and official setup instructions.
  2. Deploy the lab.
  3. Spend one session only on enumeration and understanding.
  4. Spend one session on review notes: trust boundaries, identities, data, attack surface.
  5. Spend one session on hardening ideas and detection opportunities.

Method 2 — attacker view and defender view

For every lab, force yourself to answer two questions:

  • What makes this attack path possible?
  • What would stop, detect, or contain it earliest?

This keeps the lab useful for Product Security instead of turning it into pure offensive entertainment.

How to document what you learn

Use the same note structure every time:

  • environment purpose;
  • assets and identities;
  • trust boundaries;
  • obvious attack paths;
  • weak controls;
  • missing logs and detections;
  • prevention ideas;
  • one lesson that changes how you review real systems.

How this ties back to the rest of the knowledge base

These labs become far more valuable when paired with the existing review and response content:

Additional learning labs and guided practice

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