Security Assessment Methodology: From Discovery to Report

Why methodology, not just tools

It’s possible to know every tool in a given assessment category and still run a disorganized assessment. Tools answer “how do I find this specific thing” — methodology answers “what order should I be looking for things in, and how do I know when I’m actually done.” Without the second question, an assessment tends to expand indefinitely in whatever direction is most interesting at the moment, rather than covering what it was actually scoped to cover.

The stages

Discovery

Establishing what actually exists — hosts, services, technologies. The goal here is coverage, not depth: you’re building the map before deciding where to dig.

Investigation

Working through what discovery produced. This is where raw output turns into an actual understanding of the environment — which services are running outdated software, which configurations look unusual, which findings deserve a closer look.

Validation

Confirming that a suspected issue is real before treating it as one. A scanner flagging something is a lead, not a finding — the validation step is what turns “this might be vulnerable” into “this is confirmed, here’s the evidence.”

Exploitation

Demonstrating actual impact, where authorized — proving a vulnerability is exploitable rather than theoretical. This stage carries the most risk and should carry the most deliberate confirmation process of any stage in the methodology.

Evidence

Capturing what was actually observed at every prior stage — not reconstructed afterward from memory. Evidence collected in the moment (a raw tool output, a screenshot, an HTTP transaction) is categorically more trustworthy than evidence written up after the fact.

Reporting

Turning everything above into something the recipient can actually act on — organized by severity, with enough context that a reader who wasn’t present for the assessment can understand what was found and why it matters.

Why it isn’t actually linear

Presented as a list, this looks like a pipeline. In practice it isn’t one. Investigation regularly sends you back to discovery (a finding on one host suggests checking a related one you hadn’t enumerated yet). Validation regularly fails and sends a lead back to investigation rather than forward to exploitation. Reporting often happens continuously throughout, not as a final step — documenting a finding the moment it’s confirmed is more reliable than trying to reconstruct the full assessment from notes afterward.

A methodology that assumes strict linear progression tends to produce tooling that fights the assessor every time reality doesn’t cooperate. The more useful framing is a set of stages that all read and write the same underlying context, rather than a pipeline you can only move forward through.

The role of context

The single biggest practical failure mode in a multi-tool assessment isn’t missing a vulnerability — it’s losing track of how findings relate to each other because each stage ran in a different tool with no shared state. A finding from a scanner, a manually verified detail, and a piece of evidence collected an hour later end up disconnected unless something is deliberately holding the relationship between them.

How Hollowpath approaches this

Hollowpath is built around exactly this non-linear reality rather than assuming it away. Discovery, investigation, validation, exploitation, and evidence collection all read and write the same underlying Asset/Service/Finding/Evidence objects through one engine — moving back to investigation after a new discovery doesn’t mean switching tools or losing context, because there was never a second, disconnected copy of the data to begin with.

Reporting reads directly from that same data at any point — see a real, generated example on the Sample Report page, and the full stage-by-stage breakdown on Product.