feat(security): add gitleaks secret scanning — this repo had none - #10
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 ✅ ApprovedAdds gitleaks secret scanning workflow using the estate's shared reusable action with proper inheritance and lockfile configuration. 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 |
|
|
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