ci: allowlist two verified gitleaks false positives

[TheAbider]

Problem

The weekly full-history gitleaks scan has failed every Monday since at least 2026-05-25 — eleven consecutive runs — always on the same two findings.

Run	Result
2026-08-03	failure
2026-07-27	failure
2026-07-20	failure
2026-07-13	failure
2026-07-06	failure
2026-06-29	failure
2026-06-22	failure
2026-06-15	failure
2026-06-08	failure
2026-06-01	failure
2026-05-25	failure (oldest run still listed)

The push and pull_request runs stay green because gitleaks only scans new commits on those events. Only the schedule run does git log -p --full-history --all, so it re-reports the same two historical commits forever.

A permanently red secret scanner is worse than no scanner: a genuine leak would arrive as "3 findings" in a job everyone has learned to skip.

The two findings are not credentials

Tests/Pester/Logging.Tests.ps1:133 — the fixture for the test asserting the logger redacts data keys named Token. The value is deliberately Stripe-shaped so the test is meaningful, and the assertion is that it never reaches the log file:

It 'redacts a key named "Token"' {
    Write-StructuredLog -Message 'auth' -Data @{ Token = 'sk_live_abcd1234' }
    (Read-LogContent $script:logPath) | Should -Not -Match 'sk_live_abcd1234'
}

Sibling cases in the same block use hunter2-plaintext and topsecret-xyz.

docs/fileserver-docker.md:145 — shows readers the shape of a Cloudflare tunnel token. The base64 payload decodes to:

{"a":"abcdef...","t":"a1b2c3d4...","s":"ABCDEF..."}

Literal ellipses, no live tunnel, no account identifier. The next line of that document reads "Never commit .env to version control."

Approach

Allowlist by exact literal value, not by path and not by commit, so a real secret added to either file in any future commit still fails.

Note the file uses the singular [allowlist] table. gitleaks 8.24.3 silently ignores the plural [[allowlists]] array at global scope — it parses without error, emits no warning, and suppresses nothing. Since push/PR runs skip history, a broken allowlist would not surface until the following Monday, so the file carries a maintenance warning and a re-verification command.

Verification

Run locally against full history with gitleaks 8.24.3 — the exact version CI pins — after checksum-verifying the release archive.

Scenario	Findings	Exit
Baseline, no config (reproduces CI)	2	2
Plural [[allowlists]] form	2	2
Singular [allowlist] form (this PR)	0	0
This PR + 3 planted secrets	3	2

The last row is the one that matters. Three secrets were planted and all three were caught while the two known false positives stayed suppressed — 3 findings, not 5:

1. A high-entropy TUNNEL_TOKEN appended to docs/fileserver-docker.md — an allowlisted file. Caught, proving the suppression is not path-scoped.
2. A near-miss of the allowlisted literal, sk_live_9f3c7a2e8b1d4506, in Tests/Pester/Logging.Tests.ps1. Caught, proving exact-value scoping.
3. A Google-shaped api_key in a new file. Caught.

The mutation commit was discarded and never pushed.

Follow-up

After merge, the gitleaks workflow should be dispatched manually on master to confirm the full-history path is green, since no required check exercises it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!