Stop duplicate tickets by giving every finding a stable fingerprint, storing it on the ticket, and checking for an open ticket with that fingerprint before creating a new one. If it exists, update it. If it was closed and the finding returns, reopen it.
Why duplicates happen
A scanner runs daily or on every commit. Each run sees the same vulnerable package. An automation that only knows "a finding exists" files a ticket every time. Within a week, a team has seven copies of one problem and stops trusting the queue.
The fix is idempotence: running the same automation twice should leave the same result as running it once.
What goes into a fingerprint
A fingerprint is a short string built from fields that identify the problem and do not change between scans.
| Field | Include? | Reason |
|---|---|---|
| Advisory or CVE id | Yes | Names the flaw |
| Package name and ecosystem | Yes | Names the component |
| Repository and manifest path | Yes | Names where it lives |
| Installed version | Usually no | Changes when someone upgrades, and the finding should then close |
| Scan timestamp | No | Changes on every run |
| Severity score | No | Can be revised without being a new problem |
Hash the chosen fields together, or join them with a separator, and keep the result in a custom field or a ticket label.
Steps
- Define the fingerprint fields and write them down.
- Add a searchable field to the ticket for the fingerprint.
- On each scan result, search for an open ticket with that fingerprint.
- If found, add a comment only when something changed, such as a new fix version or a changed score. Do not comment on every run.
- If none is open but a closed one exists, check why it was closed. Fixed and regressed means reopen. Accepted risk means leave it closed until the acceptance expires.
- If nothing exists, create the ticket.
Handle the awkward cases
Two scanners can report the same flaw with different ids. Normalize on the advisory identifier where you can, and map aliases such as a CVE and a GitHub advisory to one key.
A race can create duplicates if two automation runs execute at the same moment. Use a lock, a unique constraint in your own store, or a single queue worker.
If you already have duplicates, merge them once, keep the oldest ticket, and link the rest to it.
Try it yourself
In the demo, watch how one vulnerable component appears across the dependency inventory. That single row is what your fingerprint should represent.
Click through it at your own pace, or open it full screen.
Quick check
Should the installed version be part of the fingerprint?
Usually not. When the version changes, the old finding should resolve. Keeping the version out lets the same ticket close on its own.
What should happen when a closed finding comes back?
Reopen it if it was fixed. If it was an accepted risk, leave it closed until the acceptance date passes.
Safeguard includes SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
