Key takeaway: External attack surface management works from the same starting point an attacker does — the internet — rather than from an internal asset list that is reliably incomplete.
Why Internal Inventories Miss Things
A CMDB or asset register is built from what teams reported when they provisioned something, updated on the assumption that people remember to record changes, and reviewed on whatever cadence someone scheduled. Every one of those steps can fail silently.
A marketing team spins up a landing page on a service nobody in security knew existed. A developer stands up a test environment with production data for a demo and forgets to tear it down. An acquisition brings infrastructure that was never folded into the parent company’s inventory. None of these are unusual — they are the normal accumulation of a growing organisation, and each is invisible to any inventory built from internal reporting.
Working From the Outside In
Attack surface management inverts the discovery direction. Rather than asking internal teams what exists, it enumerates what is actually reachable from the internet against your organisation’s known domains, IP ranges and certificates, then works outward from there.
| Discovery method | Finds |
|---|---|
| Certificate transparency logs | Subdomains issued a TLS certificate |
| DNS enumeration | Registered subdomains and records |
| IP range scanning | Services listening on owned address blocks |
| Cloud asset APIs | Resources across connected cloud accounts |
| Acquisition and subsidiary mapping | Infrastructure inherited through M&A |
Certificate transparency logs are particularly effective because they are a public, complete record — every publicly trusted certificate issued for any subdomain is logged permanently, regardless of whether the team that requested it told anyone else in the organisation.
What Turns Up
The findings from a first external scan are consistently uncomfortable. Forgotten staging environments still running with default credentials. Development databases exposed without authentication because a firewall rule was scoped incorrectly. Old marketing microsites running unpatched software years past its last update, kept alive because nobody remembered they existed to decommission them.
None of these were sophisticated intrusions. They were assets that existed, were reachable, and were simply unknown to the people responsible for defending the organisation.
Turning Discovery Into a Process
A one-time scan produces a useful list and no lasting improvement, because new assets appear continuously. The value comes from running discovery on a schedule and treating new findings as events requiring triage rather than as an occasional audit.
Assign every discovered asset an owner before anything else. An asset with no owner cannot be patched, decommissioned or risk-assessed, because nobody has the authority or context to make that decision — and unowned assets are disproportionately the ones that caused the exposure in the first place.
Feed findings into the same vulnerability management workflow as internally known assets, rather than maintaining a separate parallel process. An externally discovered exposed database is exactly as urgent as one flagged by internal scanning, and treating it differently just because of how it was found delays the response.
Extending to the Supply Chain
The same technique applied to vendors and key suppliers reveals which of your critical partners have their own exposed assets — relevant because a compromise of a trusted vendor with access to your systems is functionally an attack on you, discovered too late if you were not watching their external surface at all.
The Bottom Line
Run external discovery on a schedule using certificate transparency, DNS enumeration and cloud asset APIs, and treat every new finding as requiring an assigned owner before anything else happens. Feed the results into the same triage process as internally discovered issues, since an attacker does not care which inventory an exposed asset was missing from.
