Vulnerability Report Normalizer

Import scanner output as CSV or JSON, map the columns once, normalise the severities and deduplicate, so findings from different tools can finally be counted together.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

1 Add scanner reports
2 Confirm the field mapping
3 Review normalised findings

Drop one or more reports (CSV or JSON)

Trivy and Grype JSON are recognised automatically; anything else is mapped in step 2. Read in your browser.

Different scanners, one list

Every scanner reports findings its own way. One says "Critical", another "Very High", a third gives only a CVSS score. One calls the affected thing a host, another a target, a third an artifact. Counting findings across tools, or tracking them over time, first needs everything in one shape. This normaliser converts CSV and JSON reports into a single, documented finding schema, then removes exact duplicates. Each finding keeps the original record next to its normalised form.

Recognised formats, and everything else

Trivy JSON (schema version 2) and Grype JSON are recognised automatically. Their conversion is tested against output files published in each project's own repository, so that support is a claim with evidence behind it. Any other CSV or JSON goes through the mapping step. You see which column became which field and can change it, so no scanner's format is silently guessed. For JSON, the tool finds the list of records inside the document and flattens nested fields into names like asset.host.

Normalisation rules you can check

Severities map to critical, high, medium, low and info. Common vendor terms are recognised: "Important" becomes high, "Moderate" medium, "Negligible" info. A row with no severity takes the CVSS band of its score and is marked as derived. Statuses map to open, fixed, accepted and false positive. Anything unrecognised becomes "unknown", with the original value kept, never forced into a category.

Deduplication you can explain

Two findings are merged only when they have the same identifier, the same asset and the same component at the same version. Every merged finding lists the records it absorbed. Findings that share an identifier and asset but differ in component version are listed as near-duplicates and kept separate: they may be two installations, or one upgraded mid-scan, and only you can tell. Findings without an identifier are never merged.

The canonical schema

Exports use a2z.tools/vuln-finding/1.0. Each finding has: a stable key, title, identifier, aliases, asset, component (name, version, purl), severity (with the original value and whether it was derived), CVSS, status, fix version and state, remediation, evidence, dates, a source reference (tool, format and exact record path) and the original record. CSV exports neutralise spreadsheet formulas, so a hostile finding title cannot execute in Excel.

Frequently asked questions

Why is my scanner not "supported"?

Named support is only claimed where we have tested real output from that scanner. The mapping step handles any CSV or JSON, and you stay in control of how columns are read.

Are my scan results uploaded?

No. Reports are parsed in your browser. Scan results describe exactly where your systems are weak; they should not be posted anywhere to be reformatted.

What should I do next with the normalised list?

Rank it in the Vulnerability Prioritization Calculator, or look up exploitation signals with KEV and EPSS.

References

Trivy and Grype (reference outputs, Apache-2.0)
FIRST CVSS qualitative severity ratings

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.