The difference between what scanners count and what attackers traverse
A security scanner reports four findings.
An exposed credential. An SSRF vulnerability. A weak IAM policy. An internal service with no egress filtering.
Four findings. Four tickets. Four remediation tasks assigned to four different engineers across two sprints.
Now look at the same environment through the attacker's eye.
He does not see four findings. He sees one path.
Credential → Cloud Access → SSRF → Metadata Service → IAM Token → Internal Service → Exfiltration.
One objective. One chain. One compromise.
The scanner and the attacker are analyzing the same environment. They are arriving at fundamentally different conclusions about what it means.
That gap — between the list the scanner produces and the path the attacker traverses — is where most security programs lose the battle before it starts.
The Problem Is the Model
In March and April 2025, Wiz researchers documented active exploitation of CVE-2025-51591, an SSRF vulnerability in Pandoc, the widely used document conversion tool. The attack was not complicated. An attacker submitted HTML documents containing iframe elements whose source attributes pointed at the AWS EC2 Instance Metadata Service endpoint at 169.254.169.254. Because Pandoc rendered iframes server-side, the request originated from within the server — bypassing perimeter controls, reaching the internal metadata endpoint, and returning temporary IAM credentials.
Viewed as individual observations, three separate things were present in the affected environments: a document processing function that rendered untrusted HTML, an accessible IMDSv1 endpoint, and IAM roles with excessive scope attached to the EC2 instances. Each was a manageable finding in isolation. A CVSS score, a ticket, a remediation task.
Viewed as a graph, they were a single reachable path: SSRF via Pandoc → IMDS at 169.254.169.254 → IAM credentials → whatever those credentials could reach in the cloud environment.
Mandiant confirmed in-the-wild exploitation attempts running across multiple weeks. The attack did not require a novel technique. It required connecting three nodes that no single tool had been asked to evaluate together.
That is the model problem in concrete form.
The List Problem
Modern cybersecurity is organized around lists.
Vulnerability lists. Alert lists. Asset inventories. Compliance checklists. Risk registers. Severity-sorted findings queues.
The underlying assumption is intuitive: if we understand every component individually, we understand the system.
For inventory management, that assumption works. For security, it fails structurally — because security is not determined by the existence of components. It is determined by the relationships between them.
A credential is rarely dangerous in isolation. An API endpoint is rarely dangerous in isolation. A database is rarely dangerous in isolation. Risk emerges when relationships connect those components into a sequence an attacker can traverse.
Lists describe what exists. They are poor at describing what is connected. And connectivity — not the presence of individual findings — is what determines whether an attacker reaches his objective.
The Pandoc case illustrates this precisely. Organizations running IMDSv1 had a known configuration risk. Organizations using Pandoc to process user-supplied documents had a known attack surface. In most environments, neither condition had been escalated to critical priority in isolation. The combination was the vulnerability. The combination was invisible to any tool evaluating the conditions separately.
Systems Are Defined by Relationships
Every complex system is ultimately a network of dependencies.
Applications depend on identities. Identities depend on permissions. Permissions depend on trust relationships. Services depend on data flows. Assets depend on access controls.
The security posture of an environment emerges from these interactions — not from individual components examined one at a time.
This is why two environments with the same vulnerability count can have radically different risk profiles. The vulnerabilities may be identical. The relationships are not. An exposed credential in an environment with strict network segmentation and minimal IAM scope presents a different risk than the same credential in an environment where that identity has read access to every S3 bucket in the account.
The number of findings says nothing about this. The graph does.
SonicWall's 2025 Cyber Threat Report documented a 452% increase in SSRF attacks from 2023 to 2024, driven in part by automated tooling that maps internal network reachability at scale. The attackers are not manually probing individual endpoints. They are running graph traversal algorithms against target environments — mapping what is reachable from each foothold before deciding which path to take. The defenders, in most organizations, are still counting findings.
Attackers Already Think in Graphs
Attackers rarely ask: how many vulnerabilities exist?
They ask: what can I reach from here?
Every intrusion follows a version of the same process. Initial access creates new reachability. New reachability reveals new permissions. New permissions extend the graph. Eventually a path emerges between the attacker's starting position and a target worth reaching.
The F5 Labs analysis of a coordinated SSRF campaign running between March 13 and March 25, 2025 documented this methodology in operational detail. The attackers rotated six different query parameter names — dest, file, redirect, target, URI, URL — probing for SSRF conditions across EC2-hosted applications. They targeted four specific IMDS subpaths. They operated from IPs across two countries, maintaining operational tempo across twelve days. They were not evaluating individual findings. They were mapping reachability systematically across a target population, looking for environments where the path from the external SSRF entry point to the internal credential store was open and traversable end to end.
The attack succeeds because a path exists. Not because a finding exists.
Why Severity Misleads
This also explains why vulnerability severity frequently fails to represent actual risk.
Consider a critical-severity vulnerability affecting an isolated service with no meaningful connectivity to sensitive assets. The finding is severe. The reachable impact is bounded.
Now consider a medium-severity input validation weakness in a service that accepts user-supplied URLs and forwards them server-side. The finding appears less severe. If the server has access to the cloud metadata endpoint and carries an over-permissioned IAM role, the resulting path may reach every data store in the environment.
This is not a failure of severity scoring. Severity and risk are measuring different things.
Severity describes properties of a node — the technical characteristics of a vulnerability in isolation. Risk emerges from the graph — from the relationships between that node and everything reachable from it given the actual configuration of the environment.
When organizations treat severity as a proxy for risk, prioritization reflects scanner output rather than attacker reality. Teams spend cycles on alarming-looking findings while the paths that actually lead somewhere go unexamined.
Reachability Is the Missing Metric
The most important security question is also the least frequently asked in most remediation workflows:
What becomes reachable if this weakness is exploited?
Not: what is the CVSS score? Not: how many findings are open? Not: is this a critical or a high?
But: from this node, what can an attacker reach next? And from there? And where does the chain end?
Reachability transforms isolated observations into meaningful risk assessment. An exposed credential matters because it reaches another system. A permission matters because it enables another action. A vulnerability matters because it opens another step in a traversal.
Without reachability, findings remain disconnected facts. With reachability, they become paths — and paths are what attackers use.
The Pandoc exploitation did not require a CVSS 10.0. It required SSRF reaching a metadata service that had not been locked down, returning credentials that had not been scoped to least privilege, in an environment where nobody had asked what the combination of those three conditions made possible.
What List-Based Security Gets Wrong
Lists encourage local optimization.
Organizations reduce vulnerability counts. Close tickets. Improve compliance scores. Increase scanner coverage. Generate cleaner dashboards. These activities have value. They do not necessarily reduce systemic risk.
An organization may eliminate hundreds of findings while leaving its most dangerous attack path completely intact — because the path is not a finding. It is a relationship between findings that no individual tool was asked to evaluate.
From the perspective of management metrics, security improved. From the perspective of an attacker running graph traversal against the environment, nothing changed.
This is why breaches often appear surprising in retrospect. The warning signs were present. They existed as disconnected observations in separate queues, rather than as a connected path visible to anyone responsible for the whole.
What Graph-Based Security Changes
Graph-based security begins with a different question.
Instead of: which findings are most severe? It asks: which paths lead to compromise?
Instead of focusing on individual weaknesses, it focuses on relationships, reachability, trust boundaries, permissions, identities, and dependencies. The goal is not to discover problems in isolation. It is to understand how problems interact — and specifically, whether their interaction creates a traversable path to something an attacker would value.
This shift changes prioritization fundamentally.
A low-severity finding that connects two high-value systems through a shared credential or a trust relationship may become the highest-priority issue in the environment. A critical finding in an isolated service with no meaningful connectivity may be deprioritized without consequence.
For the first time, remediation effort can be directed at what matters to an attacker rather than what looks worst on a scanner dashboard.
Starting the Shift
The mental model comes before the tooling. Tooling that implements attack path analysis exists and is increasingly mature. But the tooling is only useful if the team operating it has internalized why finding-centric prioritization fails — and what it is being replaced with.
A practical starting point: take the last three findings your team classified as low or medium severity. Do not put them in a spreadsheet. Put them on a whiteboard. Draw them as nodes.
Then draw edges between anything that shares a credential, a trust relationship, a permission boundary, a service dependency, or a data flow.
Look for a path.
Not a finding. A path.
If one appears — if the chain from the first node reaches something sensitive through the second and third — you have just discovered the central insight of graph-based security in your own environment. You have also discovered why the findings were deprioritized: evaluated individually, none of them warranted escalation. Evaluated as a graph, they form an exploitable chain that the scanner never surfaced.
Vulnerabilities do not compromise systems.
Paths do.
