Attack surface management (ASM)
In security operations, attack surface management (ASM) is the continuous discovery and assessment of external-facing assets and their exposures, from an attacker’s outside-in perspective. Its output is an inventory that is found rather than declared: the hosts, names, certificates and services that answer from the internet, whether or not anyone remembers creating them.
How it works
A discovery cycle starts from what is known, usually a set of registered domains and network ranges, and expands outward: certificate transparency logs, passive DNS, registry data, cloud provider ranges, code repositories and third-party services that publish a hostname. Each candidate is resolved, probed for open services, fingerprinted, and attributed back to an owning organisation, since the hard part is not finding hosts but deciding which ones are yours. The cycle then repeats, because the surface changes every time somebody deploys.
The boundary with its neighbours is worth being exact about, because three adjacent terms are routinely used as if they meant the same thing. Attack surface is the concept: everything reachable that could be attacked. Attack surface management is the practice of discovering and tracking it. Exposure management is what you do next: deciding which of those exposures actually matter and driving them down.
What goes wrong
The finding we write most often is not a vulnerability, it is an ownership gap. Something answers on the internet, it is in scope by anyone’s definition, and no team claims it. It was a campaign site, an acquired company’s estate, a test environment a developer left running in a personal cloud account, or an appliance somebody exposed for a supplier and forgot.
The failure mode of the tooling is the opposite one: too much. A discovery platform that attributes aggressively produces a list containing assets belonging to somebody else, and once a client finds two of those they stop trusting the whole list. Attribution evidence matters as much as discovery. And a platform that discovers continuously but is never validated by hand reports what a banner claims rather than what the service does, which is how a decommissioned host stays green and a subdomain takeover sits open for a year.
Where this shows up in an audit
Every external engagement begins here, and the first deliverable is the inventory itself, with the evidence for each attribution, because it is routinely the part the client did not have. We then confirm by hand what the automation asserted, and the report separates assets the client recognised from assets they did not. The second list is the one that changes behaviour. This is part of how we verify an external perimeter by hand.