chore(build): add gitleaks secret scanning workflow#69
Conversation
📝 WalkthroughWalkthroughA new GitHub Actions workflow file is added to the repository that configures automated secret scanning using Gitleaks. The workflow runs on pull requests and pushes to the main branch, executing the Gitleaks security scanner with necessary credentials from repository secrets. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/gitleaks.yml (1)
13-16: Pin both actions to full commit SHAs.
actions/checkout@v4andgitleaks/gitleaks-action@v2are mutable tags. Pinning to full SHAs gives you an immutable dependency and avoids future breakage if the repo/org enables GitHub's SHA-pinning policy. (docs.github.com)Hardening example
- - uses: actions/checkout@v4 + - uses: actions/checkout@<full-commit-sha> # v4 - - uses: gitleaks/gitleaks-action@v2 + - uses: gitleaks/gitleaks-action@<full-commit-sha> # v2🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/gitleaks.yml around lines 13 - 16, The workflow uses mutable tags actions/checkout@v4 and gitleaks/gitleaks-action@v2; replace each with the corresponding full commit SHA for the exact release you want to pin (e.g., actions/checkout@<full-commit-sha> and gitleaks/gitleaks-action@<full-commit-sha>) so the runner installs immutable commits; locate the two usages of actions/checkout and gitleaks/gitleaks-action in the workflow and update their ref values to the full commit SHAs from the respective repositories' tags/releases.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/gitleaks.yml:
- Around line 4-5: The gitleaks job currently runs for both push and
pull_request but fails on forked PRs because the gitleaks/gitleaks-action@v2
needs the GITLEAKS_LICENSE secret; update the gitleaks job to skip when the PR
is from a fork by adding a job-level condition checking the event: e.g., add an
if: that only runs when not a forked PR (for example if: github.event_name !=
'pull_request' || github.event.pull_request.head.repo.full_name ==
github.repository) or alternatively guard the job on presence of the secret
(check env.GITLEAKS_LICENSE) or replace the licensed action with a non-licensed
scanner; target the gitleaks job block and reference the
gitleaks/gitleaks-action@v2 usage and GITLEAKS_LICENSE secret when making the
change.
---
Nitpick comments:
In @.github/workflows/gitleaks.yml:
- Around line 13-16: The workflow uses mutable tags actions/checkout@v4 and
gitleaks/gitleaks-action@v2; replace each with the corresponding full commit SHA
for the exact release you want to pin (e.g., actions/checkout@<full-commit-sha>
and gitleaks/gitleaks-action@<full-commit-sha>) so the runner installs immutable
commits; locate the two usages of actions/checkout and gitleaks/gitleaks-action
in the workflow and update their ref values to the full commit SHAs from the
respective repositories' tags/releases.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c66719f4-f0ad-458a-8589-a8a68642f395
📒 Files selected for processing (1)
.github/workflows/gitleaks.yml
| pull_request: | ||
| push: |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/gitleaks.ymlRepository: questdb/net-questdb-client
Length of output: 570
🌐 Web query:
GitHub Actions secrets forked pull requests access restrictions
💡 Result:
- Default behavior (safe-by-default): For workflows triggered by
pull_requestfrom a fork, GitHub does not pass repository secrets to the runner (exceptGITHUB_TOKEN), and theGITHUB_TOKENis read-only for these runs. [1], [2] - Manual approval ≠ secrets access: Even if a maintainer must approve a workflow run from a public fork, that doesn’t change the default rule above—repo secrets still aren’t exposed to
pull_requestruns from forks. [1], [2] - Main foot-gun:
pull_request_target: Workflows triggered bypull_request_targetrun in the base repo context and can access secrets (and often have broader token permissions), even when the PR comes from a fork—this is why it’s considered higher risk and requires careful hardening (e.g., don’t run/check out untrusted PR code in that context). [3], [4] - Repo/org settings exist (especially for private repos): GitHub provides administrative controls for how fork PR workflows run/are approved, and historically added settings for enabling fork PR workflows (notably for private repos), but enabling secret sharing to forked PRs increases risk and should be paired with strict approvals and review. [1], [5]
Sources:
[1] GitHub Docs – Approving workflow runs from forks https://docs.github.com/en/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-public-forks
[2] GitHub Docs – Using secrets in GitHub Actions (note about forks) https://docs.github.com/en/actions/how-tos/administering-github-actions/sharing-workflows-secrets-and-runners-with-your-organization
[3] GitHub Well-Architected – Actions security (pull_request vs pull_request_target) https://wellarchitected.github.com/library/application-security/recommendations/actions-security/
[4] GitHub Changelog (2025-11-07) – pull_request_target + environment protections note on increased fork risk https://github.blog/changelog/2025-11-07-actions-pull_request_target-and-environment-branch-protections-changes/
[5] GitHub Blog – Actions improvements for fork and pull request workflows https://github.blog/news-insights/product-news/github-actions-improvements-for-fork-and-pull-request-workflows/
🌐 Web query:
gitleaks-action GITLEAKS_LICENSE requirement organization
💡 Result:
For gitleaks/gitleaks-action (the GitHub Marketplace “Gitleaks” action), GITLEAKS_LICENSE is required when scanning repositories owned by a GitHub Organization account, but not required for repositories owned by a personal account. [1], [3]
How orgs typically handle it:
- Obtain a (free) gitleaks-action license key from gitleaks.io, then store it as an Actions secret at the organization level (or per-repo) and pass it as
env: GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}. [1], [2] - The action documents that it sends license-validation data (including the license key, repo name, and repo owner) to its license validation service. [1]
If you want to avoid any license key requirement entirely, use an alternative GitHub Action wrapper such as gacts/gitleaks (it runs gitleaks without requiring a GITLEAKS_LICENSE). [4]
Sources: [GitHub Marketplace action docs] [1], [Gitleaks Medium setup post] [2], [gitleaks-action EULA summary] [3], [gacts/gitleaks action README] [4].
Guard fork PRs before requiring GITLEAKS_LICENSE.
pull_request runs for forked PRs, but GitHub does not pass repository/organization secrets to those workflows. Since gitleaks/gitleaks-action@v2 requires GITLEAKS_LICENSE for organization repositories (this repository is under the questdb organization), the job will fail for external contributors. Add a job-level condition to skip secret-dependent scanning for forked PRs, or switch to an alternative approach that does not require a licensed action.
Suggested fix
jobs:
gitleaks:
+ if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.fork == false
runs-on: ubuntu-latest🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gitleaks.yml around lines 4 - 5, The gitleaks job
currently runs for both push and pull_request but fails on forked PRs because
the gitleaks/gitleaks-action@v2 needs the GITLEAKS_LICENSE secret; update the
gitleaks job to skip when the PR is from a fork by adding a job-level condition
checking the event: e.g., add an if: that only runs when not a forked PR (for
example if: github.event_name != 'pull_request' ||
github.event.pull_request.head.repo.full_name == github.repository) or
alternatively guard the job on presence of the secret (check
env.GITLEAKS_LICENSE) or replace the licensed action with a non-licensed
scanner; target the gitleaks job block and reference the
gitleaks/gitleaks-action@v2 usage and GITLEAKS_LICENSE secret when making the
change.
Summary
gitleaks/gitleaks-action@v2withGITLEAKS_LICENSEsecretReference: questdb/questdb#6863
Summary by CodeRabbit