chore(build): add gitleaks secret scanning workflow#137
Conversation
📝 WalkthroughWalkthroughA new GitHub Actions workflow file is added to enable Gitleaks secret scanning on pull requests and pushes to the main branch. The workflow checks out the repository with full history and executes the gitleaks-action v2, passing GitHub token and license credentials from secrets as environment variables. 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 |
sklarsa
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 workflow runs on pull_request and unconditionally sets
the GITLEAKS_LICENSE env for gitleaks-action@v2, causing forked PRs to fail
because secrets aren't available; update the workflow to detect external PRs
(use github.event.pull_request.head.repo.fork or github.actor !=
repository_owner) and conditionally run the licensed gitleaks step only when the
secret is present/PR is internal, otherwise run an alternative non-secret scan
or skip the licensed step; reference the GITLEAKS_LICENSE environment entry and
the gitleaks-action@v2 step when adding the if: condition and a fallback step.
- Around line 13-16: The workflow uses movable tags for actions/checkout@v4 and
gitleaks/gitleaks-action@v2; replace those tag refs with the corresponding full
commit SHAs (the immutable full-length commit IDs) for both "uses" entries so
the workflow pins exact action commits (locate the actions/checkout and
gitleaks/gitleaks-action references in the YAML and substitute the tag@<sha>
form), then verify the workflow still passes and that secrets consumed by
gitleaks remain scoped as before.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c7667065-1566-4a91-8528-40d46606bdbc
📒 Files selected for processing (1)
.github/workflows/gitleaks.yml
| pull_request: | ||
| push: |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Read the gitleaks workflow file to understand its full structure
cat -n .github/workflows/gitleaks.ymlRepository: questdb/c-questdb-client
Length of output: 568
🌐 Web query:
gitleaks-action v2 GITLEAKS_LICENSE requirement
💡 Result:
For gitleaks/gitleaks-action@v2, GITLEAKS_LICENSE is only required when scanning repositories owned by a GitHub Organization account; it’s not required for repos under a personal (user) account. [1]
You obtain a (free) license key from gitleaks.io, store it as an encrypted GitHub Actions secret (repo- or org-level), and pass it to the action as GITLEAKS_LICENSE. [1]
Note: the action validates the key via a third-party licensing service (“keygen”) and sends the license key plus repo owner/name for validation. [1]
🌐 Web query:
GitHub Actions secrets fork pull request workflow
💡 Result:
-
Default behavior (safe by default): Workflows triggered by
pull_requestfrom forks run with a read-onlyGITHUB_TOKENand no access to repository secrets (org/repo/environment secrets). This is to prevent secret exfiltration by untrusted code in fork PRs. [1], [2], [3] -
Repo setting: “Require approval” (controls whether the workflow runs at all, not secret access): Public repos can be configured so fork-PR workflows don’t run automatically and require approval depending on contributor status (“Approval for running fork pull request workflows from contributors”). Even when approved, fork-PR runs still don’t get secrets under the default security model. [3], [4]
-
Repo/org setting: “Send secrets and variables to workflows from fork pull requests” (high risk): If you enable this, fork PR workflows may receive secrets—which is dangerous unless you fully trust/verify the code path, because a fork can modify workflow behavior to exfiltrate secrets. (GitHub explicitly highlights fork PRs as a security concern.) [3]
-
pull_request_target(powerful but commonly misused):pull_request_targetruns in the context of the base repo and can access secrets; GitHub and GitHub Security Lab warn it has increased risk with fork PRs if you execute attacker-controlled PR code (the “pwn request” class of issues). Prefer not to use it unless you know the secure patterns. [5], [6] -
Common secure pattern:
- Run CI/tests on
pull_requestwithout secrets. - Do privileged steps (publish/deploy/comment with elevated perms) in a separate workflow triggered by trusted events (e.g.,
pushtomain, or a carefully designedworkflow_run), so secrets are never exposed to untrusted PR code. [4], [6]
- Run CI/tests on
Sources:
[1] GitHub Docs – “Understanding GitHub secret types” (fork PRs don’t receive Actions secrets) (docs.github.com)
[2] GitHub Blog – “GitHub Actions improvements for fork and pull request workflows” (read-only token, no secrets for fork PRs) (github.blog)
[3] GitHub Docs – “Managing GitHub Actions settings for a repository” (fork PR workflow settings) (docs.github.com)
[4] GitHub Blog – “4 tips to keep your GitHub Actions workflows secure” (fork PRs: no secrets, read-only token) (github.blog)
[5] GitHub Changelog (2025-11-07) – pull_request_target risk/secret exposure considerations (github.blog)
[6] GitHub Security Lab – “Preventing pwn requests” (pull_request_target pitfalls) (securitylab.github.com)
Citations:
- 1: https://docs.github.com/en/enterprise-server%403.17/code-security/reference/secret-security/understanding-github-secret-types?utm_source=openai
- 2: https://github.blog/news-insights/product-news/github-actions-improvements-for-fork-and-pull-request-workflows/?utm_source=openai
- 3: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository?from=20423&from_column=20423&utm_source=openai
- 4: https://github.blog/security/supply-chain-security/four-tips-to-keep-your-github-actions-workflows-secure/?utm_source=openai
- 5: https://github.blog/changelog/2025-11-07-actions-pull_request_target-and-environment-branch-protections-changes?utm_source=openai
- 6: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/?utm_source=openai
Fork PRs will fail because GITLEAKS_LICENSE is unavailable.
This workflow runs on pull_request (including forks) but unconditionally references GITLEAKS_LICENSE in the environment. GitHub Actions does not pass repository secrets to fork-triggered PR workflows by default, so external contributor PRs will fail. Since gitleaks-action@v2 requires GITLEAKS_LICENSE for organization repositories, consider guarding the licensed scan behind a condition that skips external PRs, or add a separate non-secret fallback scan path for forks.
🤖 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 workflow runs on
pull_request and unconditionally sets the GITLEAKS_LICENSE env for
gitleaks-action@v2, causing forked PRs to fail because secrets aren't available;
update the workflow to detect external PRs (use
github.event.pull_request.head.repo.fork or github.actor != repository_owner)
and conditionally run the licensed gitleaks step only when the secret is
present/PR is internal, otherwise run an alternative non-secret scan or skip the
licensed step; reference the GITLEAKS_LICENSE environment entry and the
gitleaks-action@v2 step when adding the if: condition and a fallback step.
| - uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 | ||
| - uses: gitleaks/gitleaks-action@v2 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/gitleaks.ymlRepository: questdb/c-questdb-client
Length of output: 568
🌐 Web query:
GitHub Actions security hardening full commit SHA pin action references best practice
💡 Result:
Best practice: pin GitHub Actions to a full commit SHA
- Pin all third‑party actions to an immutable ref—preferably a full, 40‑char commit SHA (not a branch like
main/master, and not a mutable tag likev1). GitHub explicitly calls SHA pinning “the only way to use an action as an immutable release,” and recommends it to reduce supply‑chain risk (tags can be moved). [1] - Choose the SHA that corresponds to a tagged release, and add a comment with the human version to keep updates manageable (and friendlier for update tooling). Example: [2]
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
- Verify the SHA comes from the action’s official repository (not a fork) before pinning. [1]
- Enforce SHA pinning via policy (enterprise/org/repo). GitHub supports requiring actions to be pinned to full-length SHAs, and this can be enforced in Actions policies (and via API fields like
sha_pinning_required). [3][4] - Also consider pinning reusable workflow references, and/or restrict which actions/workflows are allowed to run using “allowed actions and reusable workflows” policy controls. [4][5]
Why this is recommended
GitHub recommends SHA pinning to proactively limit the impact of a compromised dependency in workflows. [5]
Sources
[1] GitHub Docs — Security hardening for GitHub Actions (Pin actions to a full length commit SHA) (docs.github.com)
[2] GitHub Well-Architected — Securing GitHub Actions Workflows (example of SHA pin + version comment) (wellarchitected.github.com)
[3] GitHub Enterprise Cloud Docs — Enforcing policies for GitHub Actions in your enterprise (require full-length SHA option) (docs.github.com)
[4] GitHub Docs — Disabling or limiting GitHub Actions for your organization (allow-list syntax; tag-or-SHA) (docs.github.com)
[5] GitHub Changelog — Actions policy now supports blocking and SHA pinning actions (recommends pinning to specific commit SHA) (github.blog)
Citations:
- 1: https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions&utm_source=openai
- 2: https://wellarchitected.github.com/library/application-security/recommendations/actions-security/?utm_source=openai
- 3: https://docs.github.com/github-ae%40latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise?utm_source=openai
- 4: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization?from=20423&from_column=20423&utm_source=openai
- 5: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/?utm_source=openai
Pin action refs to full commit SHAs.
Both steps are using movable tags, and the gitleaks step receives repository secrets. GitHub's secure-use guidance recommends full-length commit SHAs because that is the only immutable way to reference an action release and it reduces tag-retargeting risk. (docs.github.com)
🔒 Suggested hardening
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<verified-full-length-commit-sha> # v4
with:
fetch-depth: 0
- - uses: gitleaks/gitleaks-action@v2
+ - uses: gitleaks/gitleaks-action@<verified-full-length-commit-sha> # v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}🤖 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
movable tags for actions/checkout@v4 and gitleaks/gitleaks-action@v2; replace
those tag refs with the corresponding full commit SHAs (the immutable
full-length commit IDs) for both "uses" entries so the workflow pins exact
action commits (locate the actions/checkout and gitleaks/gitleaks-action
references in the YAML and substitute the tag@<sha> form), then verify the
workflow still passes and that secrets consumed by gitleaks remain scoped as
before.
1 participant
Summary
gitleaks/gitleaks-action@v2withGITLEAKS_LICENSEsecretReference: questdb/questdb#6863
Summary by CodeRabbit