security-scan.sh pipes detect-secrets JSON into python -c to decide pass/fail. On systems with only python3 (fresh Ubuntu, modern macOS), python is not found, python -c exits 127, the if takes the else branch, prints "no secrets detected.", and leaves status 0 — so a real hardcoded secret slips the gate silently. The comment even calls this line "portable." A security gate that fails OPEN is worse than no gate.
# python -c keeps this portable
if printf %s "$report" | python -c "...sys.exit(0 if ...results else 1)"; then
...
else
echo "...no secrets detected."
Script uses set -u only (no set -e/pipefail). Reproduced: python3-only PATH with a real secret → "SECURITY GATE: passed", exit 0.
Why it matters
This is the central worked example of the security module, and the bug defeats the gate on common modern platforms — directly against the module's purpose and the honesty promise.
Proposed change
Use python3 instead of bare python (idiomatic for this Unix bash script; detect-secrets is itself Python-installed).
Make the gate fail CLOSED on interpreter/parse error: capture the boolean explicitly and treat empty/parse-error/missing-interpreter as FAILURE.
Add an early guard: command -v python3 >/dev/null 2>&1 || { echo "python3 required"; exit 2; } so a missing interpreter aborts rather than passing.
Acceptance criteria
On a python3-only host with a planted secret, the gate FAILS (non-zero exit), not passes.
Missing interpreter aborts with a clear message and non-zero exit.
Parse errors fail closed.
Affected files
modules/15-security-scanning/lab/security-scan.sh
References
Source finding F28 (realVotes 3/3). Related: bare-python portability is also flagged in F11.
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` pipes detect-secrets JSON into `python -c` to decide pass/fail. On systems with only `python3` (fresh Ubuntu, modern macOS), `python` is not found, `python -c` exits 127, the `if` takes the else branch, prints "no secrets detected.", and leaves status 0 — so a real hardcoded secret slips the gate silently. The comment even calls this line "portable." A security gate that fails OPEN is worse than no gate.
## Evidence
`modules/15-security-scanning/lab/security-scan.sh` (~lines 32-39):
```
# python -c keeps this portable
if printf %s "$report" | python -c "...sys.exit(0 if ...results else 1)"; then
...
else
echo "...no secrets detected."
```
Script uses `set -u` only (no `set -e`/`pipefail`). Reproduced: python3-only PATH with a real secret → "SECURITY GATE: passed", exit 0.
## Why it matters
This is the central worked example of the security module, and the bug defeats the gate on common modern platforms — directly against the module's purpose and the honesty promise.
## Proposed change
1. Use `python3` instead of bare `python` (idiomatic for this Unix bash script; detect-secrets is itself Python-installed).
2. Make the gate fail CLOSED on interpreter/parse error: capture the boolean explicitly and treat empty/parse-error/missing-interpreter as FAILURE.
3. Add an early guard: `command -v python3 >/dev/null 2>&1 || { echo "python3 required"; exit 2; }` so a missing interpreter aborts rather than passing.
## Acceptance criteria
- [ ] On a python3-only host with a planted secret, the gate FAILS (non-zero exit), not passes.
- [ ] Missing interpreter aborts with a clear message and non-zero exit.
- [ ] Parse errors fail closed.
## Affected files
- `modules/15-security-scanning/lab/security-scan.sh`
## References
Source finding F28 (realVotes 3/3). Related: bare-`python` portability is also flagged in F11.
---
*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.shpipes detect-secrets JSON intopython -cto decide pass/fail. On systems with onlypython3(fresh Ubuntu, modern macOS),pythonis not found,python -cexits 127, theiftakes the else branch, prints "no secrets detected.", and leaves status 0 — so a real hardcoded secret slips the gate silently. The comment even calls this line "portable." A security gate that fails OPEN is worse than no gate.Evidence
modules/15-security-scanning/lab/security-scan.sh(~lines 32-39):Script uses
set -uonly (noset -e/pipefail). Reproduced: python3-only PATH with a real secret → "SECURITY GATE: passed", exit 0.Why it matters
This is the central worked example of the security module, and the bug defeats the gate on common modern platforms — directly against the module's purpose and the honesty promise.
Proposed change
python3instead of barepython(idiomatic for this Unix bash script; detect-secrets is itself Python-installed).command -v python3 >/dev/null 2>&1 || { echo "python3 required"; exit 2; }so a missing interpreter aborts rather than passing.Acceptance criteria
Affected files
modules/15-security-scanning/lab/security-scan.shReferences
Source finding F28 (realVotes 3/3). Related: bare-
pythonportability is also flagged in F11.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.