ASM vs. a pile of scanner output: why correlation is the product

Most teams that “do attack surface management” are really running a handful of excellent open-source scanners on a schedule. subfinder enumerates subdomains, naabu finds open ports, httpx probes services, nuclei fires templates. Each one is best-in-class at its job. And at the end of the week you have four piles of output that don’t talk to each other.

That’s not attack surface management. That’s homework.

The scan is the easy part

Here’s the uncomfortable truth: nobody needs Nmap rewritten. The engines are solved problems, maintained by people who are very good at it. The hard, valuable, unglamorous work is everything that happens after the scan finishes:

De-duplication. The same weak TLS configuration shows up in tlsx, in nuclei, and in your httpx notes. Three tools, one problem. If your “findings” list has three rows for it, every triage decision gets made three times.
Correlation to assets. “Port 8080 open” and “admin panel exposed” and “end-of-life nginx” are not three findings — they’re one host telling you a story. You want to ask “what’s wrong with api.example.com?” and get an answer, not run three greps.
Normalization. Each engine rates severity its own way. Without a common scale, you can’t sort, you can’t threshold alerts, and you can’t tell your boss how bad things actually are.
State over time. A finding you triaged as accepted-risk last month should not reappear as “new” this month. A finding you remediated that comes back should be screaming at you. That requires memory.

Do that work well and the pile of output becomes a short, ranked list of things that are actually true about your perimeter right now. That list is the product. The scan was just the raw material.

“What changed since last run” is the feature people open

Continuous scanning produces a firehose. The signal in that firehose is the delta: what’s new, what regressed, what got fixed, what assets appeared that nobody told you about.

A good weekly report doesn’t say “here are your 240 findings.” It says:

2 new (1 critical), 1 regressed, 3 remediated, 1 new asset discovered.

That’s a report a security lead reads in thirty seconds and a report an executive can be handed without a translation layer. The 240-row export still exists for the person who needs to go deep — but the diff is what drives the weekly rhythm.

Correlation is also what makes scanning safe

There’s a second reason the layer around the engines matters: control. A raw scanner will happily point at whatever you give it. A real ASM platform knows which assets are yours (ownership-verified), what you’re authorized to do to them (signed rules of engagement), and refuses everything else — at the API, at the dispatcher, and at the worker. The same correlation model that de-duplicates findings is what ties every packet back to a scope you proved you own and signed off on.

What to look for

If you’re evaluating tools — or deciding whether to keep gluing scripts together — ask how the tool handles the after:

Does it collapse the same issue across engines into one finding with history?
Can it answer “everything wrong with this host,” and “when did this first appear”?
Does it give me a readable diff every run, not just a dump?
Can a non-specialist run it without accidentally scanning something they shouldn’t?

If the answer to those is yes, you have attack surface management. If it’s “well, it runs the scanners,” you have a cron job.

That gap — between running the engines and making their output mean something — is exactly where ProbeIQ lives.