Problem
docs/ci-supply-chain-policy.md's "Existing Scanners" section (lines 70-77) lists the checks the security job must keep: Bandit, pip-audit, and the two ShellCheck steps. It omits Gitleaks entirely.
Gitleaks is real, required CI behavior, not aspirational: the actual security job in .github/workflows/tests.yml (lines 339-426) runs, in order, a checksum-pinned Gitleaks install plus tests/scan-secrets.sh history scan (lines 374-392), then Bandit, pip-audit, and the two ShellCheck steps. SECURITY.md ("The required Security scanners check runs Gitleaks 8.30.1 over committed history...") and .ai-context/WORKFLOWS.md ("In addition to Bandit, pip-audit, and ShellCheck, it runs the checksum-pinned Gitleaks release...") both already document it correctly -- docs/ci-supply-chain-policy.md is the one doc in this area still listing the pre-Gitleaks scanner set.
This is exactly the kind of gap the recent .ai-context/ refresh (#2042, merged) was meant to close -- Gitleaks/secret-scanning enforcement was one of the four items that refresh added -- but that refresh only touched .ai-context/STATUS.md, PROJECT.md, and COMMANDS.md; it didn't reach docs/ci-supply-chain-policy.md, which is the canonical CI-scanner registry page and is itself referenced from docs/contracts.md's "GitHub workflow policy" contract row.
Related: the same file's "Updating CI Pins" procedure (lines 22-45) only covers GitHub Action SHA pinning and gives no guidance for bumping the pinned Gitleaks version/SHA-256 checksum pair used in the workflow -- worth folding into the same fix.
Why this matters
docs/ci-supply-chain-policy.md is the canonical page for "what does the security job actually check" -- missing the newest and most security-relevant scanner from that list defeats its purpose, and it's already inconsistent with SECURITY.md and .ai-context/WORKFLOWS.md, which do list it correctly.
Proposed change
- Add a fifth bullet to "Existing Scanners": Gitleaks over committed history via
tests/scan-secrets.sh, checksum-pinned per release.
- Add a short note in "Updating CI Pins" about updating the pinned Gitleaks version/SHA-256 checksum pair.
Acceptance criteria
Problem
docs/ci-supply-chain-policy.md's "Existing Scanners" section (lines 70-77) lists the checks the security job must keep: Bandit,
pip-audit, and the two ShellCheck steps. It omits Gitleaks entirely.Gitleaks is real, required CI behavior, not aspirational: the actual
securityjob in.github/workflows/tests.yml(lines 339-426) runs, in order, a checksum-pinned Gitleaks install plustests/scan-secrets.shhistory scan (lines 374-392), then Bandit, pip-audit, and the two ShellCheck steps. SECURITY.md ("The requiredSecurity scannerscheck runs Gitleaks 8.30.1 over committed history...") and.ai-context/WORKFLOWS.md("In addition to Bandit, pip-audit, and ShellCheck, it runs the checksum-pinned Gitleaks release...") both already document it correctly -- docs/ci-supply-chain-policy.md is the one doc in this area still listing the pre-Gitleaks scanner set.This is exactly the kind of gap the recent
.ai-context/refresh (#2042, merged) was meant to close -- Gitleaks/secret-scanning enforcement was one of the four items that refresh added -- but that refresh only touched.ai-context/STATUS.md,PROJECT.md, andCOMMANDS.md; it didn't reach docs/ci-supply-chain-policy.md, which is the canonical CI-scanner registry page and is itself referenced from docs/contracts.md's "GitHub workflow policy" contract row.Related: the same file's "Updating CI Pins" procedure (lines 22-45) only covers GitHub Action SHA pinning and gives no guidance for bumping the pinned Gitleaks version/SHA-256 checksum pair used in the workflow -- worth folding into the same fix.
Why this matters
docs/ci-supply-chain-policy.md is the canonical page for "what does the security job actually check" -- missing the newest and most security-relevant scanner from that list defeats its purpose, and it's already inconsistent with SECURITY.md and
.ai-context/WORKFLOWS.md, which do list it correctly.Proposed change
tests/scan-secrets.sh, checksum-pinned per release.Acceptance criteria
securityjob in.github/workflows/tests.yml.