Skip to content

chore(build): add gitleaks secret scanning workflow#69

Open
sklarsa wants to merge 1 commit intomainfrom
add-gitleaks-workflow
Open

chore(build): add gitleaks secret scanning workflow#69
sklarsa wants to merge 1 commit intomainfrom
add-gitleaks-workflow

Conversation

@sklarsa
Copy link
Contributor

@sklarsa sklarsa commented Mar 10, 2026

Summary

  • Adds a Gitleaks GitHub Actions workflow to scan for secrets on pull requests and pushes to the default branch
  • Uses gitleaks/gitleaks-action@v2 with GITLEAKS_LICENSE secret

Reference: questdb/questdb#6863

Summary by CodeRabbit

  • Chores
    • Added automated secret scanning workflow for pull requests and main branch pushes to enhance code security.

@coderabbitai
Copy link

coderabbitai bot commented Mar 10, 2026

📝 Walkthrough

Walkthrough

A 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

Cohort / File(s) Summary
GitHub Actions Workflow
.github/workflows/gitleaks.yml
Adds new Gitleaks security scanning workflow configured to run on pull requests and main branch pushes, with job checking out repository and executing gitleaks-action@v2 using GitHub and license tokens.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A whisker-twitch of security delight,
Where secrets hide, now caught in Gitleaks' sight!
Each pull, each push, a scan so keen,
The safest code we've ever seen. ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: adding a Gitleaks workflow for secret scanning in GitHub Actions.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch add-gitleaks-workflow

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
.github/workflows/gitleaks.yml (1)

13-16: Pin both actions to full commit SHAs.

actions/checkout@v4 and gitleaks/gitleaks-action@v2 are 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

📥 Commits

Reviewing files that changed from the base of the PR and between 0e697e2 and 62c08ac.

📒 Files selected for processing (1)
  • .github/workflows/gitleaks.yml

Comment on lines +4 to +5
pull_request:
push:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/gitleaks.yml

Repository: 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_request from a fork, GitHub does not pass repository secrets to the runner (except GITHUB_TOKEN), and the GITHUB_TOKEN is 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_request runs from forks. [1], [2]
  • Main foot-gun: pull_request_target: Workflows triggered by pull_request_target run 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.

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.

1 participant