fix(standards): rename GITLEAKS_SHA256→GITLEAKS_CHECKSUM, add .gitleaks.toml template#167
fix(standards): rename GITLEAKS_SHA256→GITLEAKS_CHECKSUM, add .gitleaks.toml template#167don-petry wants to merge 71 commits into
Conversation
…ire .gitleaks.toml
…note to secret-scan section
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a standardized gitleaks secret-scan: requires a repository-root ChangesGitleaks Secret-Scan Standardization
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer (repo)
participant CI as GitHub Actions Runner
participant GL as Gitleaks Binary
participant Script as push-protection.sh
participant Org as Org Secrets Store
Dev->>CI: Push/PR triggers workflow (.github/workflows/ci.yml)
CI->>Org: read GITLEAKS_CHECKSUM & GITLEAKS_LICENSE
CI->>GL: download gitleaks@GITLEAKS_VERSION
CI->>GL: verify tarball using GITLEAKS_CHECKSUM
CI->>GL: install and add to PATH
CI->>GL: run gitleaks detect --config .gitleaks.toml --redact --exit-code 1
GL-->>CI: report findings / exit code
CI->>Script: run audit check secret_scan_ci_job_present (pattern match)
Script-->>CI: pass/fail enforcement result
CI-->>Dev: report status with remediation guidance
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Pull request overview
Updates the security standards around gitleaks-based secret scanning by switching the canonical CI job from the gitleaks/gitleaks-action to a manual binary install pattern, standardizing the checksum env var name, and introducing a required .gitleaks.toml template to suppress known false positives (notably BMAD paths).
Changes:
- Replace the Layer 3 canonical
secret-scanjob to download/verify/install the gitleaks binary and rungitleaks detect --config .gitleaks.toml. - Add a canonical
standards/gitleaks.tomltemplate and document the repo-root.gitleaks.tomlrequirement. - Update CI standards docs to reflect
.gitleaks.tomlrequirements, failure modes, and onboarding checklist updates.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
standards/push-protection.md |
Updates the canonical secret-scan job and adds a .gitleaks.toml template section. |
standards/gitleaks.toml |
Adds a new template config intended to be copied to repo root as .gitleaks.toml. |
standards/ci-standards.md |
Documents the required .gitleaks.toml artifact, checksum env var naming, updates failure table, and onboarding checklist. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| wget -q "${url}" -O /tmp/gitleaks.tar.gz | ||
| echo "${GITLEAKS_CHECKSUM} /tmp/gitleaks.tar.gz" | sha256sum -c | ||
| tar -xzf /tmp/gitleaks.tar.gz -C /usr/local/bin gitleaks |
There was a problem hiding this comment.
The install step extracts gitleaks into /usr/local/bin without elevated permissions. On GitHub-hosted ubuntu-latest runners, /usr/local/bin is root-owned, so this will typically fail with permission denied and the job won’t reach the scan step. Install into a writable location (e.g., $RUNNER_TEMP/$HOME/.local/bin and add it to $GITHUB_PATH) or use sudo for the extract/install step.
| wget -q "${url}" -O /tmp/gitleaks.tar.gz | |
| echo "${GITLEAKS_CHECKSUM} /tmp/gitleaks.tar.gz" | sha256sum -c | |
| tar -xzf /tmp/gitleaks.tar.gz -C /usr/local/bin gitleaks | |
| install_dir="${RUNNER_TEMP}/gitleaks-bin" | |
| mkdir -p "${install_dir}" | |
| wget -q "${url}" -O /tmp/gitleaks.tar.gz | |
| echo "${GITLEAKS_CHECKSUM} /tmp/gitleaks.tar.gz" | sha256sum -c | |
| tar -xzf /tmp/gitleaks.tar.gz -C "${install_dir}" gitleaks | |
| chmod +x "${install_dir}/gitleaks" | |
| echo "${install_dir}" >> "${GITHUB_PATH}" |
| **Required repo artifact — `.gitleaks.toml`:** | ||
|
|
||
| Every repo using the `secret-scan` job MUST ship a `.gitleaks.toml` at the | ||
| repository root. The `Run gitleaks` step passes `--config .gitleaks.toml`; | ||
| without the file the job fails immediately with a file-not-found error. | ||
|
|
||
| Copy [`standards/gitleaks.toml`](gitleaks.toml) as a starting point and extend | ||
| the `paths` allowlist for any repo-specific false-positive paths. BMAD Method | ||
| repos **must** include `'''_bmad/'''` in the allowlist — the `generic-api-key` | ||
| rule fires on knowledge file paths such as `api-request.md` and | ||
| `auth-session.md`. | ||
|
|
There was a problem hiding this comment.
This new .gitleaks.toml requirement callout is good, but the surrounding section still describes the setup as “gitleaks action” and shows an env: snippet including GITHUB_TOKEN. Since push-protection.md now documents a manual binary install, consider updating this section to match (remove the action-specific wording/token, and show where GITLEAKS_LICENSE should be set for org repos) to avoid adopters copy/pasting conflicting instructions.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@standards/ci-standards.md`:
- Line 302: Update the guidance for the "Secrets found" table entry to stop
implying allowlisting is an acceptable default: change the cell that currently
reads "Legitimate secrets in the code | Add the path to `.gitleaks.toml`
`allowlist.paths`, or remove the secret" to instruct that real secrets must be
removed and rotated, and that adding paths to `.gitleaks.toml` `allowlist.paths`
is only allowed for confirmed false positives after documented justification and
approval; reference the "Secrets found" table header and the `.gitleaks.toml`
`allowlist.paths` symbol when making the change so reviewers can locate and
tighten the remediation text accordingly.
In `@standards/push-protection.md`:
- Around line 258-282: The document currently conflicts on which gitleaks
artifact to use: it mandates `.gitleaks.toml` in the “.gitleaks.toml template”
section but still instructs using `.gitleaksignore` in the “Writing tests and
fixtures” section; update the “Writing tests and fixtures” text to reference
`.gitleaks.toml` (and any example commands or file names there) so all guidance
consistently uses `.gitleaks.toml` and remove or replace any mention of
`.gitleaksignore`.
- Around line 227-241: Update the audit function secret_scan_ci_job_present in
scripts/lib/push-protection.sh (current logic at ~180-206 and similar check at
~250-255) so it no longer only greps for "uses: gitleaks/.*-action" but also
recognizes the new canonical job pattern by looking for the job name "name:
Install gitleaks" combined with the CLI invocation "gitleaks detect --config
.gitleaks.toml" (or the presence of both the install step and the detect
command); also update the compliance table description string that refers to the
old action to mention the new standard (Install gitleaks + gitleaks detect
--config .gitleaks.toml) so compliant repos are correctly classified.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 94305ad7-e024-461f-97cf-4874528512bd
📒 Files selected for processing (3)
standards/ci-standards.mdstandards/gitleaks.tomlstandards/push-protection.md
There was a problem hiding this comment.
♻️ Duplicate comments (1)
standards/ci-standards.md (1)
302-302:⚠️ Potential issue | 🟠 Major | ⚡ Quick winTighten secret-remediation guidance to avoid allowlisting real leaks.
Line 302 currently implies allowlisting is acceptable for any "Secrets found" failure. This weakens incident response: real secrets should be removed/rotated, and allowlist should be limited to confirmed false positives.
The guidance should clarify that adding paths to
.gitleaks.tomlallowlist.pathsis only permitted for verified false positives after proper review, while actual secrets must always be removed and rotated immediately.🔒 Suggested documentation fix
-| Secrets found | Legitimate secrets in the code | Add the path to `.gitleaks.toml` `allowlist.paths`, or remove the secret | +| Secrets found | Secret detection triggered | Remove and rotate the secret immediately; use `.gitleaks.toml` `allowlist.paths` only for confirmed false positives |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@standards/ci-standards.md` at line 302, Update the guidance for the "Secrets found" row so it no longer implies blanket allowlisting: specify that adding paths to `.gitleaks.toml` `allowlist.paths` is only allowed for verified false positives after a documented review/approval, and that any actual secrets discovered must be removed and rotated immediately; reference `.gitleaks.toml` and `allowlist.paths` explicitly and add a short required checklist (verify false positive, obtain approval, document decision) to accompany any allowlist entry.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@standards/ci-standards.md`:
- Line 302: Update the guidance for the "Secrets found" row so it no longer
implies blanket allowlisting: specify that adding paths to `.gitleaks.toml`
`allowlist.paths` is only allowed for verified false positives after a
documented review/approval, and that any actual secrets discovered must be
removed and rotated immediately; reference `.gitleaks.toml` and
`allowlist.paths` explicitly and add a short required checklist (verify false
positive, obtain approval, document decision) to accompany any allowlist entry.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 57784b43-e376-4a35-b6e6-81879df5f308
📒 Files selected for processing (1)
standards/ci-standards.md
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
@dev-lead - please fix this PR |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with dev-lead will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
Summary
standards/push-protection.md— Replaces thegitleaks/gitleaks-actionbased canonical job (Layer 3) with the manual-install pattern usingGITLEAKS_CHECKSUM(notGITLEAKS_SHA256). Adds a new### .gitleaks.toml templatesubsection explaining why the config file is required and what to put in it. Drops the now-unusedsecurity-events: writepermission from the job.standards/gitleaks.toml— New canonical template. Copy to repo root; extendallowlist.pathsfor repo-specific false positives. Ships with'''_bmad/'''pre-populated.standards/ci-standards.md— Adds a "Required repo artifact" callout under §4 Secret Scanning explaining the.gitleaks.tomlrequirement and theGITLEAKS_CHECKSUMnaming rule. Updates the CI failure table (addsconfig file not foundrow, fixes the.gitleaksignore→.gitleaks.tomlreference). Adds step 3 to the "Applying CI to a New Repository" checklist.Why these changes
GITLEAKS_CHECKSUMnotGITLEAKS_SHA256: SonarCloud's security gate flags env var names matching*SHA256*that contain hex strings as Security Hotspots (hardcoded credential false positive). Renaming toGITLEAKS_CHECKSUMsuppresses the false positive without any functional change —sha256sum -creads the value regardless of the variable name.Required
.gitleaks.toml: Thegeneric-api-keyrule in gitleaks fires on BMAD knowledge file paths (e.g.api-request.md,auth-session.mdin_bmad/directories) because their names contain substrings gitleaks treats as API-key indicators. Every adopting repo needs a config file that allowlists these paths;--config .gitleaks.tomlis now part of the canonical Run step so omitting the file is a hard failure rather than a silent miss.Test plan
push-protection.mdLayer 3 canonical job YAML is well-formed (correct step indentation, no stray nesting)standards/gitleaks.tomlis valid TOML (tomlq . standards/gitleaks.tomlor equivalent)standards/gitleaks.toml→.gitleaks.toml, add thesecret-scanjob withGITLEAKS_CHECKSUM, confirm SonarCloud reports no Security Hotspot for the env vargitleaks detect --config .gitleaks.tomldoes not fire on_bmad/path fixtures🤖 Generated with Claude Code
Summary by CodeRabbit