Attack path analysis vs vulnerability scanning: what each one answers
A vulnerability scan answers "what is broken?" Attack path analysis answers "what can an attacker actually reach?" They are not rivals. They fail in opposite directions, which is the reason most teams end up running both.
If you only remember one line, make it this: a vulnerability scan is an inventory of flaws, and attack path analysis is a map of routes. A flaw is not a route. A route can exist with no flaw at all. Each tool is blind to what the other sees.
What vulnerability scanning answers
A vulnerability scanner compares what is installed against databases of known flaws. It reads package lists, container image layers, or the software on a host, and reports each match with an identifier, usually a CVE, and a score. The question it answers is narrow and useful: which known vulnerabilities exist in the software I run?
That has real strengths. It is systematic, so a package nobody remembered gets listed. It is repeatable, so you can watch the count move. It maps well to patching, since every row names the thing to update and often the version that fixes it. Compliance programmes lean on it for good reason.
Where scanning fails
Scanning fails in three ways, and they all come from the same limit: it judges each item alone.
- It cannot rank. A scan of a modest estate returns thousands of rows, many scored high. Severity describes the flaw in a generic setting. It does not say whether this host can be reached, or what the host can do if it is taken. The queue is long and the order is arbitrary.
- It misses what is not a vulnerability. A role that can assume an administrator role has no CVE. A trust policy that admits an entire organisation has no CVE. An unauthenticated function with broad permissions has no CVE. Most cloud breaches start with access, not with a patchable flaw, so the scanner has nothing to say.
- It cannot tell you what to stop first. Two hosts carry the same flaw. One sits in an isolated subnet with no role. The other is public and can read customer data. The rows are identical.
What attack path analysis answers
Path analysis builds a graph of resources, network routes and identity relationships, then searches it for chains from an entry point an outsider can reach to a target worth taking. The question it answers is different: given how this environment is configured today, what can an attacker reach, through which steps?
That is the strength a scanner lacks. It ranks by reachability and consequence, so the short list at the top is the set of things that connect to something that matters. It sees identity and trust, where most cloud risk lives. And it points to the cheapest repair, which is often a permission, not a patch. The full method is in attack path analysis.
Where path analysis fails
It has its own blind spots, and they are the mirror of the scanner's.
- It models the possible, not the confirmed. A path shows that a chain can be walked. It does not show that the first step is actually exploitable. That depends on whether a flaw exists at the entry point, which is the scanner's territory.
- It depends on the quality of its data. A gap in what the connection can read is a gap in the graph, and a missing edge looks the same as a safe one.
- It does not replace patching. A flaw with no route to it today may have one tomorrow, after an unrelated change. Closing the path is a mitigation. The flaw is still there.
The same estate, seen both ways
Imagine two EC2 instances running the same outdated web library. The scanner reports the flaw on both, with the same identifier and the same score, and the two rows sit next to each other in the queue.
One instance is in a private subnet behind a load balancer, with no public address and an instance role that can only write logs. The other has a public address, accepts traffic from anywhere, and runs as a role that can read the customer export bucket. A path analysis returns nothing for the first instance and a three-hop chain for the second.
The scanner could not tell these apart, and it was never meant to. The path analysis could tell them apart, but it needed the scanner's result to know the second instance had a flaw an attacker could use for the first step. That is the whole relationship in one example: the scan supplies the weakness, the path supplies the context.
Side by side
| Question | Vulnerability scanning | Attack path analysis |
|---|---|---|
| Core question | What known flaws exist in what I run? | What can an attacker reach, and how? |
| Unit of output | A flaw on an asset | A chain of steps to a target |
| Sees permissions and trust | No | Yes |
| Sees network reachability | Rarely | Yes |
| Ranks by consequence | By generic severity | By route and target |
| Confirms a flaw is exploitable | Reports the flaw, not the exploitability | No |
| Typical fix | Update a package | Remove a permission, close a route, or patch |
Why most teams need both
The two outputs combine into something neither gives alone. A path tells you which hosts are on routes to targets. A scan tells you which of those hosts carry a known flaw, and whether it is one attackers are already using. Together they answer the practical question: which flaw, on which host, on which route, do I deal with today?
Use the scanner to keep the estate honest: nothing unpatched should go unlisted. Use path analysis to decide the order, and to catch the risks that have no identifier. Exploit signals such as EPSS and the KEV catalogue sit in the middle. They narrow a scan's list, and on a path they say how likely its weakest step is to be tried. CVSS, EPSS and KEV explains what each means, and attack paths vs CVSS shows what goes wrong when severity alone sets the order.
Which to start with
If you have no scanning at all, start there. Not knowing what is installed is a worse position than not knowing what is reachable. If you already have a scanner and a queue nobody can finish, add path analysis, because the queue is the problem and a ranking is what shortens it. And if you are worried about identity, trust and misconfiguration more than packages, path analysis is the better first purchase, since a scanner will not see most of it.
FAQ
Is attack path analysis a replacement for vulnerability scanning?
No. Path analysis ranks and connects risks, but it relies on a scanner or inventory to know which hosts carry flaws. The two answer different questions.
Can a vulnerability scanner do attack path analysis?
Not by itself. A path needs network, identity and trust data in a single graph. Some platforms combine both, but a plain scanner reports flaws per asset.
Which finds more cloud risk, scanning or path analysis?
They find different things. Scanning finds known flaws in software. Path analysis finds routes created by configuration and permissions, which often have no CVE.
Do I need a separate tool for each?
Not necessarily. Several platforms offer both. What matters is that the ranking uses reachability and the scan uses a current inventory.
Secorvia runs both on one platform: vulnerability intelligence on every plan, and attack paths from Starter. See attack path analysis.