A scanner knows a finding is the same as last week's by computing a fingerprint from stable fields, such as component, advisory and location, then comparing it with the previous run. Matching fingerprints mean the same finding; a new one is labelled new, and a missing one is absent. Unstable fingerprints cause duplicate alerts.
Why identity matters
Without identity, every scan produces a fresh list. You could not say which findings are new, which you fixed, or how long one has been open. Trends, service targets and accepted risks all depend on recognising the same finding across runs.
What goes into the fingerprint
For a dependency finding, sensible ingredients are:
- the package identifier (ecosystem and name)
- the advisory ID, or a canonical form of it
- the project or repository
- the manifest or lockfile path
Notice what is left out: the version, the scan time, and any line number that shifts. If the version were in the fingerprint, upgrading from one vulnerable version to another would look like a fix plus a new finding, when really the issue is still open.
For code findings the choice is harder, because code moves. The SARIF standard addresses this directly. A result can carry partialFingerprints, each a string that contributes to the result's stable, unique identity. Property names are versioned, and the spec says that when two results are compared, the latest version available in both should be used. That lets a tool improve its fingerprint method without breaking history.
The four states relative to a baseline
SARIF defines a baselineState for each result, relative to a baseline run:
| State | Meaning |
|---|---|
| new | Seen now, not in the baseline |
| unchanged | Seen in both, no significant change |
| updated | Seen in both, changed in a way the tool considers significant |
| absent | Seen in the baseline, not seen now |
Even if your tool does not use SARIF, these four states are a good model for a findings database. "Absent" is the closest thing to automatic closure, though it deserves verification, as covered in verifying a fix closed a finding.
What breaks identity
- Renames and moves. A file path changes, and the finding looks new.
- Aliases. The same issue arrives under a different ID from another database.
- Line numbers. Fingerprints that include them churn on every edit above the finding.
- Tool upgrades. A new matcher may identify components differently.
The symptom is a burst of "new" findings that look familiar. If that happens after a tool or process change, suspect identity first, not a sudden loss of security.
How to test it
Run the same scan twice on an unchanged project. Everything should be unchanged. Then rename a directory and scan again, and see what the tool does. Then upgrade a vulnerable package to another vulnerable version and confirm the finding stays one finding.
Where Safeguard fits
Safeguard's vulnerability management tracks findings over time alongside its dependency scanning and policies. Run the free scan twice and compare what is reported as new.
Quick check
Why not include the line number in a fingerprint?
Edits above the finding shift line numbers, so the same issue would look new after every change. Stable fields work better.
Does absent always mean fixed?
No. It can also mean the scan did not cover that path this time. Verify before closing.
Sources
Last reviewed: 19 October 2026.
