Update Best Practices badge to dynamic JSON

[kpj2006]

Addressed Issues:

Fixes #(issue number)

Screenshots/Recordings:

Additional Notes:

Checklist

• My code follows the project's code style and conventions
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have joined the Discord server and I will share a link to this PR with the project maintainers there
• I have read the Contributing Guidelines

⚠️ AI Notice - Important!

We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact.

Summary by CodeRabbit

• Documentation
  • Updated the OpenSSF Best Practices badge in the README to use a dynamic status endpoint that reflects current certification progress.
• Chores
  • Adjusted the Gitleaks scanning workflow to run with pull request target-branch context and ensured the license setting is correctly applied to the scan step.

[github-actions]

	Messages
📖	⚠️ PR Template Check These are non-blocking, but please fix: Please replace the placeholder Fixes #(issue number) with the actual issue number (e.g. Fixes #42). Some required checklist items are not completed: My PR addresses a single issue

Generated by 🚫 dangerJS against b4f31ff

[coderabbitai]

Walkthrough

The PR updates the "Best Practices" badge in README.md to use a Shields.io dynamic endpoint, and adjusts the gitleaks workflow to use pull_request_target as the trigger event with environment variable configuration for the license secret.

Badge URL Update

Layer / File(s)	Summary
Best Practices badge endpoint swap README.md	The <img> src for the "Best Practices" badge is replaced with a Shields.io dynamic/json URL that queries checklist-status.json and formats the value with a % suffix.

Gitleaks Workflow Security Configuration

Layer / File(s)	Summary
Workflow trigger and metadata .github/workflows/gitleaks-scanning.yml	Workflow name remains gitleaks; the pull request event trigger is changed from pull_request to pull_request_target to execute in the target-branch context.
License environment variable configuration .github/workflows/gitleaks-scanning.yml	The GITLEAKS_LICENSE secret environment variable placement is adjusted within the gitleaks action's env block.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested labels

Documentation

Poem

A badge now glows with dynamic JSON grace,
🐇 While gitleaks dances to pull_request_target's pace!
Secrets flow through environment blocks so tight,
The workflow takes flight with pull_request_target's might.
Security and badges dancing in the light! ✨

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: updating the Best Practices badge to use dynamic JSON format, which aligns with the primary modification shown in README.md.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with 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.

Inline comments:
In @.github/workflows/gitleaks-scanning.yml:
- 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.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ffa6d3ea-3cba-4c91-8efe-3b7c08eafe07

📥 Commits

Reviewing files that changed from the base of the PR and between 69f1f98 and b4f31ff.

📒 Files selected for processing (1)

• .github/workflows/gitleaks-scanning.yml

[coderabbitai]

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

• 1: https://github.com/gitleaks/gitleaks-action
• 2: https://github.com/marketplace/actions/gitleaks
• 3: Support running gitleaks-action on pull_request_target gitleaks/gitleaks-action#94
• 4: https://github.com/gitleaks/gitleaks-action/blob/master/README.md
• 5: https://deepwiki.com/gitleaks/gitleaks-action/3.2-gitleaks-integration-layer

---

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.