Onboarding + make M15 gate catch the plant + M17 override (#6,#17,#18,#19,#29) (#58)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>

modules/15-security-scanning/README.md

@@ -287,9 +287,14 @@ that key had been real and ever pushed, removing it now is not enough; you'd hav
 because it's in history. (Proper secret management is Module 17; this is just the catch.)
 
 > **Stretch — Gate 3 (SAST):** install a static analyzer for your language (for Python,
-> `pip install bandit`, then `bandit -r .`) and see it flag insecure patterns — including, often, the
-> very hardcoded secret from Part C, from a different angle. Note how much noisier it is than the
-> first two gates. That noise is why it's the one you tune.
+> `pip install bandit`, then `bandit -r .`) and watch it flag insecure *code you wrote* — here, the
+> MD5-based request signing in `config.py` (weak crypto, CWE-327). Now note what it does **not**
+> flag: the hardcoded `SYNC_API_KEY`. Bandit's hardcoded-credential checks (B105–107) key on
+> *password-named* identifiers — `password`, `secret`, `token` — so a key named `SYNC_API_KEY` slips
+> right past them. Catching that string is a secret scanner's job (Gate 2), not SAST's. Same file,
+> two distinct flaws, caught by two different gates with two different blind spots — which is exactly
+> why you run all three rather than trusting one. And note how much noisier SAST is than the first
+> two gates: that noise is why it's the one you tune.
 
 ### Part D — Wire the gates into CI
 
@@ -298,13 +303,32 @@ runs on every push and blocks the merge.
 
 1. Copy `lab/security-scan.sh` into your project. It runs the SCA and secret-scan gates and **exits
    non-zero on any finding** — which is what makes CI go red. Make it executable
-   (`chmod +x security-scan.sh`) and run it locally first:
+   (`chmod +x security-scan.sh`).
+
+   Before you run it, **stage the starter files** so the secret gate can see them:
+
+   ```bash
+   git add config.py requirements.txt
+   ```
+
+   This is not a footnote. `detect-secrets scan` with no path argument scans the files Git
+   *tracks* — an *untracked* `config.py` is invisible to it, so the gate would report "no secrets"
+   on a file that's full of them (a silent false pass, the worst kind). Staging puts the file in
+   front of the scanner. It's the same reason the explicit `detect-secrets scan config.py` in
+   Part C worked, and the same reason "secrets live in history": the moment Git knows about a file,
+   so does the gate.
+
+   To watch the gate catch both planted problems at once, restore the original booby-trapped files
+   first (you fixed them in Parts B and C) — re-copy `config.py` and `requirements.txt` from this
+   module's starter, re-stage, then run:
 
    ```bash
    ./security-scan.sh
    ```
 
-   With the bad starter files in place it should fail. With your Part B/C fixes applied, it should
+   It should **fail on both gates** — the SCA gate on the unresolvable/vulnerable dependencies and
+   the secret gate on the hardcoded key — and you should be able to point at which finding caused
+   each non-zero exit. Re-apply your Part B/C fixes (and re-stage), run it once more, and it should
    pass.
 
 2. Add a security step to your pipeline that calls it. `lab/ci-security.yml` is a provider-neutral