‍

Why graph-based risk models mirror the future of software testing

Identity risk has become one of the most difficult problems for security teams to reason about. Modern environments accumulate users, roles, service accounts, policies, trust relationships, and ephemeral credentials at a scale that static access reviews were never designed to handle. These reviews provide a moment-in-time snapshot, but the real exposures emerge from the paths those identities create over days and weeks, not from any single entitlement on the day of review.

Recent research makes this gap clear: more than 60% of enterprise breaches now involve excessive or outdated access rights that static reviews failed to catch, largely due to permission drift and interim privilege changes.

This is the same failure mode we see in complex software systems. Reviewing individual components can confirm that each piece follows policy, but it reveals little about how those components behave when they interact. Identity systems are no different: what matters is the sequence of steps an attacker can take: the lateral moves, the inherited permissions, the chained trust relationships.

This is where attack graphs come in. They provide a behavioral understanding of risk by mapping how identities, privileges, and systems connect in practice. Instead of asking “Is this permission valid?”, attack graphs help teams ask: “Where could this lead? What paths does it create? What sequence of steps would an attacker take?”

Dynamic systems, whether software or identity, require evaluation that reflects how they behave, not just how they are configured. Attack graphs bring that behavioral lens to identity security in the same way that modern testing brings it to software: by examining real paths, not isolated artifacts.

What attack path modeling looks like in practice

Attack graphs map the routes an attacker could actually take through an environment, from their first foothold to the systems and data that matter most. Instead of listing who has access to which resource, they show how identities, privileges, and systems connect - and how those connections can be chained into real attack paths.

You can think of this as building a living map of lateral movement and privilege escalation. Microsoft’s Defender for Identity, for example, uses lateral movement paths to show how attackers can move from non-sensitive to sensitive accounts and highlight the most vulnerable identities so teams can close those paths before attackers reach domain dominance. Microsoft Learn

Tim Bahlke, Chief Technology Officer at Davidson’s, points out how quickly the ground is shifting:

"The pace of AI's evolution, this year alone, is mind boggling."

That pace doesn’t just create new tools; it creates new service accounts, new automations, and new privilege relationships. Static reviews fall behind almost immediately. Attack path modeling is one way for security teams to keep up with the rate of change, by focusing on how identities can be used in sequence, not just how they are configured on paper.

In practice, modeling starts by identifying all the ways an attacker could move from entry points to critical assets: direct permissions, inherited rights, service account relationships, and trust links between systems. Michael Downs, Chief Technology Officer at Evolving Solutions, sees many organizations struggling with how they approach this kind of complexity:

"This is a great summary of why so many organizations are struggling to get to real ROI with AI. Attributing too much ability to LLMs, often times when simpler solutions, such as automation or discreet AI solutions would provide better results, is missed opportunity for improvement and true ROI."

Attack graphs aren’t simple to implement, but they provide clarity that simpler tools often miss. They don’t replace security judgment; they give teams a clearer picture of where that judgment needs to be applied.

Consider a common pattern: a user with modest direct permissions can impersonate a service account, which has elevated privileges on an intermediate system that in turn has access to a critical database. None of those individual permissions look obviously dangerous in isolation. The risk only becomes visible when you see the full path.

Mark Virag, Chief Technology Officer at Permaplate, uses a musical metaphor that fits well here:

"As he [Keith Jarret] played, he listened to how the [broken] piano was performing, adapted, and improvised around its shortcomings. (...) This is my favorite story about “making do” and overcoming adversity."

Attack path modeling demands the same kind of adaptive thinking. The environment is never static. New applications, infrastructure changes, and access requests continually reshape the graph. Teams have to listen for how the “instrument” is behaving — where new paths appear, where existing controls no longer hold — and adjust their approach accordingly.

The visualization side of this work matters as much as the underlying analysis. Graph views give security teams a way to see how a change in one area can open up routes somewhere else. Instead of treating identity risk as a long list of permissions to review, they can track the specific attack paths that matter and decide where intervention will have the greatest impact.

Why identity risk accelerates in modern environments

Identity systems change faster than traditional controls can track. Cloud adoption, new SaaS applications, ephemeral compute, and automation workflows all create shifting privilege relationships that static access reviews were never designed to capture. Risk now emerges from how roles, tokens, and service accounts interact over time, not from the individual entitlements teams review manually.

