Attack Surface Management: A Practical Definition

What it is

“Attack surface management” gets used loosely enough that it’s worth pinning down. It is not a scan you run once. It’s the ongoing practice of knowing what you actually have exposed to the internet (or to an internal network segment), and noticing when that changes.

The distinction matters because most organizations don’t have an accurate picture of their own exposure. A subdomain gets spun up for a marketing campaign and never torn down. A developer stands up a staging environment on a cloud provider outside the normal provisioning process. An acquisition brings in infrastructure nobody has inventoried yet. None of these show up in an asset list that was accurate six months ago. Attack surface management is the discipline of catching them anyway.

Why it has to be continuous

A point-in-time scan answers “what does our exposure look like right now.” That’s useful, but it decays immediately — DNS records change, new services get deployed, certificates get issued for hosts nobody flagged. An organization of any real size has infrastructure churn happening constantly, usually faster than any manual inventory process can track it.

This is why attack surface management is treated as a process with a cadence, not a deliverable. The useful question isn’t “what’s our attack surface” — it’s “what changed since we last looked, and does that change matter.”

The components

Discovery

Finding what actually exists — subdomains, IP ranges, cloud assets, exposed services. This is where tools like passive DNS aggregation, certificate transparency log monitoring, and active subdomain brute-forcing earn their keep. Discovery is necessarily imperfect: passive sources find what’s been seen publicly, active enumeration finds what responds to a direct probe, and neither finds everything on its own.

Fingerprinting

Once something is discovered, the next question is what it actually is — web server, version, framework, exposed admin panel, TLS configuration. This is the difference between “we have 40 subdomains” and “we have 40 subdomains, three of which are running an end-of-life CMS version.”

Change detection

The genuinely valuable part, and the part a one-time scan structurally cannot provide. A new subdomain appearing, a service that used to require authentication no longer requiring it, a certificate reissued for a host that shouldn’t exist — these are the events that actually warrant attention, and they only show up if you’re comparing against a baseline.

Prioritization

Not every exposed asset is equally urgent. An internal-only admin panel that’s accidentally internet-facing is a different kind of problem than a marketing microsite running an outdated jQuery version. Attack surface management without prioritization just produces a longer list nobody acts on.

Common mistakes

• Treating discovery as complete. No single technique — passive or active — finds everything. Coverage gaps are the default state, not an edge case.
• Conflating “discovered” with “in scope.” Finding something during automated discovery does not mean it’s authorized to act on. This distinction matters enough that it’s worth encoding directly into tooling rather than relying on a human to remember it every time — more on that below.
• No baseline to diff against. Without a stored prior state, every scan is a fresh inventory instead of a change report, and the signal that actually matters (what’s new) gets buried in what’s already known.

How Hollowpath approaches this

Hollowpath’s external mode runs a defined discovery chain — subdomain and asset discovery, live-host confirmation, port scanning, web crawling, and template-based detection — and normalizes what it finds into a consistent Asset/Service model rather than a pile of disconnected tool output.

The “discovered isn’t authorized” problem above isn’t left to operator memory: Hollowpath’s scope engine enforces it directly. A target being found during discovery does not put it in scope, and nothing downstream — enumeration, exploitation — proceeds against a target that hasn’t been positively confirmed authorized. See Security Philosophy for how that’s actually enforced, and Product for how discovery fits into the rest of the assessment workflow.