Fix Module 15 Bandit stretch's false claim that it flags the hardcoded API key #19

New Issue

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

claude commented

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

Problem

The Gate-3 stretch claims bandit will flag "the very hardcoded secret from Part C." Bandit's hardcoded-password checks (B105-107) only fire on password-word-list identifiers (password, secret, token, …). The lab variable is SYNC_API_KEY, which matches none, so bandit -r . reports "No issues identified." Compounding it, the stretch runs after Part C where the secret was already removed.

Evidence

modules/15-security-scanning/README.md Part C stretch (~lines 289-292): "pip install bandit, then bandit -r . … including, often, the very hardcoded secret from Part C."
modules/15-security-scanning/lab/config.py uses SYNC_API_KEY. Tested: bandit -r config.py → "No issues identified."

Why it matters

A verifiable false claim about tool behavior in the very module about scanner limits, and it conflates SAST with secret-scanning — breaking the honesty-about-limits promise and the module's own SCA/secret/SAST taxonomy.

Proposed change

Pick one:

Best: plant a genuinely SAST-shaped flaw in the starter (e.g. subprocess(..., shell=True) or string-concatenated SQL) so bandit actually fires and the stretch demonstrates SAST; OR
Reword to the truth: "bandit's hardcoded-secret check keys on password-named variables, so it will NOT catch SYNC_API_KEY — that's detect-secrets' job"; OR
Drop the claim.

Acceptance criteria

The stretch no longer claims bandit catches SYNC_API_KEY unless bandit actually does.
If kept as a demo, running the shown command produces the described result.

Affected files

modules/15-security-scanning/README.md (and modules/15-security-scanning/lab/config.py if option 1)

References

Source finding F30 (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 The Gate-3 stretch claims `bandit` will flag "the very hardcoded secret from Part C." Bandit's hardcoded-password checks (B105-107) only fire on password-word-list identifiers (`password`, `secret`, `token`, …). The lab variable is `SYNC_API_KEY`, which matches none, so `bandit -r .` reports "No issues identified." Compounding it, the stretch runs after Part C where the secret was already removed. ## Evidence `modules/15-security-scanning/README.md` Part C stretch (~lines 289-292): "`pip install bandit`, then `bandit -r .` … including, often, the very hardcoded secret from Part C." `modules/15-security-scanning/lab/config.py` uses `SYNC_API_KEY`. Tested: `bandit -r config.py` → "No issues identified." ## Why it matters A verifiable false claim about tool behavior in the very module about scanner limits, and it conflates SAST with secret-scanning — breaking the honesty-about-limits promise and the module's own SCA/secret/SAST taxonomy. ## Proposed change Pick one: 1. Best: plant a genuinely SAST-shaped flaw in the starter (e.g. `subprocess(..., shell=True)` or string-concatenated SQL) so bandit actually fires and the stretch demonstrates SAST; OR 2. Reword to the truth: "bandit's hardcoded-secret check keys on password-named variables, so it will NOT catch `SYNC_API_KEY` — that's detect-secrets' job"; OR 3. Drop the claim. ## Acceptance criteria - [ ] The stretch no longer claims bandit catches `SYNC_API_KEY` unless bandit actually does. - [ ] If kept as a demo, running the shown command produces the described result. ## Affected files - `modules/15-security-scanning/README.md` (and `modules/15-security-scanning/lab/config.py` if option 1) ## References Source finding F30 (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.*