Skip to content

Update Best Practices badge to dynamic JSON #4

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
kpj2006 wants to merge 2 commits into
base: main
Choose a base branch
from
+3 −3
Open

Update Best Practices badge to dynamic JSON #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
69f1f98
Update Best Practices badge to dynamic JSON
kpj2006 Jun 23, 2026
b4f31ff
Update gitleaks-scanning.yml
kpj2006 Jun 23, 2026
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
4 changes: 2 additions & 2 deletions .github/workflows/gitleaks-scanning.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
name: gitleaks
on:
pull_request:
pull_request_target:

@coderabbitai coderabbitai Bot Jun 23, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔒 Security & Privacy | 🟠 Major

🧩 Analysis chain

🌐 Web query:

gitleaks-action v3 pull_request_target supported commit scanning checkout ref behavior

💡 Result:

The gitleaks-action v3, like its predecessor v2, is primarily designed for the pull_request and push events [1][2]. There is no specialized support or specific behavior implemented for the pull_request_target event [3]. When using gitleaks-action within a GitHub Actions workflow, the action relies on the repository state established by the preceding actions/checkout step [1][2]. The behavior regarding commit scanning is as follows: 1. Checkout Requirement: To properly scan commits, you must use actions/checkout with fetch-depth: 0 [1][4]. This ensures the full git history is available for gitleaks to perform its analysis [1][2]. 2. Scan Scope: For pull_request events, gitleaks-action automatically calculates the commit range (typically using baseRef^..headRef) to scan only the changes introduced by the pull request [5]. 3. pull_request_target behavior: While you can technically configure a workflow to run on pull_request_target, the action does not have explicit logic to handle the nuances of that event type [3]. Users who previously requested support for pull_request_target determined that it was not necessary for typical secret scanning use cases [3]. If you choose to use pull_request_target, you must manually manage the checkout ref (e.g., using with: ref: ${{ github.event.pull_request.head.sha }} in actions/checkout) to ensure the runner is scanning the actual pull request code rather than the base branch, as the default behavior of pull_request_target is to check out the base branch of the pull request. Note that running security-sensitive actions on pull_request_target requires caution due to the elevated permissions associated with that event [3].

Citations:

Switching to pull_request_target breaks the scan and exposes secrets to fork PRs.

Two distinct problems with this trigger change, both confirmed by gitleaks-action v3 behavior:

  1. Scan will miss PR contents. gitleaks-action v3 does not have specialized support for pull_request_target and relies on the checkout step to establish the scanning scope. For pull_request, it automatically calculates the commit range (baseRef^..headRef). For pull_request_target, it defaults to scanning whatever ref is checked out—which is the base branch when actions/checkout has no explicit ref parameter (as here). Without manually setting ref: ${{ github.event.pull_request.head.sha }}, the PR head commits are never checked out locally, so gitleaks scans only base-branch code, defeating the purpose of PR secret scanning.

  2. Secrets now reachable from fork PRs. pull_request_target exposes repository secrets (GITLEAKS_LICENSE, write-scoped GITHUB_TOKEN at lines 18–19) to runs triggered from forks. While scanning a file does not execute untrusted code, the elevated permissions and secret availability create an unnecessary attack surface.

The gitleaks use case does not justify pull_request_target. Unlike danger.yml (which needs write permissions to post comments), gitleaks only needs to read the PR diff and requires no elevated permissions. Keep pull_request instead.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/gitleaks-scanning.yml at line 3, Change the workflow
trigger from pull_request_target back to pull_request. The pull_request_target
trigger causes gitleaks-action v3 to scan only the base branch instead of the PR
head commits (since no explicit ref parameter is provided to actions/checkout),
missing the actual PR contents that need to be scanned. Additionally,
pull_request_target unnecessarily exposes repository secrets like
GITLEAKS_LICENSE and the GITHUB_TOKEN to fork PRs. Since gitleaks only requires
read access to the PR diff and does not need elevated permissions, reverting to
the pull_request trigger solves both the incomplete scanning and the security
exposure issues.

@kpj2006 kpj2006 Jun 24, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

However, they are not exposed to contributors from forked PRs because the workflow only checks out the base repository code and does not execute untrusted code from the fork ig

@coderabbitai coderabbitai Bot Jun 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

@kpj2006, that point is partially correct—pull_request_target does use the base branch's workflow file, not the fork's version, so a fork contributor cannot modify the workflow file itself to exfiltrate secrets. That prevents one specific attack vector.

However, two issues still remain:

  1. Secrets ARE in the runner environment. Even though untrusted code isn't checked out and executed, GITLEAKS_LICENSE and the write-scoped GITHUB_TOKEN (which pull_request_target grants, unlike the read-only token under pull_request) are injected into every run triggered by a fork PR. If any maintainer later adds an innocent-looking ref: ${{ github.event.pull_request.head.sha }} to the checkout step—a very common pattern—the workflow would immediately execute fork code with those elevated credentials. Using pull_request eliminates this latent risk entirely, since it never grants secrets or write permissions to fork-triggered runs.

  2. The scan is broken regardless. This is the more direct, undisputed problem. Without an explicit ref: override in the actions/checkout step, pull_request_target checks out the base branch, not the PR head commits. gitleaks-action v3 will scan only base-branch code, so any secrets introduced in a PR go completely undetected. The sole purpose of having gitleaks on pull_request is to catch secrets in incoming changes—this configuration defeats that entirely.

Reverting to pull_request (as in the original file) fixes both issues cleanly, since that event: (a) always scans the PR head commits, and (b) runs with a read-only, secretless token for fork PRs.

push:
workflow_dispatch:
schedule:
Expand All @@ -16,4 +16,4 @@ jobs:
- uses: gitleaks/gitleaks-action@v3
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@
</a>
&nbsp;&nbsp;
<a href="./BestPracticesChecklist.md">
<img src="https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2F%7BAOSSIE-Org%7D%2F%7BPythonScripts%7D%2Fmain%2Fchecklist-status.json&logo=openssf" alt="Best Practices"/>
<img src="https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2FAOSSIE-Org%2FPythonScripts%2Fmain%2Fchecklist-status.json&query=%24.percent&label=Best%20Practices&suffix=%25&logo=openssf&color=brightgreen" alt="Best Practices"/>
</a>
&nbsp;&nbsp;
<a href="https://github.com/gitleaks/gitleaks">
Expand Down
Loading