gitleaks binary is pinned to 8.21.2 (Oct 2024) with no update path — Renovate cannot see it, and the anthropic-api-key rule does not exist in it #30

Activity

1. CameronBrooks11

   added

   bugSomething isn't workingSomething isn't working

   dependencies

   on Sep 10, 2026
2. CameronBrooks11 commented on Sep 10, 2026

   

   CameronBrooks11

   on Sep 10, 2026

   ContributorAuthor

   More actions

   Verified, measured, and fixed in #31 (not merged).

   What held up, and what did not

   Claim	Verdict
   default: "8.21.2" at line 18	Confirmed on main
   No caller overrides gitleaks-version	Confirmed — zero overrides across every caller
   All pinned revisions carry the same default	Confirmed, but 9 revisions are in use, not 4
   "Eight repos"	Wrong. 66.
   8.21.2 has no anthropic-api-key rule	Confirmed empirically — and there are two Anthropic rules, not one
   "Twelve rule files added"	True of files; the rule-ID count is 27 added, 0 removed

   The undercount is the part worth correcting. The listing in the description covered eight repos; enumerating the whole org finds this workflow called by 66 of 67:

   $ gh api "orgs/FlowMatrix-AI/repos?per_page=100&type=all" --paginate --jq '.[].name' | wc -l
   67
   # then fetch every .github/workflows/*.yml in each and grep for gitleaks.yml
   $ grep -c . caller-repos.txt
   66
   

   Nine distinct revisions of this file are pinned across them (158c5963, 1bbaee7d, 5eb6dcf1, 8aa90186, bbd63dc5, d12147b2, d2eab9f6, df3d01bf, fdd02918), spanning 2026-07-06 to 2026-09-05, and default: "8.21.2" is present at every one — checked at each SHA, not inferred.

   The rule gap, pinned down

   anthropic.go first ships in v8.28.0 (2025-07-20). Absent at 8.21.2, 8.22.0, 8.23.0, 8.24.0, 8.25.0, 8.26.0, 8.27.0, 8.27.1, 8.27.2; present from 8.28.0 through 8.30.1. It defines anthropic-api-key and anthropic-admin-api-key (sk-ant-admin01-…), which the description missed.

   The null result has a positive control: the same v8.21.2 listing does contain openai.go, so the check would have found anthropic.go had it been there.

   Not argued from source — run against a throwaway repo holding one synthetic key of each shape, with this org's .gitleaks.toml:

   ===== gitleaks 8.21.2 =====   OPENAI_API_KEY -> generic-api-key            leaks found: 1
   ===== gitleaks 8.30.1 =====   anthropic-admin-api-key, anthropic-api-key   leaks found: 2
   

   Built-in rule IDs: 195 at v8.21.2, 222 at v8.30.1 (grep -cE '^\s*id\s*=' config/gitleaks.toml at each tag). Beyond Anthropic, the additions that matter here include both Amazon Bedrock key rules, perplexity-api-key, notion-api-token, 1password-secret-key, two Sentry token rules, heroku-api-key-v2, two routable GitLab token rules, and sonar-api-token.

   Blast radius: zero

   All 66 callers were cloned with full history and scanned with both versions, replicating what the workflow does (fetch the org config to .gitleaks.org.toml, copy to .gitleaks.toml only where the repo has none, then gitleaks git --redact -v --config .gitleaks.toml).

   0 findings on 8.21.2. 0 findings on 8.30.1. No repo turns red, and no allowlist entries are needed — so no repo needs to fork the org config either. 145 MB and ~4,900 commits scanned.

   report files: 132 | files with >0 findings: 0
   $ grep -E 'WRN leaks found' reports/*.log
   (none)
   

   Three checks behind that null result:

   1. The harness reports when there is something to report — the control above returned 2 findings through the same path.
   2. The eight callers that commit their own .gitleaks.toml also gain the coverage: injecting a synthetic key into one gives 1 finding on 8.21.2 and 2 on 8.30.1, because useDefault = true chains the new built-ins through. No edits needed there.
   3. It is genuinely full history: gitleaks git defaults to --all, so on the largest caller it scanned 412 commits where rev-list HEAD is 364.

   No true positives. Nothing is being withheld from this thread.

   Fix

   #31 takes option (1) from the description. default: moves to 8.30.1 and carries:

   # renovate: datasource=github-releases depName=gitleaks/gitleaks extractVersion=^v(?<version>.+)$
   

   Renovate's own customManagers:githubActionsVersions preset uses exactly this comment convention but its matchString only accepts a key ending in _VERSION, so a workflow input default: never matches — hence a small customManager in renovate.json, written by shape rather than naming gitleaks. extractVersion is load-bearing: the tag is v8.30.1 and the curl URL supplies its own v.

   Proven by running renovate itself against the branch (--platform=local --dry-run=lookup, renovate 44.61.5): extraction goes from 4 files / 5 deps on main to 6 files / 7 deps, with "depName": "gitleaks/gitleaks", "currentValue": "8.30.1", "datasource": "github-releases", "currentVersion": "8.30.1", "updates": []. It also concatenates with rather than replacing the org preset's uv tool install manager — verified against mergeChildConfig, which returns parent entries then child entries for customManagers.

   The org preset's automerge rules do not match custom.regex, so future releases open a reviewable PR rather than automerging.

   CI on the PR confirms it end to end: gitleaks version → 8.30.1, no leaks found.

   Two things found alongside

   • .pre-commit-config.yaml had the same rot. It pinned rev: v8.21.2 for the same hook, and Renovate's pre-commit manager is off by default, so that file was not in Detected Dependencies at all — the same defect on the developer-machine gate. fix(gitleaks): bump the org scanner to 8.30.1 and make the pin Renovate-trackable #31 enables the manager and bumps it. This repo is the only caller carrying that file.
   • The install step has no integrity check. curl … | tar -xz into /usr/local/bin, and Renovate cannot pin a digest for a tarball URL, though releases publish gitleaks_<v>_checksums.txt. Different defect, deliberately left out of fix(gitleaks): bump the org scanner to 8.30.1 and make the pin Renovate-trackable #31.

   One behaviour change to know about: --max-decode-depth defaults to 5 in 8.30.1 versus 0 in 8.21.2, so nested base64 is now decoded and scanned. It produced no new findings on any caller, but it is the likeliest source of a future false positive.
3. CameronBrooks11

   closed this as completedin #31on Sep 28, 2026
4. CameronBrooks11

   added a commit that references this issue on Sep 28, 2026

   fix(gitleaks): bump the org scanner to 8.30.1 and make the pin Renova…

   ...

   933396f