Deduplication
Run three scanners over one codebase and the same weakness arrives three times in three dialects. Sinterly merges them using a three-tier confidence model: automation where it is safe, human judgement where it is not.
The four matching criteria
Every comparison looks at the same four things: the asset identifier, the weakness class (CWE), the affected file or endpoint, and the vulnerability class.
The three tiers
| Tier | Condition | What happens |
|---|---|---|
| 1 | All four criteria match | Merged automatically. The matching criteria are recorded and an AppSec Lead can reverse it. |
| 2 | Three of four match, or the same CVE appears with location variance | Nothing merges. The findings stay separate with a pending indicator until an AppSec Lead confirms or rejects in the dedup queue. |
| 3 | Two of four match | Both records are marked as related. Nothing merges without a person deciding. |
Every decision, automatic or human, lands in the audit log with the criteria that drove it.
Why tier 2 waits for a person
A wrong merge hides a real finding behind an unrelated one, and it is very hard to notice afterwards. At three of four criteria the confidence is real but not sufficient, so the product asks rather than assumes. The queue is small in practice, because tier 1 handles the obvious cases.
Reviewing the queue
Open Dedup queue as an AppSec Lead. Each entry shows both findings and exactly which criteria matched. Approving merges them; rejecting keeps them separate and the pair is not offered again.
Primary findings
When findings merge, one is the primary and carries the score and any ticket. Reporting counts primaries only, so merged duplicates never inflate your totals.