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.*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
security-scan.shrunsdetect-secrets scanwith 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 nogit add, so when the learner runs the gate locally (Part D step 1, "it should fail"), the secret gate finds nothing on the untrackedconfig.pyand 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 explicitdetect-secrets scan config.pyworks, 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.mdPart A (~lines 230-231): "Copy this module's starter files" (no staging).Reproduced (detect-secrets 1.5.0): untracked
config.py→ results{}; aftergit 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:
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-filesas the primary fix: it ignores git and would scanvenv//.git, producing false positives and an always-red gate.Acceptance criteria
Affected files
modules/15-security-scanning/README.md(and optionally a comment inlab/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.