The challenge in finding exploit chains is not finding individual vulnerabilities. Scanners are good at that. The challenge is determining whether two or more individual findings are connected in a way that makes the combination exploitable when neither one alone would be. That requires understanding application topology: what components can reach what other components, under what conditions, and through what paths.
Manual penetration testers build this topology model in their heads during an engagement. They explore the application, read the code, probe the API, and accumulate a mental map of how data flows, where trust boundaries exist, and which misconfigurations connect to which entry points. The mental model is the testing substrate; everything they test is informed by it. The limitation is that building this model takes time, and maintaining it as the application changes is not feasible between quarterly engagements.
What we built at Strix is a system that constructs and maintains this topology model computationally, then uses it to drive path-finding across code, API endpoints, and cloud configuration simultaneously. This article explains the technical approach and where its limits are.
The Application Graph: Building the Testing Substrate
The first step is constructing a unified graph representation of the application. The nodes in this graph are application components: API endpoints, functions and methods, data stores, cloud resources (IAM roles, S3 buckets, Lambda functions, EC2 instances), and external service integrations. The edges are the possible interactions between them: function calls, HTTP requests, data reads and writes, trust relationships in IAM policies, network reachability defined by security groups and VPC routing.
The graph is populated from several data sources in parallel. Static code analysis extracts the call graph, data flow paths, and identifies where user-controlled input enters the application. OpenAPI specifications or dynamic endpoint discovery builds the API surface map. Cloud configuration APIs (AWS Config, Terraform state, CloudFormation templates) provide the cloud resource graph including IAM policy evaluation results. DNS and network configuration adds the connectivity layer.
The result is a heterogeneous graph that spans layers most security tools treat separately. A node that is an API endpoint is connected to the function that handles it, which is connected to the database query it executes, which is connected to the IAM role that governs its database access, which is connected to other resources that role can reach. A vulnerability at any node can be understood in terms of what it enables access to via that chain of connections.
Path-Finding From Entry to Impact
With the graph constructed, exploit chain discovery becomes a path-finding problem. For each entry point (unauthenticated API endpoints, public-facing services, dependency vulnerability injection points), the system runs path-finding algorithms toward high-value target nodes: database tables containing PII, secret stores, IAM roles with broad permissions, execution environments that could be used for lateral movement.
Not all paths in the graph are exploitable. A path that goes from an API endpoint through an authentication check through a properly scoped database query to a data store does not represent an exploit chain. The authentication and authorization checks are nodes in the graph that constrain traversal. The path-finding algorithm incorporates exploitability assessments at each step: is this authentication check bypassable through a known technique, is this authorization check implemented consistently across all code paths that reach it, is this IAM boundary enforced at the cloud control plane or just in application logic.
When the system identifies a path from entry point to high-value target where all intermediate steps are either unprotected or potentially bypassable, that path becomes a candidate chain for dynamic verification. The dynamic verification step actually tests the exploitation: can user A access user B's resource through this endpoint, does this SSRF reach the metadata service, does this input path allow file inclusion.
Cross-Layer Chain Discovery: Where the Interesting Results Are
The findings that a purely code-focused scanner or a purely cloud-configuration scanner would never surface are the cross-layer chains. These require the unified graph to see.
A specific example pattern we see regularly: an application has an SSRF vulnerability in its file preview feature. The SSRF was found and rated Medium by a previous scan because the analyst did not check whether the SSRF could reach internal addresses. In the graph, the service running the file preview feature is an EC2 instance. The EC2 instance has an IMDSv1 metadata endpoint accessible from its network namespace. The instance's IAM role has permissions including secretsmanager:GetSecretValue on several secrets. The graph shows a path: SSRF in file preview endpoint, to metadata endpoint, to IAM credential retrieval, to Secrets Manager, to database credentials. The SSRF is now the first link in a chain that reaches production database credentials. That finding needs to be on the Critical list for immediate attention.
None of the individual components of that chain are unusual. SSRF vulnerabilities exist in file handling code. IMDSv1 is still common on older EC2 instances. IAM roles with Secrets Manager permissions are normal. The chain emerges from the combination, and the combination is only visible when you have a unified graph that spans the code and cloud layers.
The Limits of Automated Chain Discovery
There are categories of exploit chains that automated path-finding cannot find, and being clear about this matters for how you use any automated security tool including ours.
Business logic chains require understanding intended behavior, not just data flow topology. A chain where an attacker manipulates a discount code in a way that the code validation logic does not correctly handle requires understanding what the correct validation behavior is supposed to be. The graph can identify the data flow from user input to discount application logic. It cannot determine whether the discount logic correctly handles edge cases without a specification of correct behavior to evaluate against.
Chains that exploit timing relationships, race conditions in concurrent operations, require testing under specific concurrency conditions that are hard to reproduce deterministically. The graph can identify functions that modify shared state, but identifying whether the concurrent modification creates an exploitable race condition requires dynamic testing under timing constraints.
Novel vulnerability techniques are also a limit. The path-finding algorithm incorporates exploitability assessments based on known vulnerability patterns. A genuinely novel technique that has not been previously characterized will not be in the model. This is the same limitation that every pattern-based detection system has, and it is why skilled human red teams remain valuable for finding what automated systems miss.
What the Graph Enables That Scans Do Not
The practical advantage of the graph-based approach over point-in-time scanning is that the graph can be updated continuously as the application changes, and path-finding can be re-run against the updated graph immediately. A new endpoint added to the codebase appears in the graph when the code is committed. If that endpoint connects to a chain that reaches a high-value target through unprotected steps, that is surfaced before the endpoint ships to production.
The graph also enables what we think of as impact-scoped prioritization: every finding in the system is scored not just on its individual severity but on the length of the highest-impact chain it enables. A Medium-severity SSRF that is the entry point for a chain reaching credential stores is prioritized above a High-severity injection that reaches only a low-sensitivity data table. The graph makes the context explicit rather than leaving it to the analyst's intuition.
This does not make automated chain discovery a replacement for adversarial human testing. It makes it a complement that provides continuous coverage between manual engagements and ensures that the manual testing team's time is focused on the high-impact areas the automated system identifies rather than re-covering ground the automated system already handles.