git-gate: restrict gitleaks inline suppression to supervised exceptions #208

New Issue

2026-06-06T14:40:17-04:00

didericis-claude commented

2026-06-06 14:40:17 -04:00

Background

# gitleaks:allow inline suppression is currently enabled in git-gate (the default gitleaks behaviour). This was useful during early development — test fixtures that deliberately construct credential-shaped strings (e.g. "npm_" + "A" * 36) would otherwise require manual exception entries for every pattern we add.

However, the same mechanism means any agent with write access to the repo could silence a real-secret finding by appending # gitleaks:allow to the offending line. That bypasses git-gate entirely and is not detectable after the fact from the commit diff alone.

What should change

Add a supervisor control flow for gitleaks findings:

When git-gate detects a # gitleaks:allow annotation on a finding, route it to the supervisor rather than auto-allowing it.
The supervisor presents the flagged line + file path and asks the human to confirm one of:
- Allow (test fixture): the file is under tests/ or similar and the value is clearly a dummy credential.
- Allow (false positive): the pattern matched something that is not actually a secret (e.g. a regex literal, a documentation example).
- Block: the annotation looks like an attempt to sneak a real secret through.
Only on explicit human approval does the push proceed.

This keeps # gitleaks:allow usable as a developer convenience while closing the agent-bypass path — the agent can write the annotation, but a human still has to confirm it before it lands.

Scope

Changes to git-gate pre-receive hook logic (or a wrapper around it).
The supervisor UI/flow for this case (similar to existing egress-block and capability-block supervisor controls).
Until this is implemented, # gitleaks:allow remains enabled as-is; the risk is accepted for the current development phase.

References

gitleaks inline suppression docs: https://github.com/gitleaks/gitleaks?tab=readme-ov-file#inline-scan-suppression
Existing supervisor controls: mcp__supervise__egress-block, mcp__supervise__capability-block
PRD 0053 (where the issue was first observed): #205

## Background `# gitleaks:allow` inline suppression is currently enabled in git-gate (the default gitleaks behaviour). This was useful during early development — test fixtures that deliberately construct credential-shaped strings (e.g. `"npm_" + "A" * 36`) would otherwise require manual exception entries for every pattern we add. However, the same mechanism means any agent with write access to the repo could silence a real-secret finding by appending `# gitleaks:allow` to the offending line. That bypasses git-gate entirely and is not detectable after the fact from the commit diff alone. ## What should change Add a **supervisor control flow** for gitleaks findings: 1. When git-gate detects a `# gitleaks:allow` annotation on a finding, route it to the supervisor rather than auto-allowing it. 2. The supervisor presents the flagged line + file path and asks the human to confirm one of: - **Allow (test fixture):** the file is under `tests/` or similar and the value is clearly a dummy credential. - **Allow (false positive):** the pattern matched something that is not actually a secret (e.g. a regex literal, a documentation example). - **Block:** the annotation looks like an attempt to sneak a real secret through. 3. Only on explicit human approval does the push proceed. This keeps `# gitleaks:allow` usable as a developer convenience while closing the agent-bypass path — the agent can write the annotation, but a human still has to confirm it before it lands. ## Scope - Changes to git-gate pre-receive hook logic (or a wrapper around it). - The supervisor UI/flow for this case (similar to existing egress-block and capability-block supervisor controls). - Until this is implemented, `# gitleaks:allow` remains enabled as-is; the risk is accepted for the current development phase. ## References - gitleaks inline suppression docs: https://github.com/gitleaks/gitleaks?tab=readme-ov-file#inline-scan-suppression - Existing supervisor controls: `mcp__supervise__egress-block`, `mcp__supervise__capability-block` - PRD 0053 (where the issue was first observed): #205

didericis added the Kind/Security label 2026-06-06 14:40:32 -04:00

didericis-codex referenced a pull request that will close this issue

2026-06-10 03:26:32 -04:00

PRD: Gitleaks inline suppression supervision #228

didericis closed this issue

2026-06-23 17:44:25 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: didericis/bot-bottle#208