Attack Path Analysis: The Missing Layer in Vulnerability Prioritization

Where Contextual Prioritization Runs Out

Contextual prioritization gets you a long way. Exploitability data removes most of the backlog on strong evidence. Asset criticality tells you which of the remainder touch something the business depends on. If you have not worked through that case, Vulnerability Risk Scoring: Why CVSS Alone Isn’t Enough covers why severity alone cannot carry the decision.

But every one of those signals still evaluates findings one at a time, and that is not how a breach happens. A breach happens when an attacker takes something small, uses it to reach something else, and repeats until they arrive somewhere that matters. Each individual step can look tolerable. The sequence does not.

Attack path analysis models that sequence. It maps how exposures connect across applications, cloud resources, network topology, and identity configuration to form routes toward critical assets. A medium-severity server-side request forgery flaw on an internal API is not a standalone problem. If that API can reach a metadata service, and the role attached to it can read your customer database, the flaw is the opening move in a live path.

Four Hops to the Customer Database

Here is what that looks like in practice, drawn from a pattern common enough in cloud environments to be unremarkable.

An internal API carries a CVSS 6.5 server-side request forgery flaw. The API runs in a subnet documented as isolated. It is not isolated, because a segmentation rule permits east-west traffic to the database tier. The API can reach the cloud metadata service. The role attached to that workload carries read access to the customer database, granted during a migration and never revoked.

Hop	What the attacker does	What it grants	How it was rated alone
1	Exploits the SSRF flaw on the internal API	The ability to make requests from inside the subnet	CVSS 6.5, medium. Sprint backlog.
2	Directs those requests at the cloud metadata service	Temporary credentials for the role attached to the workload	Never flagged. Working as designed.
3	Assumes the role and enumerates its permissions	Read access to the customer database, granted years ago and never revoked	Cloud posture finding, medium. Owned by the cloud team.
4	Crosses from the API subnet to the database tier	A direct network route to the data	Segmentation finding, low. Owned by the network team.
End	Reads and exfiltrates	Regulated customer data	No critical finding anywhere in the chain

Read the right-hand column on its own, and there is no emergency here. A medium, a design behavior, another medium, and a low. Read the row sequence, and there is a complete route from an exposed component to regulated data.

The findings were not hidden. The risky conditions were already present across the environment, but no single tool or team could see the complete route.. The application security team owned the SSRF. The cloud team owned the role. The network team owned the segmentation rule. Nobody owned the path, because no system in the environment could represent one.

And the critical that does not matter

In the same scan, a CVSS 9.8 remote code execution flaw appears on a legacy test server. No external exposure, quarantined segment, no route to production, an application nobody uses, decommission already scheduled. By severity, it is the top of the queue and gets the best engineer on Monday. By reachability, it is a housekeeping ticket, because the path is one hop long and terminates immediately.

Two decisions, opposite directions, and severity scoring gets both of them backwards.

Attackers Chain. Scanners Do Not.

This is not a modeling exercise. In a joint advisory, CISA and partner agencies documented threat actors combining vulnerabilities in internet-facing gateway appliances to bypass authentication, craft malicious requests, and execute arbitrary commands with elevated privileges. The authentication bypass that opened that chain was rated CVSS 8.2, below the critical threshold many teams use to trigger emergency response. Paired with a command injection flaw, it produced unauthenticated remote code execution on an internet-facing device.

The pattern holds generally: the component that opens the door is rarely the component with the highest score. Authentication bypasses, permission gaps, and segmentation errors are seldom rated critical on their own, because severity measures what a single flaw can do in isolation. Chaining is about what a flaw grants access to next, and that is a property of your environment, not of the vulnerability.

The breach data has moved the same way. Exploitation of vulnerabilities has overtaken credential abuse as the leading initial access vector, at 31 percent of breaches against 20 percent the year before, the first time in the report’s 19-year history that stolen credentials have been displaced. Edge devices and VPNs accounted for 22 percent of that exploitation activity, up from 3 percent (Verizon 2026 Data Breach Investigations Report).

Those are exactly the assets where chains begin: internet-facing, identity-adjacent, and connected to everything behind them.

What Isolated Scoring Cannot Express

CVSS, EPSS, and the CISA KEV catalog are all worth using, and each answers a real question: how damaging, how likely, and whether confirmed in the wild. They share one structural limit. Each scores vulnerabilities individually, so none of them can express that a medium on one asset, plus an over-permissioned role on a second, plus a missing segmentation rule on a third, equals a route to your database. That is a statement about relationships, and a per-CVE score has no way to hold one. Vulnerability prioritization tools built only on those three signals will produce queues that look rigorous and still miss the routes an attacker would take.

Chokepoints Are Where This Pays Off

