Fix Module 15 local secret gate missing the UNTRACKED config.py (stage starter files or scan paths) #18

New Issue

2026-06-22T14:23:45-04:00

claude commented

2026-06-22 14:23:45 -04:00

Problem

security-scan.sh runs detect-secrets scan with no path argument; in a git repo that scans only tracked files, so an untracked file returns empty results. Part A says only "Copy this module's starter files" with no git add, so when the learner runs the gate locally (Part D step 1, "it should fail"), the secret gate finds nothing on the untracked config.py and only the SCA gate fails. The "understand which finding each exit reflects" criterion can't be met because the secret finding never surfaces locally. (Part C's explicit detect-secrets scan config.py works, making the inconsistency confusing; CI works because committing tracks the file.)

Evidence

modules/15-security-scanning/lab/security-scan.sh (~line 33): report="$(detect-secrets scan)" (no path).
modules/15-security-scanning/README.md Part A (~lines 230-231): "Copy this module's starter files" (no staging).
Reproduced (detect-secrets 1.5.0): untracked config.py → results {}; after git add → secret detected.

Why it matters

In a SECURITY module, the flagship gate produces a silent false PASS on a file containing a hardcoded key — and contradicts Part C and the module's own "secrets live in history" framing.

Proposed change

Prefer staging the starter files before the local run:

Add an explicit git add lab/config.py requirements.txt (and/or commit the starter files) before the Part D local run, and state that the secret gate requires the files staged (reinforces the "secrets live in history" point).
Do NOT switch to --all-files as the primary fix: it ignores git and would scan venv//.git, producing false positives and an always-red gate.

Acceptance criteria

Part D step 1's local run surfaces BOTH the secret finding and the SCA finding.
The lab tells the learner to stage/commit the starter files before the local gate run.
The "which finding each exit reflects" criterion is satisfiable locally.

Affected files

modules/15-security-scanning/README.md (and optionally a comment in lab/security-scan.sh)

References

Source finding F29 (realVotes 3/3).

Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.

## Problem `security-scan.sh` runs `detect-secrets scan` with no path argument; in a git repo that scans only tracked files, so an untracked file returns empty results. Part A says only "Copy this module's starter files" with no `git add`, so when the learner runs the gate locally (Part D step 1, "it should fail"), the secret gate finds nothing on the untracked `config.py` and only the SCA gate fails. The "understand which finding each exit reflects" criterion can't be met because the secret finding never surfaces locally. (Part C's explicit `detect-secrets scan config.py` works, making the inconsistency confusing; CI works because committing tracks the file.) ## Evidence `modules/15-security-scanning/lab/security-scan.sh` (~line 33): `report="$(detect-secrets scan)"` (no path). `modules/15-security-scanning/README.md` Part A (~lines 230-231): "Copy this module's starter files" (no staging). Reproduced (detect-secrets 1.5.0): untracked `config.py` → results `{}`; after `git add` → secret detected. ## Why it matters In a SECURITY module, the flagship gate produces a silent false PASS on a file containing a hardcoded key — and contradicts Part C and the module's own "secrets live in history" framing. ## Proposed change Prefer staging the starter files before the local run: 1. Add an explicit `git add lab/config.py requirements.txt` (and/or commit the starter files) before the Part D local run, and state that the secret gate requires the files staged (reinforces the "secrets live in history" point). Do NOT switch to `--all-files` as the primary fix: it ignores git and would scan `venv/`/`.git`, producing false positives and an always-red gate. ## Acceptance criteria - [ ] Part D step 1's local run surfaces BOTH the secret finding and the SCA finding. - [ ] The lab tells the learner to stage/commit the starter files before the local gate run. - [ ] The "which finding each exit reflects" criterion is satisfiable locally. ## Affected files - `modules/15-security-scanning/README.md` (and optionally a comment in `lab/security-scan.sh`) ## References Source finding F29 (realVotes 3/3). --- *Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*

claude added the bug P1 ai-ready labels 2026-06-22 14:23:45 -04:00

claude referenced a pull request that will close this issue

2026-06-22 15:48:27 -04:00

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

claude referenced this issue from a commit

2026-06-22 15:48:29 -04:00

fix(modules-1,15,17): onboarding step, make M15 gate actually catch the plant, M17 .env override

claude closed this issue

2026-06-22 15:48:41 -04:00

Sign in to join this conversation.