fix: prevent false-positive secrets alerts on gitleaks scanning errors#10
Open
fix: prevent false-positive secrets alerts on gitleaks scanning errors#10
Conversation
When gitleaks encounters a git error (e.g., "Invalid revision range" on synchronize events with merge commits), it exits with code 1 (error) instead of code 2 (leaks found). The workflow previously treated any failure as "secrets detected", sending false-positive PR comments and Slack alerts to buzz-security. This adds a SARIF verification step that checks whether actual leaks were found before triggering alerts. Scanning errors now produce a warning annotation instead of false alerts. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Zen Agent <zen@composio.dev>
The gitleaks action (ScanPullRequest) fetches the PR commit list via GitHub API and constructs a range: first_commit^..last_commit. When actions/checkout checks out the default merge ref (refs/pull/<n>/merge), the PR HEAD commit may not be directly reachable via --first-parent in the resulting git graph, causing: fatal: Invalid revision range <base>^..<head> Fix by checking out the PR HEAD SHA directly and explicitly fetching the base branch, ensuring the full commit graph is available for gitleaks to scan. Also removes the SARIF verification workaround (continue-on-error + verify_leaks step) since fixing the root cause makes it unnecessary. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Zen Agent <zen@composio.dev>
Contributor
Author
PR Status UpdateCodex Review: Passed (LGTM) — no actionable issues found Changes
|
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
2 participants
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.
Description
Fixes
fatal: Invalid revision rangeerrors in the gitleaks secrets detection workflow that caused false-positive alerts on PR comments and Slack (buzz-security).Root cause: The gitleaks action (
ScanPullRequest) fetches the PR commit list via the GitHub API, then constructs a revision rangefirst_commit^..last_commitwith--first-parent. Butactions/checkoutdefaults to checking out the ephemeral merge ref (refs/pull/<n>/merge) — not the actual PR HEAD. When a PR contains merge commits (e.g., "Merge branch 'master' into feature"), the PR HEAD SHA differs from the merge ref's parents, and git cannot resolve the revision range via--first-parent, producing:This caused gitleaks to exit with code 1 (error, not leaks), but the workflow treated any failure as "secrets detected", firing false PR comments and Slack alerts.
Fix:
ref: ${{ github.event.pull_request.head.sha }}) instead of the merge ref, ensuring the actual PR commit graph is availablebaseRef^(the parent of the first PR commit) resolves correctlyPrevious attempts to fix this (commits
bd877ca,a10369f) tried fetching individual SHAs which doesn't work withgit fetch. This fix uses the correct approach of checking out the right ref from the start.How did I test this PR
00a87d52dd(merging03937c9203into0bbe5580e5)03937c9203^..a41436bd6f(from PR commits API)a41436bd6fis the actual PR HEAD (a merge commit on the PR branch), not reachable via--first-parentfrom the merge refsrc/gitleaks.js:160-172) to confirm how the revision range is constructed from PR commits APIgit logcommand locally — works when the PR HEAD is properly checked out, fails when the merge ref topology differsTriggered by: srujan@composio.dev | Source: slack
Session: https://zen-api-production-4c98.up.railway.app/dashboard/#/chat/zen-29d183b7c352