The argument so far is defensive: without path analysis, you misrank findings. The stronger argument is offensive, and it comes from a property of paths that individual findings do not have. Paths converge.

Routes through a real environment are not independent. They funnel through shared infrastructure, because that is what shared infrastructure is for. One over-permissioned service role, one flat network segment, one CI runner with production credentials, one identity provider misconfiguration. Each of these tends to appear not on one path but on many, because everything downstream of it inherits its reach.

That changes the economics of remediation. Closing a finding removes one finding. Cutting a chokepoint removes every route that traverses it, which may be dozens. A sprint spent scoping one IAM role correctly can eliminate more real exposure than a quarter spent burning down a severity-sorted backlog, and it does so without asking developers to touch application code at all.

It also gives security something it usually lacks in the conversation with engineering: a request that is small, specific, and clearly bounded. Fixing this one permission is an easier ask than patch these four hundred findings, and in path terms it can be the larger risk reduction. Chokepoint analysis is only possible once routes are modeled, which is a concrete reason to build the capability rather than approximate it with better scoring.

Identity Often Shapes Cloud Attack Paths

When teams first think about attack paths they picture network hops: a machine reaching another machine. In cloud environments that intuition is dated. In cloud environments, network reachability is only part of the picture. Identity and permissions often create critical hops..

A workload assumes a role. A role trusts another role. A service account holds a token that was scoped generously during a migration and never revisited. A CI pipeline carries credentials that can deploy to production. None of these are vulnerabilities in the CVE sense, so none carry a CVSS score, and traditional CVE-focused vulnerability scanners generally will not report them.. They are configuration, and they are frequently the longest hops in the chain, because a single role assumption can cross a boundary that would otherwise take an attacker several steps to traverse.

This is why path modeling that draws only on scanner output produces short, tidy, misleading paths. The chain in the example above depends on hop 2 and hop 3, and neither is a vulnerability. If your prioritization model cannot ingest identity and permissions data alongside findings, it will keep concluding that the SSRF is a medium, because in the data it can see, that is all the SSRF is.

It also explains why exposure management has become the frame mature programs use. The question stops being what is vulnerable and becomes what is reachable, and reachability in cloud environments is largely a question about who can assume what.

What Changes When You Prioritize by Reachability

The queue reorders, and some of the reordering is uncomfortable. Mediums get escalated for where they sit. Criticals get deferred because nothing can reach them. Teams trained on severity will challenge both, which is why the reasoning has to be legible rather than asserted.

That legibility is the underrated benefit. A prioritization decision expressed as a path is arguable in a way a weighted score is not. You can walk a developer through the four hops and the asset at the end. You can show an executive why a medium is being fixed this week and a critical is not. You can show an auditor the basis on which a finding was deferred. A risk decision backed by a traced route survives scrutiny that a composite number does not.

It also changes what deferral means. Under severity triage, deferring a critical is an exception someone has to sign for. Under path-based prioritization, deferring an unreachable critical is the correct answer, documented as such. That distinction now has regulatory support: CISA Binding Operational Directive 26-04, issued 10 June 2026, directs federal agencies to prioritize high-risk vulnerabilities on publicly exposed assets while deferring lower-risk ones, and encourages every organization to adopt the same risk-based approach. The lesson is not that deferral is risk-free. It is that deferral can be a documented, risk-based decision when the evidence supports it.

What It Takes to Model Paths

Path analysis depends on data most organizations already hold and do not correlate. It assumes Risk-Based Vulnerability Management as a starting point, since a route that crosses a repository, a cloud resource, a network segment, and a database needs all four sources present. Partial integration yields partial paths, which is worse than none, because a truncated path reads as a dead end. Beyond that:

Add the layers scanners do not carry

Network topology and reachability, identity and permissions, asset ownership, and business criticality. Every hop is a relationship between two of those. A missing layer does not degrade the model gracefully, it silently shortens paths.

Rank by what the route terminates in

A path ending at a customer database outranks a path ending at a build cache, even when the component findings score identically. The terminal asset sets the priority. The traced route establishes that the priority is real rather than assumed.

Prioritize chokepoints with broad risk reduction

Once routes are modeled, identify shared components that sit on multiple high-risk paths. Remediating a chokepoint can eliminate several routes at once, making it an important prioritization signal alongside exploitability, asset criticality, business impact, and reachability..

Re-evaluate continuously

Paths change when the environment changes. A new security group, a new service account, a new deployment can open a route overnight with no new CVE published anywhere. Point-in-time analysis will miss it, which is why path modeling belongs inside a continuous threat exposure management program rather than a quarterly review cycle.

How ArmorCode Approaches This

