Skip to content

ci(gitleaks): switch to pull_request_target so fork PRs get GITLEAKS_LICENSE - #31

Merged
dgeyshis merged 1 commit into
masterfrom
fix/gitleaks-fork-pr-secrets
May 4, 2026
Merged

ci(gitleaks): switch to pull_request_target so fork PRs get GITLEAKS_LICENSE#31
dgeyshis merged 1 commit into
masterfrom
fix/gitleaks-fork-pr-secrets

Conversation

@yotamleo

@yotamleo yotamleo commented May 4, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Fork PRs (e.g. test: add pytest test suite and CI workflow #15 from joshbouncesecurity/OpenAnt) currently fail the gitleaks check with missing gitleaks license. GitHub strips secrets from pull_request runs whose head is in a fork, so ${{ secrets.GITLEAKS_LICENSE }} resolves to an empty string and gitleaks-action rejects the org.
  • Switch the trigger to pull_request_target, which runs in the base-repo context with org secrets available. Explicitly check out pull_request.head.sha so the scan still covers the contributor's commits, and update the scan-range branch to match the new event name.

Why this is safe

pull_request_target is dangerous when a workflow executes PR-controlled code (build steps, npm install, pip install, etc.). This workflow does not — it only runs gitleaks/gitleaks-action pinned by full SHA against the checked-out tree. No installer, no script execution, no test runner. The action reads files; it does not evaluate them.

Test plan

  • Merge → re-run check on PR test: add pytest test suite and CI workflow #15 (fork PR) → expect gitleaks SUCCESS with the license env populated.
  • Open a same-repo branch PR → confirm scan still works (no regression on the non-fork path).
  • Push to master → confirm push-event scan range falls through to the BEFORE_SHA..HEAD branch.

🤖 Generated with Claude Code

…AKS_LICENSE

Fork PRs (isCrossRepository=true) run with secrets stripped under the
'pull_request' event, so ${{ secrets.GITLEAKS_LICENSE }} resolves to
empty and the action fails with 'missing gitleaks license'.

pull_request_target runs in the base-repo context where org secrets
are available. We explicitly check out the PR head SHA so the scan
covers the contributor's commits. The job only runs gitleaks-action
(pinned by SHA) on the checked-out tree — no build, no install, no
PR-controlled scripts execute — so the usual pull_request_target risk
does not apply here.
@dgeyshis
dgeyshis merged commit 8c52d5a into master May 4, 2026
1 check passed
@dgeyshis
dgeyshis deleted the fix/gitleaks-fork-pr-secrets branch May 4, 2026 09:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants