Summary
.github/workflows/secret-scan.yml pins GITLEAKS_VERSION="8.18.4". Newer gitleaks releases ship a curl-auth-header rule in the default ruleset (.gitleaks.toml sets [extend] useDefault = true, so we inherit it automatically). That rule flags two lines in a committed doc. CI is green today only because 8.18.4 predates the rule — the job fails the moment anyone bumps the pin.
Evidence
Scanning the current tree with gitleaks 8.30.0 using the repo's own config:
$ gitleaks detect --source . --config .gitleaks.toml --no-git --redact --exit-code 1
INF scanned ~63255682 bytes (63.26 MB) in 9.55s
WRN leaks found: 2
Both findings are the same false positive:
RuleID: curl-auth-header
File: docs/knowledge_prototypes/universal-automation-service/TECHNICAL_NOTES.md
Line: 30
RuleID: curl-auth-header
File: docs/knowledge_prototypes/universal-automation-service/TECHNICAL_NOTES.md
Line: 201
The flagged content is a documented curl example whose header value is a literal placeholder, not a credential:
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash-exp:generateContent" \
-H 'Content-Type: application/json' \
-H 'X-goog-api-key: REDACTED_GOOGLE_API_KEY_ROTATE' \
curl-auth-header matches on the shape of an auth header in a curl invocation, so the placeholder text is irrelevant to it. Confirmed the rule is not defined in our .gitleaks.toml — it comes from the inherited default ruleset.
Why this matters
secret-scan.yml runs gitleaks detect --no-git --config .gitleaks.toml --redact --verbose --exit-code 1 on push to main and on all PRs, so it is a merge gate. The failure mode is silent-until-triggered: a routine dependency/version bump turns a green required check red, with a finding that looks like a leaked Google API key and will read as a genuine incident to whoever picks it up.
Surfaced while verifying #1215 (uv.lock digest allowlist). Deliberately kept out of that fix, which is scoped to lockfile digests.
Proposed fix
Add a targeted allowlist entry so the placeholder is suppressed by value, not by silencing the rule or excluding the whole path:
regexes = [
# existing uv.lock digest entry ...
# Documented curl examples use a literal placeholder in the auth header.
# gitleaks' `curl-auth-header` rule (default ruleset, added after 8.18.4)
# matches the header shape, so the placeholder itself must be allowlisted.
'''REDACTED_[A-Z_]+''',
]
This keeps curl-auth-header active everywhere else and leaves the file scanned for real secrets.
Acceptance criteria
Verification
gitleaks detect --source . --config .gitleaks.toml --no-git --redact --exit-code 1
echo "exit=$?" # expect 0
Summary
.github/workflows/secret-scan.ymlpinsGITLEAKS_VERSION="8.18.4". Newer gitleaks releases ship acurl-auth-headerrule in the default ruleset (.gitleaks.tomlsets[extend] useDefault = true, so we inherit it automatically). That rule flags two lines in a committed doc. CI is green today only because 8.18.4 predates the rule — the job fails the moment anyone bumps the pin.Evidence
Scanning the current tree with gitleaks 8.30.0 using the repo's own config:
Both findings are the same false positive:
The flagged content is a documented
curlexample whose header value is a literal placeholder, not a credential:curl-auth-headermatches on the shape of an auth header in a curl invocation, so the placeholder text is irrelevant to it. Confirmed the rule is not defined in our.gitleaks.toml— it comes from the inherited default ruleset.Why this matters
secret-scan.ymlrunsgitleaks detect --no-git --config .gitleaks.toml --redact --verbose --exit-code 1on push tomainand on all PRs, so it is a merge gate. The failure mode is silent-until-triggered: a routine dependency/version bump turns a green required check red, with a finding that looks like a leaked Google API key and will read as a genuine incident to whoever picks it up.Surfaced while verifying #1215 (uv.lock digest allowlist). Deliberately kept out of that fix, which is scoped to lockfile digests.
Proposed fix
Add a targeted allowlist entry so the placeholder is suppressed by value, not by silencing the rule or excluding the whole path:
This keeps
curl-auth-headeractive everywhere else and leaves the file scanned for real secrets.Acceptance criteria
gitleaks detect --no-git --config .gitleaks.toml --exit-code 1exits 0 against a current gitleaks release, not just 8.18.4curl-auth-headerrule remains enabled (not disabled, and the docs path is not blanket-excluded)uv.lockdigest suppression from Allow gitleaks to ignore uv.lock SHA-256 digest lines #1215 still holds — 4800/4800 digest lines matchedGITLEAKS_VERSIONis bumped in the same change so the fix is proven under the newer ruleset rather than left latentVerification