ArmorCode models attack paths on the Context Risk Graph, the data plane that correlates findings with assets, code repositories, cloud resources, identities, network topology, ownership, and business context. Tracing a route requires knowing what connects to what, including the identity relationships that never appear in scanner output, and the graph is what makes that knowable across tools that otherwise never exchange data.

The platform ingests findings from more than 400+ security tools, then puts Anya Agents, ArmorCode’s agentic workforce, to work reasoning over the correlated picture. The Vulnerability Researcher investigates whether a CVE is exploitable in your environment, while the Risk Analyzer explains the reasoning behind a finding’s risk score and prioritization., drawing on the same graph an engineer would inspect by hand. They operate inside the platform RBAC model rather than as general-purpose assistants attached to the side.

The result is the consolidation the whole approach is aimed at. Snap Finance reduced 63,000 findings from a single cloud security tool to 90 actionable tickets. A leading global agricultural and construction equipment manufacturer cut remediation time by 97%, from 240 days to just hours. Both outcomes come from the shift this article describes: deciding by reachability and business context rather than by score.

Conclusion

Severity scoring rates vulnerabilities individually. Attackers use them in combination. When your prioritization model has no way to represent that gap, the failure is specific and predictable: your best engineer spends the sprint on an unreachable critical while four unremarkable findings form a working route to regulated data.

Attack path analysis closes the gap by supplying what no score can. Not a better severity number, but reachability, and with it the ability to name the chokepoints where many routes converge. That is the difference between a queue that looks rigorous and a queue that reduces risk.

The next piece in this series assembles exploitability, asset context, business impact, and attack paths into a practical framework a team can adopt. For the remediation side, see How to Prioritize Vulnerability Remediation with Risk, Not Just CVSS.

Ready to see which of your findings sit on live attack paths? Request a demo or take a self-guided tour of Unified Exposure Management.

Frequently Asked Questions

Q: What is attack path analysis?

A: Attack path analysis is the practice of mapping how individual security exposures chain together into exploitable routes toward critical assets. Rather than scoring each vulnerability in isolation, it models relationships between assets, identities, network segments, and configurations to determine which combinations of findings create a reachable route. The output is a traced path from initial exposure to terminal asset, which teams use to prioritize by reachability rather than severity.

Q: Can a medium-severity vulnerability really outrank a critical one?

A: Yes, and it is the most common practical outcome of path modeling. Severity describes the impact of a single flaw exploited under ideal conditions and says nothing about reachability. A medium flaw on an internet-adjacent component that chains to an over-permissioned identity and then to regulated data represents a complete route to a breach. A critical flaw on a quarantined server with no inbound path represents a maintenance task. Public advisories describing chained exploitation frequently show an entry point rated below critical.

Q: What is a chokepoint in attack path analysis?

A: A chokepoint is a shared component that appears on many attack paths at once, typically an over-permissioned role, a flat network segment, a CI runner with production credentials, or an identity provider misconfiguration. Because every route downstream inherits its reach, remediating a single chokepoint can eliminate dozens of paths simultaneously. Chokepoints are only visible once routes are modeled, which is one of the strongest practical arguments for path analysis over improved scoring.

Q: What data do you need before attack path analysis is possible?

A: Four layers beyond the findings themselves: network topology and reachability, identity and permissions, asset ownership, and business criticality. Each hop is a relationship between two of those, so a missing layer truncates paths and produces false dead ends. Identity data matters most and is most often absent, because role assumptions and service account permissions are configuration rather than vulnerabilities and never appear in scanner output.

Q: Does attack path analysis replace CVSS?

A: No, and it should not. CVSS remains a useful description of how damaging a flaw could be under worst-case conditions. Attack path analysis supplies what CVSS cannot: whether the flaw is reachable, what it connects to, and where the route terminates. Together they answer both halves of the question. Either alone produces a distorted queue.

Key Takeaways

• A complete route to regulated data can consist of several individually non-critical conditions spread across different tools, teams, and queues.
• Chaining is documented, not theoretical. CISA has described threat actors combining an authentication bypass rated CVSS 8.2 with a command injection flaw to reach unauthenticated remote code execution on internet-facing gateways (CISA advisory AA24-060B).
• Attack path analysis adds context no severity score can produce: whether an exposure is reachable, what it connects to, and whether multiple weaknesses form a viable route to a critical asset..
• Paths converge. One over-permissioned role or one missing segmentation rule often sits on dozens of routes at once, so cutting a chokepoint removes more risk than closing dozens of individual findings.
• Exploitation of vulnerabilities is now the leading initial access vector at 31 percent of breaches, up from 20 percent, and edge devices rose from 3 percent to 22 percent of that activity (Verizon 2026 Data Breach Investigations Report).