Fix Module 15 security gate failing OPEN on python3-only systems (bare python) #17

New Issue

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

claude commented

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

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

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.*

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.