Give every finding a stable identity, such as package, version, advisory, and service, and let one system hold the ticket. Run one policy across the IDE, the pull request, and the scheduled scan. Give each stage a different job so they do not all report the same thing.
Why duplicates appear
Scanning in more than one place is good practice. The side effect is that the same vulnerable dependency shows up in the editor, on the pull request, and in the nightly report. If each creates its own alert or ticket, people see three notices for one problem and start ignoring all of them.
Give each stage its own job
| Stage | Reports | Does not report |
|---|---|---|
| IDE | Hints for the author, never tickets | Anything for the backlog |
| Pull request | New findings introduced by the change | Existing findings |
| Scheduled scan | Existing findings and new advisories | Things already ticketed |
When each stage has a narrow job, overlap shrinks by design.
Use a stable finding identity
Duplicates collapse when two reports can be recognized as the same. A workable identity combines:
- The affected package or code location.
- The vulnerable version or rule identifier.
- The advisory identifier where one exists.
- The service or repository that carries it.
If your tools produce different identifiers for the same advisory, map them to a common one when you import results. Without this, deduplication is guesswork.
One source of truth for status
Pick a single place where a finding's status lives: open, fixed, excepted, or accepted. Other stages read that status. If the scheduled scan sees a finding already marked excepted with an unexpired waiver, it should not open a new ticket.
One policy everywhere
If the IDE uses one threshold, the pull request another, and the schedule a third, the same package can be a warning in one place and a blocker in another. Authors get confused, and security gets blamed. Keep the policy in one file or service and have every stage read it.
Close the loop on fixes
When a fix lands, the next scan should mark the finding resolved automatically. Manual closing is where stale tickets pile up. Track how many tickets are closed by the scanner versus by hand, and investigate if the manual share is large.
A short checklist
- Decide the job of each stage and write it down.
- Define the finding identity fields.
- Choose the system of record for status.
- Point all stages at one policy.
- Check weekly for tickets that duplicate each other.
Where Safeguard fits
Safeguard uses one set of policies across its extensions, CLI, and pull request gates, and its dependency scanning and SBOM data give a consistent view of what each service contains. Try a scan at https://gold.safeguard.sh/scan.
Quick check
Should the IDE create tickets?
No. IDE results are hints for the author. Tickets should come from shared stages with an owner.
How do I know duplicates are a problem?
Look for tickets with the same package and service, or for developers saying alerts are repeated. Either signal means identity or ownership needs work.
Last reviewed: 19 October 2026.
