Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sklarsa wants to merge 1 commit into
base: main
Choose a base branch
from
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions .github/workflows/gitleaks.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
name: Gitleaks

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

@coderabbitai coderabbitai bot Mar 10, 2026

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.

branches:
- main

jobs:
gitleaks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}