What is attack path analysis (and why a findings list isn't enough)

A scan comes back with 40 findings, sorted by CVSS score. Three critical, eleven high, the rest medium and low. Where do you start? The severity column answers "how bad is this in isolation" — it can't answer the question that actually matters: what can an attacker do with these, together?

The gap between a findings list and a real risk picture

Take three findings from a typical firewall + VPN concentrator audit, none of them individually catastrophic:

• A management interface reachable from an internal VLAN it shouldn't be (Medium)
• SNMP running with a default or weak community string (Medium)
• No lockout policy on remote-access VPN authentication (High)

Scored separately, none of these screams "fix this today." Chained together, they're a full path: brute-force the VPN (no lockout), land on the internal VLAN, read the device's running config over SNMP with the default string, find the management interface is reachable from there too, and now you have administrative access to the firewall itself. That's a materially different risk than "three medium/high findings" suggests — and it's invisible if you only ever look at findings one at a time.

What attack path analysis actually does

It's the same idea behind MITRE ATT&CK-style thinking, applied directly to your own findings instead of a generic technique library: take the full set of failed checks from a scan, and look for combinations where one finding's impact becomes the next finding's entry condition. Weak authentication becomes initial access. A missing segmentation control becomes lateral movement. An overprivileged service account becomes escalation. Chain enough of these and you get an actual path from "attacker has network access" to "attacker has domain admin" or "attacker has the firewall."

The output isn't another severity score — it's a narrative: step 1 does this, which enables step 2, which enables step 3, with the real finding IDs and evidence backing each step. That's a fundamentally more useful thing to hand to whoever decides what gets fixed first, because it answers "why does this matter" instead of just "how bad is this."

Why this doesn't replace a findings list — it prioritizes it

Not every finding is part of a path, and that's useful information too. A finding with no plausible chain to anything else genuinely is lower priority than one sitting in the middle of a three-step path to a critical system, even if their standalone severity scores say otherwise. Attack path analysis re-sorts the pile by "how much does fixing this actually reduce risk," which is rarely the same order as "how bad does this look by itself."

What it needs to work

This only works if the underlying findings are trustworthy — real evidence pulled from the actual config, not a guess. Chaining three real findings into an accurate attack narrative is useful. Chaining three hallucinated findings into a confident-sounding narrative is actively worse than not having one, because it looks authoritative while pointing everyone at the wrong problem. Any tool doing this needs a hard gate between "the model suggested this" and "this is backed by a real line in the config" — the analysis is only as good as what it's built on.