The Anatomy of a Noisy Scan

Open any vulnerability scanner against a real attack surface and you get the same thing: a wall of alerts. Hundreds of them. Most are duplicates, low-severity informational hits, or signature matches on services that were never reachable in the first place. The scanner did its job — it matched a checklist. The problem is that a checklist is not an assessment.

This is the first post on the Xseth blog, and it is a fitting place to start, because cutting through that noise is the entire reason Xseth exists.

What "noise" actually is

A scanner's output is noisy in three distinct ways, and it helps to keep them separate:

• Volume — every banner, every default page, every version string becomes a line item.
• Duplication — the apex domain and its www host resolve to one IP, so the same finding lands twice (or four times).
• Unverified inference — an open port 21 becomes "Anonymous FTP enabled" without anyone ever trying to log in.

That third category is the dangerous one. It is where a scanner crosses from reporting what it saw into asserting something it never confirmed. A report full of those assertions erodes trust fast — the first false positive a customer catches makes them doubt every finding above it.

A finding you cannot stand behind is worse than a finding you never made.

Triage is the missing step

Between "here is everything I matched" and "here is what you should fix first" sits a step most tools skip entirely: triage. That is the work of a security engineer reading the raw output, throwing out the noise, grouping the duplicates, and ranking what is left by what an attacker could actually do with it.

Xseth runs the same recon a human tester reaches for — subfinder, naabu, httpx, nmap — and then hands the output to a security-tuned model whose only job is that triage step. The model keeps a structured view of the target and reasons over how findings connect, rather than emitting each match in isolation.

Crucially, it is held to an evidence discipline. A finding inferred only from an open port is capped at low confidence and never written up as a confirmed condition. The titles stay honest:

OBSERVED:  Port 21/tcp open, banner "vsftpd 3.0.3"
INFERRED:  FTP service present (login behaviour not tested)
CONFIRMED: — (no probe run)

That last line matters. When Xseth says a finding is CONFIRMED, it means a non-destructive probe actually reached the issue and matched real evidence. It is reachability, not exploitability — proof the weakness is genuinely there, not proof we broke in. Everything else is shown, honestly, as unproven.

Why we lead with honesty

We would rather show you a shorter list you can trust than a longer one you have to second-guess. That is not a marketing line — it is an engineering constraint baked into the prompt, the validation layer, and the report template. You can read the full commitment on our editorial principles page.

The rest of this blog will go deeper: how the recon pipeline is wired, what the cognitive core reasons over, where the line sits between what ships today and what is on the roadmap, and plenty of general security writing for teams who are not living in this stack every day.

Welcome. We are glad you are here.