Skip to content

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

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 #137

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
Copy Markdown

@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:

# Read the gitleaks workflow file to understand its full structure
cat -n .github/workflows/gitleaks.yml

Repository: 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_request from forks run with a read-only GITHUB_TOKEN and 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_target runs 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:

    1. Run CI/tests on pull_request without secrets.
    2. Do privileged steps (publish/deploy/comment with elevated perms) in a separate workflow triggered by trusted events (e.g., push to main, or a carefully designed workflow_run), so secrets are never exposed to untrusted PR code. [4], [6]

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:

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.

branches:
- main

jobs:
gitleaks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: gitleaks/gitleaks-action@v2
Comment on lines +13 to +16
Copy link
Copy Markdown

@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/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 like v1). 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:

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.

env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}