Vulnerability Report Normalizer: One Format for Every Scanner

Security teams rarely use one scanner. A network scanner, a web application scanner, a dependency checker and a cloud configuration tool each produce reports in their own format, with their own field names, severity scales and identifiers. The same vulnerability can therefore appear four times under four names, while a genuinely new finding hides among duplicates. Comparing, counting or tracking findings across tools becomes guesswork, and teams waste time reconciling spreadsheets instead of fixing flaws. Normalization solves this by mapping every report into one consistent format, so that findings can be compared like with like.

The Vulnerability Report Normalizer converts pasted report entries from different scanners into a single schema: a common set of fields for identifier, title, severity, affected asset, description, and remediation, with severity mapped onto one scale. It works from report text you paste in; it does not scan systems or connect to scanners, and it needs no credentials. Never paste secrets, passwords, private keys, or sensitive internal details into it. Report entries should be generalised before pasting: replace internal hostnames with roles where possible, remove customer data, and never include credentials that a scanner may have recorded. Normalization needs the finding's structure, not your infrastructure's secrets.

Normalization starts with a schema decision: which fields every finding must have, regardless of source. A practical minimum includes a stable identifier, a title, a severity on a single scale, the affected asset or component, a description of the flaw, evidence or location, a remediation suggestion, and the source scanner. Optional fields can include exploitability notes, references, and discovery dates. The schema should be small enough that every scanner can populate it, because a schema demanding fields only one scanner provides will leave the rest blank and defeat the purpose. Agree the schema once, document it, and resist adding fields for single cases; extensions belong in a notes field, not in the core schema.

Mapping fields and aligning severities

Field mapping is where most normalization effort goes. One scanner calls a field "plugin ID", another calls it "rule", a third calls it "check", and all three mean the same thing: the identifier of the test that found the issue. Mapping these to a single "identifier" field is straightforward once, and then automatic forever, provided the mapping is recorded. Asset fields vary similarly: one tool reports a hostname, another an IP address, another a repository and file path. Normalization should preserve the original asset reference while adding a canonical asset label, such as a system role, so that findings about the same system group together even when tools describe it differently.

Severity alignment is harder, because scanners use different scales and different judgements. One tool's "high" may equal another's "medium" for the same flaw, because their scoring methods differ. Aligning severities means mapping each scanner's scale onto your single scale with a documented table, and, where scanners disagree about the same finding, recording both original severities alongside the normalised one rather than silently discarding one. That transparency matters when a team questions a ranking: the normalised severity is a judgement, and judgements should be traceable to their sources. Where possible, anchor severity to a standard framework your team already uses, so the normalised scale has meaning beyond the normalization itself.

Deduplication is the payoff. After normalization, findings can be matched across scanners by identifier, affected asset and flaw type, so that the same vulnerability reported by three tools becomes one tracked item with three sources, rather than three separate tickets. Deduplication rules need care: matching too loosely merges distinct findings, while matching too strictly leaves duplicates. Start with exact matches on identifier and asset, then review near-matches manually, and refine the rules from the mistakes you find. Record which findings were merged and why, because a future audit may ask whether a finding was fixed or merely merged out of sight. A merged finding is not a fixed finding, and the tracking system must keep that distinction visible.

Worked example: three scanners, one web server

Suppose a public web server is scanned by three tools. The network scanner reports a finding titled with its plugin name, severity high, on the server's address, describing an outdated TLS configuration. The web scanner reports a finding titled differently, severity medium, on the server's hostname, describing weak cipher suites. The configuration checker reports a finding titled differently again, severity high, on the server's role name, describing obsolete protocols. Three reports, three titles, three severity labels, three asset descriptions — and one underlying problem: the server's TLS settings are out of date.

Normalization maps all three entries to the common schema. Their identifiers differ, so the normalizer records each source identifier and groups the entries by asset and flaw type: the canonical asset is the web server's role, and the flaw type is TLS configuration. The normalised severity is set to high, with a note recording the web scanner's medium rating and the reason for the higher normalised value: the combined evidence shows obsolete protocols, not only weak suites. The three entries become one tracked item, owned by the server team, with a single remediation — update the TLS configuration to current guidance — and three sources listed as evidence. When the fix is applied, a re-scan from any of the three tools can close the single item, rather than three tickets closing at different times and leaving the team unsure whether the problem is truly gone.

The example also shows what normalization does not do: it does not fix the vulnerability, verify the fix, or decide priority. Those remain human and scanner tasks. Normalization's contribution is clarity: one list, one language, one count. A team that cannot count its findings cannot manage them, and a team that counts duplicates as separate findings overstates its problem while understating its progress, because fixing one flaw appears to close only a third of the problem.

Keeping normalised reports trustworthy

Trust in normalised data depends on process. Record the mapping rules and severity table where the team can find them, and update them when a scanner changes its format or a new tool is added. Validate normalised output before it enters tracking: check that required fields are populated, that severities fall on the expected scale, and that asset labels resolve to real systems. Reject or quarantine entries that fail validation rather than letting malformed data pollute the list, because a tracking list with unknown entries is worse than a shorter list that is accurate.

Also preserve the original reports. Normalization is a transformation, and transformations can lose detail or introduce errors, so the original scanner output should remain available for audit and for re-normalization if the schema changes. Keep originals and normalised data linked, so any normalised finding can be traced back to its source entries. Finally, review deduplication decisions periodically: sample merged findings and confirm they truly describe the same flaw, and sample unmerged findings for duplicates the rules missed. Normalization improves with this feedback, and a quarterly review of a sample keeps the rules honest.

For working with the structured data that normalization produces, the JSON Studio formats and inspects structured report data, and the JSON Schema Validator checks normalised output against your schema. For reading violation-style reports in a related domain, see CSP Report Analyzer Guide.

FAQs

Does normalization change a finding's severity? It maps severities onto one scale, which can change the label, but the original severity should be preserved alongside the normalised value so the mapping is transparent and reversible.

How many scanners can be normalised together? As many as your mapping covers. Start with the two or three tools you use most, prove the schema works, and add further tools one at a time, updating the mapping table for each.

Is a normalised report a substitute for the original? No. Keep originals for audit, detail and re-normalization. The normalised report is the working list for tracking and comparison; the originals are the evidence behind it.