Attack surface management has had its moment. Over the past four years, ASM tools have moved from niche to mainstream. Security teams can now continuously monitor their external-facing assets, discover shadow IT, map their third-party supply chain exposure, and get alerted when a new subdomain or cloud storage bucket appears. This is genuinely useful. It is also genuinely insufficient.
The gap that ASM tools do not close — and that security programmes have been slow to confront — is this: knowing that something is exposed does not tell you whether it is exploitable, whether it is being actively targeted, or whether exploiting it would cause material harm to the business. Without that second layer, ASM gives you a map of the surface. It does not tell you where the doors are, which doors are unlocked, or which rooms you actually care about protecting.
What ASM Does Well
It is worth being precise about ASM's genuine value before addressing its limits — because the problem is not with ASM as a capability. The problem is with treating it as a complete solution.
ASM tools excel at continuous discovery. They find assets that traditional vulnerability management programmes miss: forgotten subdomains, development environments left internet-facing, cloud buckets provisioned by a development team outside the security team's awareness, recently acquired company infrastructure not yet onboarded to internal processes. In environments with significant cloud footprint, supply chain complexity, or fast deployment cadences, this discovery function is indispensable.
ASM also provides good historical context — tracking how the attack surface has grown or contracted over time, which gives security leaders a credible signal about whether their external hygiene is improving or degrading.
Where the Gap Opens
The gap opens the moment you move from the question "what is exposed?" to the question "what should I fix first?" ASM data alone cannot answer the second question. Here is why.
Exposure is not the same as exploitability
An internet-facing server running an unpatched Apache version is exposed. Whether it is exploitable depends on factors ASM does not track: is there a public proof-of-concept exploit for the specific CVE on that version? Is there a WAF in front of it that blocks the attack pattern? Is the vulnerable component actually reachable given the application's network architecture? Is the vulnerability being actively exploited in the wild right now, or is it theoretical?
Without exploitation context, a security team looking at ASM output is staring at a list of everything that could hypothetically be targeted, with no reliable way to distinguish the genuine threats from the theoretical ones.
"An ASM tool without exploitation context is like a fire alarm that triggers for smoke, steam, and someone burning toast. It is not wrong — but the response team quickly learns to ignore it."
Exposure without business context produces false urgency
ASM tools flag exposures. They do not know whether the exposed asset is the company's primary revenue platform or a developer demo environment that nobody has looked at in two years. Both are "critical" in an ASM alert. The remediation priority for each is categorically different.
Teams that use ASM as their primary risk signal end up responding to alert volume rather than to business risk. They patch the things that are easy to patch, defer the things that require coordination, and end up with a programme that is busy but not effective.
The supply chain blind spot
ASM tools are increasingly good at identifying third-party assets in your exposure map. They are not good at telling you whether those third parties have been compromised, whether a vulnerability in a third-party component is being actively exploited in supply chain attacks, or whether your reliance on a particular third-party service creates a systemic business risk that exceeds the technical exposure.
The Three Layers of Context That ASM Is Missing
| Context Layer | What It Answers | Why ASM Doesn't Provide It |
|---|---|---|
| Exploitation intelligence | Is this being actively exploited? Does a reliable exploit exist? What is the EPSS score? | ASM is passive discovery — it does not ingest real-time threat intelligence feeds or exploitation data |
| Business asset criticality | What does this asset do? What is the revenue / regulatory / operational impact of a compromise? | ASM has no model of business context — it sees technical assets, not business units or data classifications |
| Compensating controls | Is this vulnerability mitigated by a WAF, EDR, MFA, network segmentation, or other control? | ASM sees the attack surface from the outside — it cannot assess the internal defence posture |
Exploitation Context in Practice
Exploitation context is a composite signal, not a single data point. In practice, it combines three sources:
- CISA KEV (Known Exploited Vulnerabilities): The US Cybersecurity and Infrastructure Security Agency maintains a catalogue of CVEs for which there is confirmed evidence of active exploitation in the wild. A CVE on the KEV catalogue is categorically more urgent than one that is not — regardless of CVSS score.
- EPSS (Exploit Prediction Scoring System): EPSS is a machine learning model that predicts the probability that a given CVE will be exploited within the next 30 days, based on threat intelligence, public exploit data, and historical exploitation patterns. A CVE with an EPSS score of 0.7 (70% probability of exploitation) warrants a fundamentally different response than one scoring 0.003.
- Threat intelligence feeds: Industry-specific and general threat intelligence feeds provide signals about which CVEs and attack techniques are currently being weaponised against organisations like yours — in your sector, in your geography, targeting your technology stack.
When exploitation context is combined with ASM exposure data and business asset criticality, the result is a prioritisation signal that is both defensible and actionable.
A practical illustration
Your ASM tool flags 47 internet-facing hosts with a medium-severity Apache vulnerability. Exploitation context shows that 3 of those CVEs are on the CISA KEV list, 2 have EPSS scores above 0.6, and current threat intelligence indicates active scanning for those specific versions in your industry sector. Business context shows that 2 of those 47 hosts serve your customer-facing payments API. With this combined signal, the decision is immediate: those 2 hosts are treated as a P0 incident, not a scheduled patch. The other 45 enter the normal sprint cycle.
What a Complete ASM + Exploitation Context Programme Looks Like
Effective programmes treat ASM and exploitation context as two layers of the same system, not two separate tools. The integration points are:
- Common asset inventory: ASM discovery feeds into a shared asset register that carries business context — application name, business unit, data classification, revenue tier. Every finding from every source references this register.
- Automated exploitation enrichment: Every discovered exposure is automatically enriched with current EPSS scores, KEV status, and relevant threat intelligence. This happens in near real-time, not on a weekly batch cycle.
- Unified risk score: A combined risk signal — exposure + exploitability + business criticality — drives the remediation queue. Teams see a single prioritised list, not separate outputs from separate tools.
- Continuous feedback: Remediations are validated (the vulnerability is confirmed closed, not just the ticket), and the asset register is updated to reflect the current state.
The Honest Assessment
If your organisation is running ASM and feeling like the signal-to-noise ratio is poor, that is not a product failure. It is a completeness failure. You are doing the first half of a two-stage process and expecting it to produce the outputs of the full process.
ASM tells you where your walls are and which ones have cracks. Exploitation context tells you which cracks are being actively probed, how hard it would be for an attacker to get through them, and what is on the other side. You need both questions answered to make good decisions. ASM alone only answers the first.
The good news is that the data to answer the second question exists, is increasingly accessible, and — when integrated properly — transforms the value of your ASM investment rather than replacing it.