Home / Knowledge hub / Finding deduplication
Knowledge hub
Finding deduplication
Merging reports of the same flaw so a team sees it once.
What it means
Finding deduplication is merging several reports of the same flaw into one record. The same missing check can be reported by two scanners, by a scan this week and last, and by a tester and a customer. Without merging, a team sees four tickets for one fix.
The harder part is deciding what counts as the same. One flaw in a shared function may appear on twenty endpoints. One endpoint may have two different flaws. A good merge follows the cause and not the surface, so a shared fix closes every copy.
Why it matters
Duplicates inflate the backlog, hide the real count and split the work. Two developers fix the same issue in parallel, or one ticket is closed while its twin stays open and keeps showing up in reports, which looks like a failed fix.
They also damage trust. A manager who sees 600 findings and learns that 150 are the same flaw stops believing the number. Metrics such as age and time to fix become unreliable if each recurrence starts a new clock, so the oldest and most important flaws look young.
How it shows up
Tools match on fields such as the weakness type (CWE), the location, the parameter and the affected component. Loose matching merges things that differ. Tight matching misses repeats when a URL changes slightly. Keep a link to every original so evidence is not lost, and treat a re-opened issue as the same record with its history.
Across tools, normalise first: map scanner-specific names to a CWE, strip session values from addresses, and group by the code location when the source is known. Review merged groups on a sample. Merging also lowers the rate of false alarms reaching developers, as long as the original proof stays attached.
Questions people ask
Finding deduplication, answered
What is the difference between deduplication and triage?
Deduplication merges repeats of the same flaw. Triage decides whether a finding is real and how urgent it is.
Both reduce the load, and they are usually done together.
How do tools decide two findings match?
Typically by weakness type, location, parameter and sometimes a fingerprint of the evidence. Rules differ, so results differ.
Check how your tool does it and test it on known repeats.
Can deduplication hide a real finding?
Yes, if it merges two different flaws that look alike. Keep the original evidence linked to the merged record, so a reviewer can split it again.
Sample the merges.
What about the same flaw across many endpoints?
If one root cause explains all of them, one record with a list of affected places is clearer and gets fixed once.
If there are separate causes, keep separate records.
Does it affect compliance reporting?
Auditors want an accurate picture. Merged records should still show every affected asset and the dates found and fixed.
Do not lose history in the merge, since the first-found date is what age targets depend on.
Sources
Where this comes from
Related
Terms that sit next to this one
Finding triage
Sorting new findings into fix now, fix later, duplicate or not real.
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
CWE
A catalogue of vulnerability types, rather than individual bugs.
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
False positive rate
How often a tool reports issues that turn out not to be real.
One flaw or four tickets?
Findings carry CWE and OWASP references and the request and response that proved them, so repeats are easy to recognise and group. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.