Skip to content

fix(ci/secret-scan): strip line_number drift from detect-secrets baseline diff #5694

Description

@houko

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinghas-prA pull request has been linked to this issue

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions