feat(security): add gitleaks secret scanning — this repo had none - #24
Conversation
An estate-wide audit of secret-scanning coverage found this repository has no leak detection of any kind: no gitleaks, no trufflehog, nothing. Measured across all 424 repositories: 170 had gitleaks, 73 had gitleaks plus a leftover trufflehog step, 33 had trufflehog only, and 88 — this one among them — had nothing at all. Adds a caller of the estate's shared secret-scanner reusable, which runs gitleaks over the whole working tree with --no-git and exits non-zero on a finding, alongside its rust-secrets and shell-secrets jobs. Two details that would fail silently if left out: - `secrets: inherit` is REQUIRED. Without it the gitleaks action's inner secrets.GITHUB_TOKEN is empty and the scan degrades quietly — passing while checking less, which is the failure this campaign exists to remove. - Where an actions.lock exists it gains a hand-authored [] entry for this file. gh actions-lock SKIPS reusable-workflow callers, so without it the workflow is rejected as startup_failure with no log and no check run. Expect findings. A first run on a repository that has never been scanned may surface real secrets, and any it finds have been exposed for as long as they have been committed. Treat a red first run as information, not as a fault in this change — and rotate anything it names rather than only deleting it. The sweep re-verified from this checkout that no scanner already existed before writing, rather than trusting the audit that selected the repo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Note Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime. Code Review✅ ApprovedIntegrates the estate's shared gitleaks secret-scanning workflow with required secrets inheritance and action locking. No issues found.
OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Important Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more. Was this helpful? React with 👍 / 👎 | Gitar |
Uh oh!
There was an error while loading. Please reload this page.
An estate-wide audit of secret-scanning coverage found this repository has no leak detection of any kind — no gitleaks, no trufflehog, nothing.
Measured across all 424 repositories:
Adds a caller of the estate's shared secret-scanner reusable: gitleaks over the whole working tree with
--no-git, exiting non-zero on a finding, alongside itsrust-secretsandshell-secretsjobs.Two details that would fail silently if left out
secrets: inheritis required. Without it the gitleaks action's innersecrets.GITHUB_TOKENis empty and the scan degrades quietly — passing while checking less, which is the precise failure this campaign exists to remove.Where an
actions.lockexists it gains a hand-authored[]entry.gh actions-lockskips reusable-workflow callers, so without it the workflow is rejected asstartup_failurewith no log and no check run.Expect findings — and read them carefully
A first run on a repository that has never been scanned may surface real secrets, and anything it finds has been exposed for as long as it has been committed. Rotate what it names; deleting the line is not enough.
But expect false positives too, and do not widen the scanner to silence them. Test fixtures, spec vectors and security documentation are deliberately full of credential-shaped strings — one estate repo produced 12 findings, all of them fixtures and doc examples. The cure there was a narrow, path-anchored
.gitleaks.toml, verified by planting a real key to confirm the scanner still fired.The sweep re-verified from this checkout that no scanner already existed before writing, rather than trusting the audit that selected the repo.
Found during the 2026-08-05 estate CI/CD census.
🤖 Generated with Claude Code