The gap that nobody owns
Every organisation has two versions of its infrastructure. There is the version that lives in the CMDB, the cloud account inventory, and the change management tickets — the systems IT and security believe they are responsible for. And there is the version that actually resolves on the public internet, which includes every subdomain, every forgotten test environment, every third-party integration, and every asset spun up by a team that never filed a change request.
These two versions are never the same size. The second is almost always larger, and the difference between them is where attackers spend most of their time. Reconnaissance is cheap. An attacker does not need privileged access or a zero-day to find a login page on a subdomain nobody remembers registering — they need a DNS enumeration tool and an afternoon.
How the gap forms
Attack surface sprawl is rarely the result of negligence. It is the natural byproduct of how modern organisations operate. A marketing team spins up a landing page on a new subdomain for a campaign, connects it to a third-party form provider, and the campaign ends but the subdomain does not get decommissioned. An engineering team stands up a staging environment to test a feature, points it at a copy of production data for realism, and forgets to tear it down once the feature ships. A business unit signs up for a SaaS tool, connects it to the corporate identity provider for convenience, and nobody loops in security because the sign-up flow did not require it.
None of these actions individually looks like a security incident. Each one is a reasonable, low-friction decision made by a team trying to move quickly. But the sum of thousands of these decisions, across years and across every department that can register a domain or spin up a cloud instance, is an attack surface that security has never fully seen — let alone assessed.
Why asset inventories fall behind
CMDBs and asset inventories are built on the assumption that assets are provisioned through a known process: a ticket is raised, a system is approved, and the asset is logged. That assumption held reasonably well when infrastructure changes went through centralized IT. It holds far less well today, when any team with a credit card can provision a cloud resource, register a domain, or connect a SaaS integration without ever touching the change management process.
The result is an inventory that reflects intent rather than reality. It captures what was supposed to be deployed, not what is actually resolvable and reachable from the outside. Attackers do not care about intent. They care about what responds when they send a request, and that list is compiled independently of any internal record-keeping.
What attackers actually find
In practice, the assets that create the most risk are rarely the ones security teams are actively watching. Production systems tend to be patched, monitored, and fronted by controls precisely because everyone knows they matter. The exposure tends to concentrate in the periphery: a staging environment running an outdated framework version because it was never in scope for the patch cycle, an admin panel left open on a subdomain because the team assumed obscurity was protection, or a forgotten integration with default credentials still active because nobody remembered it existed.
These assets share a common trait — they were never designed to be internet-facing risk, they simply became risk by omission. Nobody made an active decision to expose them; they were exposed by the absence of a decision to clean them up.
Closing the gap
Solving this problem does not start with better documentation discipline, although that helps. It starts with looking at your organisation the way an attacker does: from the outside, without relying on any internal record of what should exist. External attack surface management is built on this premise — continuously enumerating what actually resolves under your organisation’s domains, IP ranges, and certificates, rather than trusting what was logged when an asset was created.
This external view will almost always surface assets that security did not know existed. That is not a failure of the exercise — it is the exercise working as intended. The goal is not to achieve a perfect, unchanging inventory; sprawl is a continuous process, driven by how the business operates, and it will keep generating new shadow assets as long as teams can provision infrastructure independently.
The more realistic goal is to shrink the time between an asset appearing and security becoming aware of it — from months or years, which is the current default for most organisations, down to days. An asset that exists for a week before it is discovered and assessed is a manageable risk. An asset that exists for three years before anyone notices it is effectively a standing invitation, and in a large enough organisation, several of those invitations are open right now.
Written by Jamal Hashi, CyberPost Advisory.