Development record
2026-07-24 — itd-28 gitleaks sign-off: Stage 2 runs through the scanner
decisiondcn-2607240000000004
2026-07-24 — itd-28 gitleaks sign-off: Stage 2 runs through the scanner seam — native patterns are the default engine, gitleaks is the stronger opt-in adapter when the binary is present, and the hook reports which engine ran (loud staging). CI's gitleaks pass stays the authoritative backstop; iss-96 pattern parity folds into the spec. No new hard dependency — adr-22 holds. Rejected: gitleaks as hard local dependency (first adr-22 exception, per-machine install burden); CI-only Stage 2 (secrets reach pushed remote history before CI sees them).
Frontmatter
| id | dcn-2607240000000004 |
|---|---|
| type | decision |
| date | 2026-07-24 |
.abcd/work/decisions/dcn-2607240000000004-itd-28-gitleaks-sign-off-stage-2-runs.md
open on GitHub ↗ · commit history ↗
mentions4
- adr-22Bundled dependencies become pluggable adapters over a native default
- iss-96Now that transcripts are captured automatically on every session end, the scanner's secret-pattern coverage becomes load-bearing in a way it was not when capture was a manual verb nobody ran. Verified by live test: the bundled patterns DO catch anchored tokens (AKIA... access key IDs, ghp_/gho_/sk-ant- style prefixes) and absolute home paths, but they do NOT catch unanchored high-entropy values — an AWS SECRET access key (the 40-char base64 value, no prefix), a bare password, or a generic API token with no recognisable prefix all pass through into the store verbatim. This is the standard prefix-matching limitation and is pre-existing, not a regression; the point is that the blast radius changed. Consider entropy-based detection or the opt-in gitleaks adapter for the transcript path specifically, where the input is unstructured prose rather than curated source.
- itd-28Spec-Tied Reviews Live Next To The Spec They Reviewed
- itd-65abcd Refuses To Publish A Payload Until The Full Ship-Time Pre-Flight Gate Suite Passes, Not Just The Secret Scan