Phil Eschallier, Chief Technology Officer at RCH Solutions, captures this shift toward complexity:

“The need is greater than ever before for creativity further up the compute stack where more complex challenges exist.”

Identity risk increasingly resides in that complexity layer, where permissions recombine across services and trust links form unintentionally. Angie Rothen, CTO at Hanson Dodge, describes the organizational reality this creates:

“There are too many critical functions for one person to do all these critical roles capably.”

No single engineer or manual review cycle can reason through the volume and velocity of privilege relationships present in modern environments. The only reliable way to understand exposure is to evaluate how identities behave in context.

Tim Pirie, CTO at CGI, highlights the mindset teams need as these environments evolve:

“Often our mistakes can become our best lessons and result in our greatest growth.”

Identity teams discover the most meaningful risks by observing real behavior, not by assuming how access “should” work. Attack path modeling supports that learning by showing where privilege chains form and how changes ripple across the environment as systems evolve.

From visibility to action

Mapping identity pathways is only useful if teams can act on what they uncover. Modern environments generate thousands of potential access routes, but only a fraction represent meaningful risk. The challenge is distinguishing between theoretical vulnerabilities and the paths an attacker could actually use.

Attack path modeling helps teams prioritize by showing which sequences of privileges lead to high-value assets and which require conditions unlikely to occur in practice. This shifts identity security from reviewing permissions in isolation to understanding how privilege chains form and which ones matter most.

Operationalizing this insight requires more than visibility. Teams need processes for deciding what gets fixed, how quickly, and by whom. They also need guardrails to ensure new integrations or role changes don’t recreate the same paths they just eliminated. The highest-performing teams treat attack paths as a living system: something they monitor, adjust, and refine continuously. The same shift is happening in software, where teams rely on behavior-based testing and continuous evaluation platforms like QA.tech to validate how systems evolve in real conditions.

When organizations connect visibility to action, identity risk becomes manageable rather than overwhelming. Attack path modeling provides the structure for that shift, helping teams focus their effort where it has the greatest effect.

Why attack paths mirror modern software testing

Attack path modeling and modern software testing address the same underlying challenge: systems have become too dynamic and interconnected for static evaluation to be effective. In both domains, the real risks emerge not from individual components but from the paths created when they interact.

Identity exposures form through privilege chains, sequences of actions or relationships that create unintended access. Software failures follow the same pattern: issues appear when services, APIs, data flows, and user actions combine in ways no isolated test would reveal. Both require evaluation methods that focus on behavior and real-world execution rather than documentation or configuration alone.

Graph-based models bring identity security the equivalent of behavior-driven testing. They show how the system behaves as a whole, reveal the specific conditions that make certain paths risky, and give teams a structured way to intervene before those paths become exploitable. This mirrors how engineering teams validate software today: by running systems, observing behavior, and refining based on what actually happens.

Teams that adopt attack path modeling gain the same advantage modern testing practices provide: a clearer understanding of how complex systems behave in motion and a faster way to surface and remediate issues before they matter. 

Systems become more resilient when teams observe their actual behavior and refine controls around what they learn.

The mindset that connects attack graphs and modern testing

Both attack path modeling and modern software testing were born from the same realization: complex systems rarely fail at the point where teams expect. The meaningful signals appear in the paths systems take during real use — the interactions, transitions, and combinations that no static review can anticipate.

In identity programs, this means looking beyond individual entitlements to understand how privilege chains emerge over time. In software, it means validating how services behave as they interact with real inputs, real data, and real user flows. The disciplines are different, but the underlying logic is shared: observable behavior reveals more about risk than configuration ever will.

Attack graphs provide identity teams with a way to see these behaviors clearly. They show where access can accumulate, how trust relationships shift, and which sequences of steps lead to sensitive systems. Behavior-driven testing serves the same purpose in software development, giving teams a structured way to understand how systems evolve and where unexpected pathways appear. QA.tech reinforces this mindset by helping teams validate behavior continuously and adjust as systems change.

Organizations that internalize this perspective gain a structural advantage. They build practices around observing how systems operate, learning from what those observations reveal, and refining controls as the environment shifts. Risk becomes something teams can act on early, not something discovered only after an incident.

‍

‍