CONCERN-4 — Pin-bump cadence accountability for gitleaks
Post-merge follow-up from F-5 (#282) per Architect CONCERN-4 carry-forward (recurring maintenance).
Goal
Establish a tracked surface for gitleaks pin-bump cadence so the v8.30.1-pinned version in .pre-commit-config.yaml does not silently rot.
ADR-042 §Consequences documents the cadence policy:
Pin-bump cadence policy: bump on each gitleaks minor release with empirical re-verification — synthetic-fixture re-test per FR-013 (16-fixture rule-interaction matrix) before merging the bump.
This Issue gives that policy a recurring tracker.
Process
Each new gitleaks minor release (e.g., v8.31.0, v8.32.0, ...) opens a child Issue that:
- Updates
.pre-commit-config.yaml to the new minor release tag, then pre-commit autoupdate --freeze to pin the commit SHA
- Runs
bash tests/fixtures/gitleaks-rule-interaction/run.sh — must produce 16/16 (6 fire + 10 no-fire) PASS
- Runs
pre-commit run --all-files from a clean tachi clone — must produce zero findings (AC-4 / FR-002 baseline)
- If either verification fails, investigates rule-ID renames / regex shifts / allow-list interactions per spec §Five-Whys-on-deviation
- Updates
.gitleaks.toml rule-ID assertion comments in fixture headers (per PM-PLAN-1) if upstream renames
- Updates
docs/architecture/02_ADRs/ADR-042-* §References with the bump entry
- Updates
docs/standards/PRECOMMIT_HOOKS.md §Known-Limitations if the new release changes any guarantee
Tasks (Issue lifecycle)
Why now
The F-5 PRECOMMIT_HOOKS.md §Known-Limitations + ADR-042 §Consequences both name the cadence policy, but without a tracked Issue the policy becomes folklore. This Issue is the single source of truth referenced by future child bumps.
References
- ADR-042:
docs/architecture/02_ADRs/ADR-042-pre-commit-secret-scanning-default.md §Consequences
- Operator handbook:
docs/standards/PRECOMMIT_HOOKS.md §Known-Limitations
- Fixture matrix:
tests/fixtures/gitleaks-rule-interaction/run.sh
- Spec:
specs/282-pre-commit-secret-scanning-defaults/spec.md Architect CONCERN-4
Metadata
CONCERN-4 — Pin-bump cadence accountability for gitleaks
Post-merge follow-up from F-5 (#282) per Architect CONCERN-4 carry-forward (recurring maintenance).
Goal
Establish a tracked surface for gitleaks pin-bump cadence so the v8.30.1-pinned version in
.pre-commit-config.yamldoes not silently rot.ADR-042 §Consequences documents the cadence policy:
This Issue gives that policy a recurring tracker.
Process
Each new gitleaks minor release (e.g., v8.31.0, v8.32.0, ...) opens a child Issue that:
.pre-commit-config.yamlto the new minor release tag, thenpre-commit autoupdate --freezeto pin the commit SHAbash tests/fixtures/gitleaks-rule-interaction/run.sh— must produce 16/16 (6 fire + 10 no-fire) PASSpre-commit run --all-filesfrom a clean tachi clone — must produce zero findings (AC-4 / FR-002 baseline).gitleaks.tomlrule-ID assertion comments in fixture headers (per PM-PLAN-1) if upstream renamesdocs/architecture/02_ADRs/ADR-042-*§References with the bump entrydocs/standards/PRECOMMIT_HOOKS.md§Known-Limitations if the new release changes any guaranteeTasks (Issue lifecycle)
gh api repos/gitleaks/gitleaks/releases/latestcron or RSS)chore(deps): bump gitleaks vX.Y.Zwith this body referencedWhy now
The F-5 PRECOMMIT_HOOKS.md §Known-Limitations + ADR-042 §Consequences both name the cadence policy, but without a tracked Issue the policy becomes folklore. This Issue is the single source of truth referenced by future child bumps.
References
docs/architecture/02_ADRs/ADR-042-pre-commit-secret-scanning-default.md§Consequencesdocs/standards/PRECOMMIT_HOOKS.md§Known-Limitationstests/fixtures/gitleaks-rule-interaction/run.shspecs/282-pre-commit-secret-scanning-defaults/spec.mdArchitect CONCERN-4Metadata