Containers & Infrastructure

Where your code runs decides how bad a bug can get. Four labs on shrinking the blast radius of containers and catching insecure infrastructure before it's applied.

An application bug in a well-configured container is an incident in one process. The same bug in a root container with the Docker socket mounted, on a bloated base image, inside a network with a public database, is a breach. These labs harden each layer, and put a scanner in front of each one so regressions are caught in pull requests.

1. LAB 2.1HIGHCWE-250 · Execution with unnecessary privileges · CIS Docker 4.1

   Everything runs as root

   Every ShopLite container runs as root, with a writable filesystem and the default Linux capabilities. Any code-execution bug gets root inside the container, and a much shorter path out of it.

2. LAB 2.2CRITICALCWE-269 · Improper privilege management · CIS Docker 5.31

   The log shipper that owned the host

   The observability lab mounts /var/run/docker.sock into Alloy so it can read container logs. That socket is full control of the Docker host.

3. LAB 2.3MEDIUMCWE-1104 · Use of unmaintained third-party components

   900 MB of someone else's vulnerabilities

   ShopLite's first Dockerfile used node:latest: a full Debian with compilers, curl, git, and hundreds of CVEs — none of which the app ever uses.

4. LAB 2.4CRITICALCWE-284 · Improper access control · OWASP A05 Security misconfiguration

   The pull request that opened the database

   A Terraform change to 'debug a connection issue' opens the RDS security group to 0.0.0.0/0 and makes the bucket policy public. The plan looked small, and it was approved.