Secrets

The most common way real systems get breached: a credential that ended up somewhere it shouldn't — git history, an image layer, a CI log — and was found by someone else first.

Every lab in this chapter uses FAKE credentials that look real enough for scanners to flag, in a throwaway repo called sec-lab. You'll leak them the way real teams do, find them the way attackers do, and fix the process, not just the one file, so it can't happen again.

1. LAB 0.1CRITICALCWE-798 · Use of hard-coded credentials

   The key that was 'already deleted'

   A developer committed an AWS key, noticed, and deleted it in the next commit. The key is still one git log -p away for anyone who clones the repo.

2. LAB 0.2CRITICALCWE-538 · Insertion of sensitive information into externally-accessible file

   Deleted in the Dockerfile, alive in the image

   The Dockerfile copies .env to build the app, then runs rm .env. Anyone who can pull the image can read every value in it.

3. LAB 0.3HIGHCWE-532 · Insertion of sensitive information into log file · CICD-SEC-6

   Masked in the log, stolen anyway

   CI 'masks' secrets in logs. A one-line change in a third-party action, or a base64 pipe, prints them in the clear to anyone who can read build logs.

4. LAB 0.4HIGHMITRE ATT&CK T1078.004 · Valid accounts: cloud accounts

   Used four minutes after the leak

   A key leaked despite everything. The question now is how fast you find out someone is using it — and what they did.