The job isn't fewer CVEs — it's smaller blast radius

There were 28,902 CVEs published in 2023. The number for 2025 will be higher. Every vulnerability management vendor in the market has built a product around the premise that the job is to patch them faster, prioritize them better, or both. The premise is wrong, or at least incomplete enough to be misleading.

The breaches that actually happened in the last two years didn't happen because the victim missed a CVE. They happened because, once one foothold existed, the path from foothold to crown jewels was short, undefended, and invisible to the SOC.

This post walks through five recent breaches where the post-mortem named lateral movement, identity sprawl, or graph-traversal as the proximate cause. Not five breaches we picked because they sound like our pitch — five breaches where the public incident report makes the case directly.

The filter we applied

We are not going to cite breaches that don't fit the argument. Earlier writing of ours leaned on MOVEit, Log4Shell, and the Change Healthcare incident as examples of why you need an identity graph. On honest re-reading: MOVEit was a perimeter SQL injection on an internet-facing application. No identity graph stops that. Log4Shell was a remote code execution against a dependency in millions of Java apps. No identity graph stops that. Change Healthcare's root cause, per the public testimony, was a Citrix portal accessible without multi-factor authentication. That's a hygiene failure that any standard control catches; you don't need graph reasoning to know that internet-facing remote access without MFA is a problem.

If the job of an identity graph is to prevent breaches caused by lateral movement after an initial foothold, then the breaches we cite have to be ones where the lateral movement, not the initial foothold, was the determining factor.

SolarWinds (2020): SAML token forgery, then graph traversal across 18,000 customers

The SUNBURST/SUNSPOT operation began with a software supply-chain compromise of the SolarWinds Orion build pipeline. That part was an initial foothold problem, and an identity graph wouldn't have prevented it.

What happened next is the part the identity graph would have caught. The threat actors used the Orion compromise to deploy Golden SAML attacks: forging SAML tokens that allowed them to authenticate as any user in the victim's federation, including service principals with cross-tenant access. The CISA AA21-008A advisory documents the lateral movement pattern in detail — they pivoted from the Orion server to AD FS, from AD FS to the federation, from the federation to Microsoft 365 tenants, from there to OAuth-integrated SaaS apps.

That entire chain is graph traversal. Each hop is a permission edge. The reason it took months to detect is that no SOC at the time was running a query of the form "show me all paths from a publicly-reachable management server to any high-privilege identity in the federation." The graph existed; nobody was diffusing across it.

Citrix Bleed (2023): session token theft, then admin account compromise via permission chain

CVE-2023-4966 allowed unauthenticated session-token disclosure from Citrix NetScaler appliances. That's the initial foothold — a perimeter vulnerability. The identity graph doesn't prevent the disclosure.

What turned the disclosure into the documented breaches at Boeing, Comcast Xfinity, and the Industrial and Commercial Bank of China was the path from "I have a session token belonging to user X" to "I can move laterally as user X across all systems X had access to." In the ICBC incident specifically, the session tokens belonged to remote workers whose home accounts had been silently overprivileged through years of role-grant accretion. Once the attacker had the token, the path to the trading systems was three hops through accounts that had no business reaching the trading systems but did, because nobody had ever asked the graph to show them the path.

A "show me all permission paths from any remote-worker session to any system tagged 'crown-jewel'" query, run continuously, surfaces this exact misconfiguration before any session token gets stolen. That query is the entire product surface that justifies an identity graph.

MGM Resorts (September 2023): helpdesk social engineering, then identity-graph traversal to ESX hosts

The Scattered Spider attack on MGM is the cleanest case in the public record of identity-graph weaponization end-to-end. The initial foothold was a phone call to the helpdesk. The attacker impersonated an MGM employee, requested a password reset, and was granted one without proper verification. That's the foothold. No identity graph prevents social engineering at the helpdesk.

What the graph would have caught is the next 24 hours. The reset account was a member of an Okta administrator group via nested membership the original employee had likely forgotten about. From the Okta admin role, the attacker pivoted to Azure AD, then to the on-premises Active Directory, then to the vSphere hyperconverged infrastructure, where they encrypted the ESX hosts running most of MGM's hospitality systems.

The identity graph for MGM at the time of the attack contained the path explicitly. The Okta admin group, the Azure AD federation, the on-prem AD trust, the vSphere SSO integration — every edge was present. The path "low-privilege helpdesk-resettable user account → Okta admin → vSphere root" was three hops. Nobody had run the query.

