chore(ci): allowlist the validator key: field gitleaks false positive#17
Merged
Merged
Conversation
The `secrets` CI job runs `gitleaks git` over the full repo history, across all branches. The validator registry (validators/<category>/<id>.yaml) begins each file with `key: <validator-id>`, and gitleaks' generic-api-key rule reads that YAML field name as a credential assignment — flagging `validators/aws/s3_replication_kms_encryption.yaml` (the one whose identifier clears the entropy threshold today). It is a declarative validator identifier, not a secret. Because the scan spans full history, that one commit fails the secrets gate on *every* open PR, not just the branch that introduced it. Add a repo-root `.gitleaks.toml` that keeps the full default ruleset and adds a tightly-scoped allowlist: condition = "AND" over the generic-api-key rule, the validators/ path, and the leading `key: <snake_id>` line — so a real credential elsewhere, or from another rule, is still caught. Verified with gitleaks 8.30.1 (the CI version): scan goes from 1 finding to 0, and negative controls confirm neither the path nor the regex alone suppresses it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a repo-root
.gitleaks.tomlthat keeps gitleaks' full default ruleset and adds one narrowly-scoped allowlist for a false positive in the validator registry.Why
The
secretsCI job runsgitleaks gitover the full repo history, across all branches. Every validator file (validators/<category>/<id>.yaml) starts with:gitleaks'
generic-api-keyrule reads that YAML field name as a credential assignment and flagsvalidators/aws/s3_replication_kms_encryption.yaml(the one whose identifier clears the entropy threshold today). It's a declarative validator identifier, not a secret.Because the scan spans full history, that single commit trips the secrets gate on every open PR — including ones that never touched
validators/(e.g. #3). This unblocks all of them at once.The allowlist
condition = "AND"over three conditions, so a finding is suppressed only when all hold:generic-api-key,validators/….yaml,key: <snake_id>.A real credential elsewhere in a validator file — or from any other rule — is still reported.
Verification (gitleaks 8.30.1, the CI version)
.gitleaks.toml(auto-detected, exact CI invocation)key:regex forced non-matchkey:regex matches, path forced non-matchThe negative controls prove it's genuinely surgical — neither the path nor the regex alone suppresses the finding.
After merge
Merging this to
mainclears the gate for open PRs whose CI checkout merges inmain(#3, #15). They may need a re-run or a quick main-merge to pick it up.🤖 Generated with Claude Code