🛠️ Lab 9 — Catch the Leak: Secret Scanning and Role-Based Data Minimization (50 pts)

Goal: Experience the full lifecycle of a secrets incident — from prevention (pre-commit hooks) to detection (history scanning) — and then build a small role-based anonymization pipeline that demonstrates least-privilege data access. Everything in this lab uses free, local, open-source tools — no cloud accounts or paid services required. Steps:

1. Set up a sandbox repo. Create a new local folder and run git init. Create 2–3 fake "config" files (e.g., config.py, .env.example, notes.txt) containing realistic-looking but fake secrets — a fake OpenAI-style key (sk-fake...), a fake database password, and a fake AWS access key. Commit these files so your repo has some seeded history.
2. Install and baseline with detect-secrets. Install Yelp's free, Apache-2.0-licensed detect-secrets tool (pip install detect-secrets). Run detect-secrets scan > .secrets.baseline against your repo. Open the generated baseline file and identify which of your fake secrets it flagged, noting the detector type used for each (e.g., high-entropy string, keyword match).
3. Install the pre-commit hook and try to sneak one past it. Install pre-commit (pip install pre-commit), add a .pre-commit-config.yaml that wires up detect-secrets-hook, and run pre-commit install. Now add a brand-new fake secret to a file and attempt git commit. Screenshot or copy the terminal output showing the hook blocking your commit.
4. Run Gitleaks over the full history. Install the free Gitleaks scanner (via brew install gitleaks, a released binary, or Docker) and run gitleaks detect --source . --report-path gitleaks-report.json against the same seeded repo (including the commits from Step 1, before the hook existed). Compare its findings to your detect-secrets baseline: Did Gitleaks catch anything detect-secrets missed, or vice versa? Note one concrete difference in how the two tools approach detection (e.g., regex/rule-based scanning of full history vs. baseline-and-diff plugin detectors).
5. Practice the correct incident response. For one of your seeded fake secrets, write 3–5 sentences describing exactly what you would do in the first 15 minutes after discovering it was pushed to a real, shared repository. Your answer must include immediate rotation/revocation of the credential at its source (not just deleting the file).
6. Build the role-based Presidio pipeline (capstone). Install Microsoft's free, open-source Presidio (pip install presidio-analyzer presidio-anonymizer). Using 3–5 sample text records containing fake PII (names, emails, phone numbers, SSNs), write a short Python script that applies two different anonymization policies to the same source records: an "admin" policy that only redacts the highest-sensitivity fields (e.g., SSN) and leaves the rest visible, and an "analyst" policy that redacts or masks all detected PII entities. Print both outputs side by side for at least one record so the least-privilege effect is visible.
7. Write up your findings. In 200–300 words, explain: (a) what detect-secrets and Gitleaks each caught and missed, (b) why deleting a committed secret doesn't remove the exposure, and (c) how your admin/analyst Presidio policies demonstrate document-level or field-level access control for AI data pipelines.

Deliverables: Submit your write-up (Step 7) as online text entry, plus a file upload containing: your .secrets.baseline, your gitleaks-report.json, a screenshot/log of the blocked commit (Step 3), and your Presidio pipeline script with its console output for both roles.