EASM, CAASM, vulnerability management, exposure management: which one do you actually need?

Four acronyms, sometimes five, arrive in the same procurement cycle. They are pitched by different vendors, sit in adjacent analyst documents, and describe overlapping outcomes in nearly identical language. Every one of them promises to show you what is exposed.

They are not interchangeable, and the difference is not marketing. It is architectural, and it comes down to a single question that cuts cleanly through all four.

The question that separates them

Where does the data come from?

Not what the dashboard shows. Not what the vendor calls the category. Where the underlying data originates. Answer that and the four separate immediately, because each is defined by a different source of truth, and every source of truth carries a different blind spot.

Vulnerability management: inside-out, from assets you already own

Vulnerability management operates on assets you have already enrolled: an agent, a set of credentials, a scan range you supplied. It authenticates into hosts, enumerates installed packages, compares versions against advisories, and produces findings with severity scores.

It is the most mature of the four, the one your auditors already understand, and genuinely good at its job: telling you which of your known systems run software with known flaws.

Its blind spot is definitional. It can only assess what you told it about. A subsidiary's marketing site registered on a corporate card, a cloud instance stood up by a product team outside the sanctioned account structure, an application a partner hosts on your behalf: none of these are in the scan range, so none of them are in the report. The scanner is not failing. It is answering the question it was asked.

CAASM: aggregation of the inventories you already have

Cyber asset attack surface management sits one layer up. Rather than scanning, it connects by API to the systems that already know about your assets, including cloud accounts, EDR, the CMDB, the identity provider and MDM, and reconciles them into a single normalised inventory.

This solves a real and expensive problem. Most enterprises run several partial asset inventories that disagree with one another, and reconciling them by hand is a permanent low-grade tax on the security team. CAASM automates that reconciliation and, more usefully, surfaces the disagreements: the hosts your EDR sees that the CMDB never recorded, the cloud instances with no owner, the laptops in MDM but absent from the directory.

Its blind spot is inherited rather than chosen. CAASM can only ever be as complete as the union of the systems it integrates with. If an asset exists in none of your internal sources, it exists nowhere in your CAASM inventory either. It is an excellent answer to "do my systems agree with each other" and no answer at all to "is there something out there that none of my systems has ever heard of."

EASM: outside-in, with no prior knowledge

External attack surface management starts from the opposite end. It assumes nothing. Given a seed, typically a company name and one or two apex domains, it discovers what is reachable from the internet and attributable to you, using the same sources an attacker would use: certificate transparency logs, passive DNS, registration records, ASN and cloud IP attribution, public code hosts, app stores, and the infrastructure relationships between all of them.

The output is an inventory built without reference to your inventory. That is the entire point, and it is why outside-in discovery consistently returns assets the internal systems never held. Across our own customer base, first-pass external discovery typically surfaces 30–60% more internet-facing assets than the organisation had inventoried internally.

Its blind spot is equally definitional and worth stating plainly. EASM sees the outside. It has no agent telemetry, no view of your internal network, no visibility into endpoints, and it cannot tell you the patch level of a server behind your firewall. Anyone selling EASM as a replacement for vulnerability management is selling you a gap.

Where outside-in claims get tested: attribution

Discovery volume is the number every EASM vendor leads with, and it is the least useful one, because the hard part of outside-in discovery is not finding candidate assets. It is deciding which of them are actually yours.

Attribution is a judgement made from indirect evidence: a shared certificate, a registrant email, a hosting relationship, a naming convention, an ASN allocation. Each inference can be wrong, and the two failure modes carry very different costs. A missed asset is a hole in the map. A falsely attributed asset is worse in practice, because it puts a third party's infrastructure into your queue and, if it reaches a validation stage, into your authorised testing scope.

So the question to put to any vendor in this category is not how many assets they find. It is how they establish ownership, what confidence they attach to each attribution, and what happens operationally when they get one wrong. A platform that cannot show you the evidence chain behind an attribution is asking you to accept its inventory on trust, which is precisely the posture the category exists to replace.

Exposure management: the programme, not the tool

Exposure management, and the framework beneath it, continuous threat exposure management, is not a data source at all. It is the operating layer: scoping, discovery, prioritisation, validation and mobilisation, run as a continuous cycle over whatever data sources feed it.

This is where the category gets muddy, because every vendor in the other three now describes itself as exposure management. Sometimes fairly, because an exposure management programme genuinely does need all of the above. Often not, because a vulnerability scanner with a new dashboard is not a programme.

The useful test is whether the thing in front of you performs the two stages that separate a programme from a feed. Prioritisation: does it order findings by what is actually reachable and usable in your environment, or by CVSS with the severity filter set to critical? And validation: does anything establish that a finding is real and exploitable before a human is asked to spend an afternoon on it? Without those two stages you have not bought an exposure programme. You have bought another queue.

Side by side

	Source of truth	Sees unknown assets	Sees internal hosts	Needs agents or credentials	Answers
Vulnerability management	Your scan scope	No	Yes	Yes	Which known systems are unpatched
CAASM	Your other systems, via API	No	Yes	Integration credentials	Whether your inventories agree
EASM	The public internet	Yes	No	No	What exists outside that you did not know about
Exposure management	All of the above	Depends on inputs	Depends on inputs	Depends on inputs	What to do first, and whether it is real

Which one are you actually missing?

Three cases, stated honestly.

You run a mature vulnerability programme, and you keep discovering assets during incidents that were never in scope. You need EASM. The gap is discovery, not assessment. The assessment is working correctly; it is simply being pointed at an incomplete list.

You have several asset inventories and cannot get a straight answer out of any of them. You need CAASM, or you need to fix the CMDB. This is an internal reconciliation problem and EASM will not solve it, because EASM does not read your CMDB, although it will tell you, uncomfortably, how much of your real estate none of those inventories contained.

You have no shortage of findings and no defensible way to decide which ones matter. You do not need a fourth scanner. You need the prioritisation and validation stages of an exposure programme applied to the data you already hold.

Where ShadowMap sits, and where it does not

We are external, deliberately. ShadowMap discovers your internet-facing estate without prior knowledge, and extends that outside-in view past infrastructure into the exposures that sit outside your perimeter entirely: leaked source code and secrets, credential and stealer-log intelligence from dark-web collection, brand abuse and impersonation, and your vendors' external posture assessed by the same method as your own.

It then performs the two stages that make a programme rather than a feed. AI Review restructures the queue by context rather than by score. Validation establishes, where it is safe and authorised to do so, whether a finding can actually be used: whether an exposed key is live and what it opens, whether a leaked credential still authenticates, whether an exposed service is reachable and exploitable rather than merely present. In practice 8–15% of surfaced exposures are validated as genuinely exploitable, and that subset is what the remediation conversation should be about.

What we are not, stated as plainly. We are not a vulnerability management platform: we run no agents and hold no endpoint telemetry, and we cannot tell you the patch level of a server inside your network. We are not CAASM: we integrate with your CMDB in order to reconcile against it, but we do not aggregate your internal inventories into a system of record. And we do not claim exposure management unqualified, because the term now implies internal scope we do not have. External exposure management is the accurate description, and the word doing the work in it is the first one.

Most enterprises end up running two of these categories, not one. The mistake worth avoiding is buying the second believing it covers the first.

---

Evaluating one of these categories? Bring an apex domain to a 30-minute technical session and we will show you what outside-in discovery returns against your own estate, including how each asset was attributed and why. → Talk to a ShadowMap engineer

Related: Attack Surface module · How ShadowMap works · The full platform