Symptom
secrets / detect-secrets scan is red on main (commits since e6de2cc5). The only structural diff against the committed baseline is a single audited false-positive whose line_number shifted by one:
"hashed_secret": "929b5531f933164784179610dc6d44c9e4fe5e28",
- "line_number": 1332
+ "line_number": 1333
The hashed_secret + filename are unchanged. This is line-shift noise, not a security signal.
Root cause
.github/workflows/secret-scan.yml's diff step strips generated_at and version from both sides of the baseline diff (added in #5691) but does not strip line_number. Any commit that adds a line above an audited false-positive bumps every downstream line_number and the workflow fails until someone regenerates .secrets.baseline.
That's the same treadmill #5691 broke for generated_at — every CI run had a fresh timestamp, every diff failed, every contributor had to refresh the baseline. Stripping generated_at made the workflow signal-only. line_number has the same problem: it carries no security information once the entry is audited (the hashed_secret is the identity), and it shifts on every unrelated edit.
Fix
Extend the jq filter on both sides of the diff to also strip line_number from every results[][] entry:
- <(jq 'del(.generated_at, .version)' .secrets.baseline.orig) \
- <(jq 'del(.generated_at, .version)' .secrets.baseline) \
+ <(jq 'del(.generated_at, .version, .results[][].line_number)' .secrets.baseline.orig) \
+ <(jq 'del(.generated_at, .version, .results[][].line_number)' .secrets.baseline) \
(Same edit at the second diff -u invocation that prints the human-readable diff.)
CI still catches: a new hashed_secret appearing, an audited entry vanishing from the baseline (revoked-but-not-removed-from-baseline mistakes), or a previously-audited entry moving to a different filename. It stops catching: pure line-number drift.
The committed .secrets.baseline itself will continue to record line numbers — that's still useful when a human audits a finding — they just won't be load-bearing for the CI gate.
CI evidence
Symptom
secrets / detect-secrets scanis red onmain(commits sincee6de2cc5). The only structural diff against the committed baseline is a single audited false-positive whoseline_numbershifted by one:The hashed_secret + filename are unchanged. This is line-shift noise, not a security signal.
Root cause
.github/workflows/secret-scan.yml's diff step stripsgenerated_atandversionfrom both sides of the baseline diff (added in #5691) but does not stripline_number. Any commit that adds a line above an audited false-positive bumps every downstreamline_numberand the workflow fails until someone regenerates.secrets.baseline.That's the same treadmill #5691 broke for
generated_at— every CI run had a fresh timestamp, every diff failed, every contributor had to refresh the baseline. Strippinggenerated_atmade the workflow signal-only.line_numberhas the same problem: it carries no security information once the entry is audited (thehashed_secretis the identity), and it shifts on every unrelated edit.Fix
Extend the jq filter on both sides of the diff to also strip
line_numberfrom everyresults[][]entry:(Same edit at the second
diff -uinvocation that prints the human-readable diff.)CI still catches: a new hashed_secret appearing, an audited entry vanishing from the baseline (revoked-but-not-removed-from-baseline mistakes), or a previously-audited entry moving to a different filename. It stops catching: pure line-number drift.
The committed
.secrets.baselineitself will continue to record line numbers — that's still useful when a human audits a finding — they just won't be load-bearing for the CI gate.CI evidence
detect-secrets scan)