fix(sarif): make partialFingerprints a content hash (v0.6.1) - #89
Merged
Conversation
Release 0.6.1. `primaryLocationLineHash` is a key GitHub reserves and recomputes: it expects a hash of the offending content. We were sending `ruleId:file:line`, so every upload logged an inconsistent-fingerprint warning for every finding — 8 of them on the first real run against ralyodio/debtap. The line number in the value was the worse half. Adding an import at the top of a file re-fingerprinted every finding below it, and GitHub then treats those as new alerts: previously dismissed ones come back and review comments detach from the code they were written about. On a scanner that runs per pull request, that is most commits. Hash the rule, the file and the matched text instead, with whitespace normalised so reindentation is not a new finding. One finding stays one finding while it moves around the file. 105 tests, up from 100. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan158 finding(s) HIGH/CRITICAL: 14 | MEDIUM: 108 | LOW: 36
…and 108 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
This was referenced Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release 0.6.1.
The bug
primaryLocationLineHashis a key GitHub reserves and recomputes — it expects a hash of the offending content. We were sending a readable triple:primaryLocationLineHash: `${finding.ruleId}:${finding.file}:${Math.max(1, finding.line)}`The first real upload said so, once per finding:
Eight warnings, eight findings, on ralyodio/debtap#1.
Why it matters more than the warning
The line number was baked into the identity. Adding an import at the top of a file re-fingerprints every finding below it, and GitHub treats a changed fingerprint as a new alert — so:
On a scanner that runs per pull request, that is most commits. It is the kind of noise that gets a security check muted rather than fixed.
The fix
Hash the rule, the file and the matched text — not the position:
Whitespace is normalised first, so reindenting is not a new finding either. Two identical lines in one file collide onto one fingerprint, which is the right trade: they are the same defect, and the SARIF
locationsstill tell them apart.Verification
Five tests added: the value is a hash and leaks neither rule id nor line number; it survives the finding moving from line 23 to line 891; it survives reindentation; it still separates different rules, files and content; and it is the value that actually reaches the document.
105 tests pass, up from 100.
tsc --noEmitclean.