To deduplicate SAST and DAST findings, normalise both to a weakness ID such as a CWE, link the DAST URL and parameter to the code handler SAST flagged, and merge matches into one ticket. Keep both pieces of evidence on it, because each proves something different.
Why duplicates appear
SAST sees code and reports a file and line. DAST sees a running application and reports a URL and parameter. If both find a SQL injection in the same search handler, you get two tickets in two queues. Developers fix one, close it, and the other lingers. Worse, two counts make the problem look bigger than it is.
A common vocabulary
CWE helps here. MITRE describes it as a list of software and hardware weaknesses and a common language for describing them, and as a standard reference mechanism for security tools. Many scanners tag findings with a CWE ID, which gives you a shared key. Note MITRE's own caution that a static analysis tool can find issues in code but not in design, architecture or implementation, so a CWE match is a clue to investigate, not proof of identity.
Matching recipe
| Signal | SAST side | DAST side |
|---|---|---|
| Weakness | CWE ID | CWE ID |
| Location | File and function | URL path and parameter |
| Bridge | Route definition in that function | Route that the URL resolves to |
| Evidence | Data flow from source to sink | Request, payload and response |
- Normalise weakness IDs. Map near neighbours, for example specific injection variants, to a parent where your policy treats them alike.
- Resolve the DAST URL to a route, and the route to a handler in the code. Frameworks list routes, so this is often a lookup.
- Compare the handler to the SAST finding's function. If the weakness family and handler agree, link them.
- Create one parent ticket. Attach both findings as evidence.
- Close the parent only after a re-scan from both tools shows the flaw gone.
What the pair tells you
When both tools agree, confidence is high: SAST found the code path and DAST showed it can be reached from outside. That is a strong signal to prioritise. When only SAST reports it, ask whether the path is reachable. When only DAST reports it, find the code, because the fix lives there. For how the tools complement each other, see what SAST, DAST and IAST each find.
Try it yourself
Open the demo and notice how reachability changes which findings deserve attention first.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers reachability analysis and policies to help prioritise findings. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is the same CWE enough to call two findings duplicates?
No. Check that the location also agrees. The same weakness can exist in many places.
Should I merge findings from different severities?
Yes, but keep the higher severity on the parent and record why the ratings differed.
Sources
Last reviewed: 19 October 2026.
