Every Scanner Speaks a Different Dialect

Security work doesn’t arrive in one tidy format. In the same week you’ll get a giant spreadsheet exported from a scanner, a batch of tickets a system auto-filed, and a hand-written penetration-test report as a PDF full of screenshots. They describe overlapping problems, but they’re structured completely differently — and, more importantly, they demand different responses. The instinct is to jump straight to fixing things. The actual first job is quieter and more important: normalize the formats into one shape, and classify what each finding even is before you touch it.

The same problem in three incompatible shapes

Each intake channel has its own structure, and you can’t parse or reason about them the same way:

• The scanner spreadsheet is rows and columns — dozens of them — with severity, CVE lists, affected hosts, and (if you’re lucky) a disposition column noting what’s already been accepted or ticketed. It’s dense, regular, and machine-readable if you know which columns matter.
• The auto-generated tickets are semi-structured text: a summary line with bracketed fields, a description with a few known headings, an attachment. Highly regular because a machine made them, so they parse well once you learn the template.
• The pentest PDF is prose and tables written by a human — an executive summary, severity ratings, numbered findings with recommendations, and evidence as screenshots that often won’t even extract as text. Rich, irregular, and hostile to automation.

Three formats, three parsers, three levels of structure. Treating them interchangeably is how you mangle the intake before you’ve even started triaging.

Normalize to one internal shape

The move that makes the rest tractable is an adapter per source that converts each format into one common internal representation — a finding is a finding, however it arrived. The spreadsheet extractor, the ticket parser, and the PDF reader are different on the outside and produce the same shape on the inside: what’s affected, how bad, what’s proposed, what’s already been decided. Once everything is normalized, triage, deduplication, and prioritization operate on one structure instead of three, and adding a new source later is just one more adapter, not a rewrite of your whole process.

The formats are the source’s problem. Your problem is turning all of them into the one shape your brain and your tooling actually reason about.

This is exactly the automate-the-gathering-not-the-judgment split: the parsing and normalizing is tedious, mechanical, and perfect for automation; what you do with the normalized findings is where human judgment stays.

Classify the “plane” before you propose a fix

Here’s the classification that matters most, and the one that’s easiest to get wrong: not every finding is yours to patch. Sorting findings by their remediation plane is the whole game:

• OS / infrastructure findings — an outdated package, a kernel CVE, a missing hardening control, a weak SSH cipher. These you can genuinely fix: patch, configure, harden. This is the plane people assume everything lives on.
• Application / vendor findings — missing API authentication, no rate limiting, improper input validation, a missing security header, an outdated app framework. These are code and config owned by an app team or a vendor. You do not “patch” them; you route them to whoever owns the application.

The expensive mistake is treating a route-it finding as a patch-it finding — trying to remediate at the infrastructure layer something that only the app owner can fix, or worse, “closing” it because you couldn’t. A pentest report in particular is mostly application-plane work with a few infrastructure items sprinkled in, and recognizing that split — this one’s mine, that one goes to the app team — is more than half the value of processing it at all. It’s the findings-without-owners-are-just-complaints lesson from the front: the first question about a finding isn’t “how do I fix it” but “whose is it.”

Lead with what’s already handled

One more thing the normalized data buys you: a lot of “findings” are already dispositioned — accepted as known risk, exceptioned, or ticketed weeks ago. The scanner exports often carry that status in the data itself. So the normalized view should surface “already handled” first and get it out of the way, so human attention goes to what’s genuinely new and genuinely actionable, not to re-litigating settled noise. That’s the same attention-preserving instinct behind treating vulnerability management as triage rather than a treadmill.

So before remediation, there’s intake — and intake is real engineering: an adapter per format that normalizes everything into one shape, and a classifier that sorts each finding by whether it’s yours to patch or someone else’s to fix. Get that layer right and the actual security work gets dramatically clearer, because you’re finally looking at one clean list of your actionable items instead of three incompatible piles of everyone’s. If you’ve built a security-intake pipeline that tamed the format chaos, I’d love to compare notes.