74% of Breaches Start
With Assets You Don't Know You Have.

Every penetration test has a scope. The scope defines which systems the testers look at. It is agreed in advance, documented in the statement of work, and approved by the security and legal teams. The problem is that the scope is defined by what the organisation knows it has. And 74% of breaches involve assets the organisation either didn't know existed or didn't include in its security programme.

This is the attack surface problem. The assets an attacker finds are not necessarily the ones on the asset inventory. They are the forgotten staging server that was never decommissioned, the development environment that the product team spun up in a personal cloud account, the API endpoint that a third-party integration exposed without going through the security review process, the subdomain registered for a marketing campaign three years ago and abandoned with the campaign but never taken down.

The known-unknown gap

Asset inventory is a solved problem in theory and an unsolved problem in practice. Every security framework requires one. Most organisations maintain one. The gap between the inventory and the actual attack surface is the space in which most serious breaches begin. The inventory reflects what someone manually catalogued at some point in the past. The attack surface reflects what is actually reachable from the internet right now.

The drift between the two is not a failure of diligence. It is a structural consequence of how modern infrastructure is built. Development teams provision cloud resources independently. Acquisition targets bring entire infrastructure estates that the acquirer may not fully understand for months. Shadow IT creates assets that the security team has no visibility into. The attack surface grows faster than any manual inventory process can track.

The API problem is the attack surface problem

Akamai's 2023 API Security Report found that 87% of API attacks targeted APIs that the organisation did not know existed or had not included in its security programme. This is the attack surface problem expressed specifically in the API layer. Modern applications generate API endpoints through microservices, third-party integrations, and legacy system wrappers at a rate that makes manual cataloguing impractical. The attack surface is continuously expanding; the asset inventory is updated quarterly at best.

APIs are a particularly attractive attack surface because they often have weaker authentication than web applications, expose more of the underlying data model, and are less likely to be behind a WAF or rate-limiting control that a web application would have. An undocumented API endpoint that allows unauthenticated access to customer data is a critical vulnerability. It is also, by definition, not in scope for a penetration test against the documented API inventory.

What external attack surface management actually does

EASM is the practice of continuously discovering, inventorying, and assessing the security posture of all internet-facing assets associated with an organisation, including assets the organisation does not know about. It starts from the attacker's perspective: given the organisation's name, its domain registrations, its IP ranges, its cloud provider relationships, and its third-party integrations, what is reachable from the internet?

The output of this discovery process is typically a much larger attack surface than the organisation's own inventory reflects. Subdomains registered years ago, development environments with production data, exposed admin panels on forgotten infrastructure, and APIs with permissive CORS policies all appear in an EASM discovery that would not appear in a traditional pentest scope.

Once the surface is mapped, the EASM programme continuously monitors it for changes. A new subdomain, a certificate expiry that exposes an alternative domain, an S3 bucket that becomes publicly accessible after a misconfiguration — all of these appear in the monitoring feed before an attacker finds them, if the programme is functioning.

Integrating EASM with continuous testing

EASM discovers the surface. Continuous security testing validates whether the surface is exploitable. The two programmes are complementary: EASM ensures the target list for testing reflects the actual attack surface, not just the known inventory; continuous testing ensures that exposures discovered by EASM are assessed for exploitability and remediated before they can be used.

Without the integration, EASM produces a list of unknown assets but provides limited information about which ones are actually dangerous. Without EASM, continuous testing covers only the known inventory and misses the 74% of the attack surface where most breaches begin. Together, they close the gap between what the organisation's security programme covers and what an attacker can reach.