sec(scripts): git-secrets allowed patterns are line regexes and whitelist most lines

[cristim]

Summary

git secrets --add --allowed <re> suppresses any scanned line matching the regex; it is a content filter, not a path filter. scripts/setup-git-secrets.sh registers 'resource\s', 'var\.', 'local\.', 'data\.' and 'module\.' as allowed patterns, which whitelists every Terraform resource-block line and any line containing those substrings anywhere in the repo. A real credential placed on such a line passes the local pre-commit gate silently. The neighbouring '_test\.go' and 'testdata/' entries show the intent was to exclude paths, which this mechanism cannot do. Reproduced in a throwaway repo: with --allowed 'resource\s' registered, resource "aws_iam_access_key" "x" { key = "AKIAABCDEFGHIJKLMNOP" } scanned clean while the same key on a plain line exited 1.

Location

scripts/setup-git-secrets.sh:104 at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (the Terraform entries at 103-105; the var\. / local\. / data\. entries a few lines above)

Failure scenario

A developer commits a Terraform file containing resource "aws_iam_access_key" "x" { secret = "AKIA..." } or an .env-style line mentioning data.; git secrets --scan matches the allowed regex against the whole line and reports nothing. The repo's other gate for this (gitleaks in CI) may still catch it, but the local gate make setup-git-secrets installs is advertised as AWS-key coverage it does not deliver.

Evidence

git secrets --add --allowed 'var\.'
git secrets --add --allowed 'data\.'
...
git secrets --add --allowed 'resource\s'
git secrets --add --allowed 'module\.'

Suggested fix

Delete the substring allowlist entries and rely on .gitallowed, which is already scoped to specific placeholder values; if path exclusions are genuinely needed, filter the file list before invoking git secrets --scan. A sibling defect in the same script, the inverted AWS secret-key pattern on line 52, is filed separately as audit finding A14-009 and is worth fixing in the same change.

---

Found by the 2026-09-02 codebase audit, finding A14-010, reported by one reviewer and independently confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md.

[cristim]

Verified against current main (7a541dae919249c6d360d432d1f1cdc6b34cef9e): fully fixed.

scripts/setup-git-secrets.sh no longer registers any git secrets --add --allowed <substring-regex> entries ('var\.', 'local\.', 'data\.', 'resource\s', 'module\.' are all gone). Allowed literals now live in .gitallowed (versioned, applied by every scan including CI), which whitelists specific benign values rather than whole-line substrings.

The GCP API-key pattern at scripts/setup-git-secrets.sh:102 is now 'AIza[0-9A-Za-z_-]{35}' — hyphen moved to the end of the bracket expression so it's a literal, not a range endpoint (Z-_). No longer rejected as invalid character range by BSD/glibc/GNU regex engines, so git secrets --scan no longer exits 128.

Fixed by merged PR #101 (sec(scripts): git-secrets allowlist matched whole lines and whitelisted most of the repo, merge commit 7a541dae919249c6d360d432d1f1cdc6b34cef9e), which also fixed the related say()/hook-verification and PEM-pattern issues noted in that PR's commit chain.

Closing as completed; no residual work.