secret-scanner-reusable.yml: shell-secrets remediation cites the leak site as the model of good practice, and the path is dangling

[hyperpolymath]

Summary

The shell-secrets job's remediation message points developers at the exact file whose leak the job was created to prevent — and that file no longer exists, so the guidance cannot be followed even in principle.

secret-scanner-reusable.yml, line 734:

echo "::error::Hardcoded secret detected in a shell script. Source from env (see avow-protocol/deploy-repos.sh) instead."

Why this is a defect and not a nitpick

The same file identifies avow-protocol/deploy-repos.sh as the leak site, twice, in its own comments:

• line 17-19 — "The shell-secrets job (added to the canonical 2026-05-21 in response to the Cloudflare token leak via avow-protocol/deploy-repos.sh, which both trufflehog --only-verified and default gitleaks missed)"
• line 609-610 — "Added to canonical 2026-05-21 after default gitleaks missed a real Cloudflare API token leaked via avow-protocol/deploy-repos.sh."

So a developer who trips this gate is told, by the gate, to go and copy the pattern from the worst example of it in the estate. The file is cited in two opposite roles inside one file: the cause in the comments, the cure in the error text.

That file held a plaintext 40-character Cloudflare API token — the credential value, not an identifier — at avow-protocol/deploy-repos.sh:5, committed 55ad5333 on 2026-02-22, in a public repository, alongside the account id for the Cloudflare account that owns 36 zones. It was reported by an external party on 2026-05-21 and removed from the working tree by #161, whose own words were "The repo is public; assume the secret is burned regardless of any history rewrite."

Second, independent defect: the citation is dangling

GET /repos/hyperpolymath/standards/contents/avow-protocol/deploy-repos.sh returns 404 at the default branch — #161 removed it. So the message directs developers to a path that does not exist. Anyone following the advice finds nothing, and anyone who goes looking for it in history finds the leak commit instead.

Suggested fix

Replace the citation with a file that is genuinely exemplary, or drop the parenthetical entirely — the instruction "Source from env" is complete and correct without it:

echo "::error::Hardcoded secret detected in a shell script. Read the value from the environment (e.g. \"\${MY_TOKEN:?}\") and supply it via a repo or org secret."

Removing the citation is strictly better than repointing it, because any named example can rot the same way this one did, and the advice needs no example to be actionable.

How this surfaced

Found while fixing a finding this same gate correctly raised against hyperpolymath/cloudflare-dns-terraform#40. The gate worked: it caught a credential-shaped literal in a test fixture, and the right fix was to remove the shape rather than exempt the file — precisely because a gate of this class is the one whose absence let a real plaintext token sit in public history for ~7 months.

Worth stating plainly, because it is the argument for keeping this gate sharp: that repo is public, had secret scanning enabled and push protection on, and produced zero alerts for the whole period. Verified with a positive control in the same run — the same credential returns 2 alerts on hyperpolymath/ambientops, so the zero is a real absence and not a permissions error shaped like one. Push protection guards only new pushes; nothing backfilled. shell-secrets is the layer that actually catches this class, which is why its guidance should not point at the leak.

No token value appears in this issue, and none should be added to it.

🤖 Generated with Claude Code

https://claude.ai/code/session_019ggwBcC2PHLMn5ZSfma1eR