chore: allowlist the test-fixture secret so the scanner stays trustworthy (#132) #438

Merged
claude-bot merged 1 commit from chore/gitleaks-allowlist into main 2026-08-29 22:26:40 +00:00
Contributor

Adds .gitleaks.toml extending the default ruleset, with one path allowlist.

#132 has been reporting a single finding: a generic-api-key at webapp/backend/tests/test_config.py:8. Checked rather than assumed — it is:

VALID_SECRET = "0123456789abcdef0123456789abcdef"

in a file whose docstring reads "Tests for startup validation of placeholder and weak secrets." It exists to prove the app accepts a well-formed key while rejecting weak ones. Never a live credential.

Why bother. Not the noise — what permanent noise does. A scanner that always says "1 secret" is a scanner nobody reads, and this week #428 found a real credential sitting in plaintext at rest, unnoticed for months and present in every backup. The next finding has to mean something.

Why a path allowlist rather than an inline gitleaks:allow. The finding is reported against a historical commit (f25ee12096, 2026-07-14), so a marker in the working tree would not suppress it.

⚠️ This may not be enough on its own. The scanner is fleet-wide — security-scan.yml is not in this repo's .forgejo/workflows. A repo-local .gitleaks.toml is only picked up when gitleaks runs without an explicit --config. If the fleet runner passes its own config, the allowlist has to move to the iac-repo instead. Worth confirming on the next scheduled scan; if #132 still shows the finding, that is the reason.

The file's header sets the bar for future additions: allowlist only when the value is demonstrably not a live credential, say why, and if in doubt rotate instead.

🤖 Generated with Claude Code

Adds `.gitleaks.toml` extending the default ruleset, with one path allowlist. #132 has been reporting a single finding: a `generic-api-key` at `webapp/backend/tests/test_config.py:8`. Checked rather than assumed — it is: ```python VALID_SECRET = "0123456789abcdef0123456789abcdef" ``` in a file whose docstring reads *"Tests for startup validation of placeholder and weak secrets."* It exists to prove the app **accepts** a well-formed key while rejecting weak ones. Never a live credential. **Why bother.** Not the noise — what permanent noise does. A scanner that always says "1 secret" is a scanner nobody reads, and this week #428 found a real credential sitting in plaintext at rest, unnoticed for months and present in every backup. The next finding has to mean something. **Why a path allowlist rather than an inline `gitleaks:allow`.** The finding is reported against a historical commit (`f25ee12096`, 2026-07-14), so a marker in the working tree would not suppress it. ⚠️ **This may not be enough on its own.** The scanner is fleet-wide — `security-scan.yml` is not in this repo's `.forgejo/workflows`. A repo-local `.gitleaks.toml` is only picked up when gitleaks runs without an explicit `--config`. If the fleet runner passes its own config, the allowlist has to move to the iac-repo instead. Worth confirming on the next scheduled scan; if #132 still shows the finding, that is the reason. The file's header sets the bar for future additions: allowlist only when the value is demonstrably not a live credential, say why, and **if in doubt rotate instead**. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
chore: allowlist the test-fixture secret so the scanner stays trustworthy (#132)
All checks were successful
CI / Summarisation accuracy eval harness (stub provider) (pull_request) Successful in 1m56s
CI / Frontend tests, audit, and build (pull_request) Successful in 3m0s
CI / Bot/backend version sync (pull_request) Successful in 26s
CI / Backend lint (ruff) (pull_request) Successful in 28s
CI / Bot tests and audit (pull_request) Successful in 3m0s
CI / Docker image build (pull_request) Successful in 4m51s
CI / Backend migration, tests, and audit (pull_request) Successful in 13m39s
0e42e4490b
The fleet security scanner has reported exactly one finding for some time: a
`generic-api-key` at webapp/backend/tests/test_config.py:8. It is
`VALID_SECRET = "0123456789abcdef0123456789abcdef"`, in a file whose docstring
reads "Tests for startup validation of placeholder and weak secrets" — a
deliberately fake value that exists to prove the app ACCEPTS a well-formed key
while rejecting weak ones. It has never been a live credential.

The point is not the noise, it is what permanent noise does. A scanner that
always says "1 secret" is a scanner nobody reads, and this week #428 found a
real credential in plaintext at rest that had gone unnoticed for months. The
next finding needs to mean something.

Allowlisted by path rather than by an inline `gitleaks:allow` comment, because
the finding is reported against a historical commit (f25ee12096, 2026-07-14)
and an inline marker in the working tree would not suppress it.

NOTE: the scanner lives in the fleet repo, not here (`security-scan.yml` is not
in .forgejo/workflows). This config only takes effect if gitleaks is invoked
without an explicit --config, in which case it picks up .gitleaks.toml from the
scanned repository. If the fleet runner passes its own config, the allowlist
has to move there instead — worth confirming on the next scheduled scan.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
No description provided.