test: pin the gitleaks allowlist against silent rot (Section 207)

[TheAbider]

Follow-up to #97.

Problem

#97 got the weekly full-history gitleaks scan back to green, but nothing stops that fix from being silently undone.

The workflow has two behaviours and only one of them can fail on history:

• push / pull_request → scans only the new commits. Green regardless of what is in history or what the allowlist does.
• schedule / workflow_dispatch → gitleaks detect over full history.

So a broken allowlist produces a perfectly green PR and stays invisible until the following Monday's failure email. There is no pre-merge signal at all. That is precisely how the previous eleven-week red streak went unnoticed.

What this pins

New Section 207: SECRET-SCANNER CONFIG INTEGRITY in Tests/Run-Tests.ps1, following the Section 206 pattern:

Assert	Guards against
singular [allowlist] table is used	—
[[allowlists]] is absent	gitleaks 8.24.3 silently ignores the plural array at global scope — parses, no warning, suppresses nothing
no paths = entry	blinding the scanner to a whole file
no commits = entry	blinding the scanner to a whole commit
useDefault = true	an allowlist layered over an empty ruleset that scans for nothing
exactly 2 regex entries	silent additions slipping in unreviewed
no catch-all regex	'''.*''' silencing the scanner wholesale
workflow keeps schedule:	removing the only trigger that scans history
workflow keeps fetch-depth: 0	a shallow checkout with no history to scan

The plural-array assert is the important one. Most current gitleaks documentation shows [[allowlists]], so "modernising" this file is an easy and completely silent way to break it.

The section deliberately does not embed the two allowlisted literals — it counts entries instead. Embedding them would reintroduce the exact strings the config exists to describe into a new file.

Verification

Passing: all 10 asserts pass; suite green at 5438 tests, 0 failed, 0 skipped, exit 0.

Mutation-verified — a guard that cannot fail is decoration. Violating all six config invariants and both workflow invariants simultaneously ([[allowlists]], paths, commits, useDefault = false, 4 entries, catch-all regex, schedule: stripped, fetch-depth: 1):

[PASS] Gitleaks: .gitleaks.toml present at repo root
[FAIL] Gitleaks: uses the singular [allowlist] table
[FAIL] Gitleaks: avoids [[allowlists]] (silent no-op on 8.24.3)
[FAIL] Gitleaks: allowlist exempts no whole paths
[FAIL] Gitleaks: allowlist exempts no whole commits
[FAIL] Gitleaks: extends the default ruleset
[FAIL] Gitleaks: allowlist holds exactly 2 reviewed entries
       Error: found 4
[FAIL] Gitleaks: allowlist contains no catch-all regex
[FAIL] Gitleaks: workflow keeps the scheduled full-history scan
[FAIL] Gitleaks: workflow checks out full history (fetch-depth: 0)

9 of 10 fail and the suite exits 1. The tenth correctly still passes — the file did exist. Both mutated files were restored from git and verified byte-identical to master.

Also re-ran a local full-history gitleaks scan on this branch: 592 commits, no leaks found — the new test code introduces no findings of its own.

Tests/Run-Tests.ps1 parses clean and is PSScriptAnalyzer-clean under the repo settings. README badge 5428 → 5438, synced by the suite's own self-heal rather than by hand.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!