Scanner Finding Deduplicator
Run SAST, DAST and SCA together and the same flaw shows up three times under three names — inflating the backlog and hiding how many distinct issues you really have. Paste your raw findings and this tool groups them by a normalized component + rule/CWE key, collapses the duplicates across tools, and gives you counts, the reporting tools per finding, and a cleaned deduped list. All in your browser.
One finding per line. Either simple CSV tool,rule,component,severity or free text (a CWE-nnn in the text is used to match across scanners). Lines starting with # are ignored.
How de-duplication works here
Findings are grouped by a normalized key of component + rule. When a line contains a CWE id, the CWE is used as the rule key so the same weakness named differently by two scanners (e.g. "SQL Injection" and "SQLi CWE-89") still collapses. Severity shown is the highest reported across tools; the count and tool chips tell you how many scanners flagged it. All matching is plain, deterministic string normalization in your browser — no uploads, no scanning.
What this tool is
- A free, in-browser deduplicator for scanner findings: paste raw findings from several tools (one per line, or simple CSV tool,rule,component,severity) and it groups, normalizes and collapses the duplicates.
- Findings are grouped by a normalized component + rule/CWE key, so the same flaw named differently by SAST, DAST and SCA (e.g. "SQL Injection" vs "SQLi CWE-89") merges into a single row.
- Each deduped row shows how many times it was reported, which tools reported it, and the highest severity seen — plus a cleaned, exportable list.
- Pure deterministic string normalization in the browser: no uploads, no network calls, no scanning and no secrets.
- De-duping matters because one flaw reported by three scanners is three tickets of noise — inflating the backlog and hiding the real count of distinct issues.
Why this matters
A vulnerability program lives or dies on signal-to-noise. When a single SQL-injection sink is reported by a static analyzer, a dynamic scanner and a dependency tool — each with its own wording — a naive pipeline creates three tickets, triples the apparent backlog, and trains engineers to ignore the queue. Deduplication restores an honest count: one weakness, one row, with visibility into which tools agree on it (multiple tools flagging the same issue is itself a strong confidence signal).
Matching on a normalized component + CWE key is the pragmatic approach used by aggregation platforms like DefectDojo: the CWE gives a tool-independent identity for the weakness, and the component anchors it to a location. This tool is a quick, private way to apply that same logic to a one-off export before you import it anywhere — no server, no account, nothing leaves the browser.
Frequently asked questions
Why do I need to deduplicate scanner findings?
Modern application security stacks run several scanners at once — SAST (static analysis), DAST (dynamic/runtime), SCA (software composition / dependencies), secret scanners and IaC scanners. The same underlying weakness is routinely reported by more than one of them under different names, and often many times across scans. Without de-duplication the backlog is inflated, the same issue generates duplicate tickets, metrics are wrong, and engineers lose trust in the program. Collapsing duplicates to a single canonical finding is one of the core jobs of an ASPM / vulnerability-management workflow (and tools like DefectDojo do exactly this).
How does the deduplication key work?
Each finding is reduced to a normalized key of component + rule. The component (file path, package, host) and the rule name are lowercased, stripped of punctuation and whitespace-collapsed. When a line contains a CWE identifier (for example CWE-89), the CWE is used as the rule part of the key — this is what lets two scanners that describe the same weakness with different wording still merge. Findings sharing a key are collapsed into one group, with a count, the set of reporting tools, and the highest severity observed.
What format should I paste?
One finding per line. The simplest input is CSV: tool,rule,component,severity — for example "snyk,SQLi (CWE-89),api/users.js,high". You can also paste free-text findings; if a line contains a CWE id it will still be used for matching, otherwise the whole line is treated as the rule label and matched on normalized text. Lines starting with # are ignored, so you can keep a header or comments. Load the sample data to see a realistic multi-scanner list.
Does anything leave my browser?
No. This is a 100% client-side tool. The normalization and grouping run in JavaScript in your browser on the text you paste. There is no server round-trip, no scanning of your systems, no storage and no secrets involved. It is a defensive, educational helper for triaging findings you already have — export the cleaned list and import it into your own tracker.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.Educational — general guidance, not security advice.