ci: server-side secret scan on every push and pull request - #5804
Conversation
… gitleaks hook only guards commits a human types; commits created by tooling and pushed by other plumbing bypass it entirely, which is how four conflicted commits carrying full tree copies reached a release branch unscanned. This job scans the pushed range server-side with the repo's existing .gitleaks.toml, so origin does not matter.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dosubot
Bot
added
size:XS
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
…write deliberate high-entropy marker strings (QA-CWD-*, QA-APPROVE-*) into committed run records to prove storage round trips; the new server-side scan's first branch run flagged three of them as generic API keys. Test artifacts, not credentials; verified by reproducing the scan and reading each finding.
1 participant
Context
The repo runs gitleaks only in local hooks (husky pre-commit and pre-push). Those guard commits a human types. Commits created by tooling and pushed by other plumbing bypass them entirely: that is how four conflicted commits carrying ~50k-file tree copies reached the release branch unscanned this week, found first by a coworker's manual scan. The trees contained no real secrets (verified with gitleaks itself), but nothing in the pipeline would have caught it if they had.
Changes
One workflow: on every push and every pull request, install gitleaks and scan exactly the pushed or proposed commit range with the repo's existing
.gitleaks.toml. The server sees every commit regardless of what created it, which closes the bypass class. New branches scan their whole history relative to the default branch, so nothing arrives unscanned.Tests
The workflow runs on this PR itself as its first execution. The scan range logic covers the three event shapes (PR, push to existing branch, push of a new branch).