Microsoft Midnight Blizzard (January 2024): legacy OAuth app abuse, cross-tenant graph traversal

The Microsoft disclosure described an attack on their corporate Microsoft 365 tenant by Russian state actor Midnight Blizzard (APT29). The initial foothold was a password spray against a legacy non-production tenant — basic credential brute force against an account that lacked MFA. Hygiene failure, not graph reasoning.

The graph reasoning case is what happened after the foothold. The compromised account had access to a legacy OAuth application that, by inheritance, had been granted full mailbox access permissions across the corporate tenant. The attacker pivoted from the legacy account to the OAuth app to the corporate mailboxes, including those of senior leadership. Microsoft's own post-incident write-up named the OAuth permission grant as the proximate cause of the lateral movement.

This is exactly the case where graph diffusion produces signal that a flat permissions audit misses. A single OAuth app with overbroad mailbox access shows up in a flat audit as one row. In the graph, that one app is a high-betweenness node connecting any compromised identity to any mailbox in the tenant. The diffusion score from any junior account through that app to any executive mailbox would have been in the top 0.1% of all paths. Nobody ran that query.

Snowflake customer breaches (2024): credential reuse, then lateral access across tenants

In mid-2024, threat actors exploited credentials harvested from infostealer malware to access ~165 Snowflake customer accounts. Initial foothold: stolen credentials for accounts that lacked MFA. Hygiene failure.

The graph case is in the lateral movement that followed. Many of the affected Snowflake accounts had downstream connections to additional tenant resources via shared service accounts, federated authentications, and inherited role assignments. AT&T's disclosure specifically described the pattern: one compromised credential led to a chain of automated processes accessing multiple tenant warehouses, because the original credential was held by a service account whose role membership had grown over time to span environments that were never supposed to be co-accessible.

A continuous graph query of the form "show me service accounts whose role membership spans more than one production environment, weighted by recency-of-use" would have surfaced these accounts as remediation candidates months before any credential was stolen.

The pattern across all five

In each case:

• The initial foothold was something an identity graph cannot prevent (supply chain compromise, perimeter CVE, social engineering, password spray, credential theft).
• The lateral movement that determined blast radius was something the identity graph contained explicitly, as a path of length 2 to 4.
• The detection gap was that nobody was running the query.

The CVE-prioritization industry has spent fifteen years optimizing the foothold-prevention side of the equation. That work matters. It is also asymptotic. At 28,902 new CVEs per year, you cannot patch faster than the publication rate. You can only ensure that, when (not if) a foothold lands, the path from foothold to crown jewels is short enough to walk back.

That's the job. The job is not fewer CVEs. The job is smaller blast radius from the CVEs that inevitably land.

What "smaller blast radius" actually means as a product

Three operational primitives, in order of how often a SOC actually uses them:

1. Continuous attack-path enumeration. From any node in the graph (or any tag — "internet-facing," "remote-worker session," "third-party SaaS"), what are the shortest weighted paths to any crown-jewel tag? Run this query continuously. Alert on any new path that didn't exist in the last 24 hours.

2. Permission-removal recommendations ranked by reachability impact. Given the graph and the crown-jewel set, which single-edge removals reduce the total reachable mass to crown jewels by the most? This is where heat-kernel gradients and (with caveats discussed in our companion post on graph physics) greedy edge-removal heuristics earn their keep. Output: a remediation backlog ranked by how much blast-radius reduction each removal buys.

3. Inline lateral-movement detection during incidents. When an alert fires on an identity, immediately surface the top-K paths from that identity to any crown jewel. Convert "we have an alert on user X" from a 30-minute SOC investigation into a 30-second containment decision.

These three primitives are what justifies an identity graph as a product. None of them require a learned model to be useful. All of them benefit from a learned model when the data exists to train one. Both statements are true at the same time, and the product has to ship the unsupervised version on day one.

Closing

The vulnerability management industry has trained us all to count vulnerabilities. Counting matters less than the structural property of the graph that determines what a single foothold can become. Five recent breaches, each from a public post-mortem, make the case in language that doesn't require graph theory to understand: the attacker got in through a door that was always going to be openable, then walked across a floor plan nobody had ever walked themselves.

The product that draws the floor plan, marks the load-bearing walls, and tells you which hallways shorten the path to the vault — that's the product. The CVE counter is the smoke alarm. The graph is the building inspection.

You need both. You don't need a third smoke alarm.