Most penetration test reports present findings as a list, sorted by severity. Critical findings at the top. Medium findings in the middle. Low and informational findings at the bottom. Risk rating methodology applied uniformly to each finding in isolation.
This presentation model has a structural flaw: vulnerabilities do not operate in isolation. A medium-severity IDOR finding that reveals another user's account ID, combined with a low-severity endpoint that accepts account IDs without authorisation verification, combined with an informational finding that leaks a session token format, is not three separate findings. It is a full account takeover path. Individually, none of the three would trigger emergency remediation. Together, they represent the highest-priority finding in the engagement.
Attack path analysis is the process of mapping how individual findings chain into breach routes: the sequences of steps an attacker would follow, using the findings as stepping stones, to reach a high-value target. It is the difference between a finding list and a threat model.
Most content about attack path analysis discusses the infrastructure version: graph-based modelling of how an attacker moves laterally through a network, from an initial foothold through misconfigured cloud resources, overpermissioned service accounts, and unpatched systems, to a crown-jewel asset. Tools like Tenable, XM Cyber, and Rapid7 specialise in this version. It is genuinely valuable for understanding network-layer exposure.
This post covers the application-layer version: how individual findings from a web application penetration test chain together into breach routes through the application itself. The logic is the same (attacker observation, stepping-stone progression, high-value target) but the medium is application code, API endpoints, authentication logic, and session handling rather than network topology and cloud resource permissions.
The application-layer version receives far less attention, which is why applications are consistently the most breached attack surface despite heavy investment in network security controls.
Severity ratings applied to individual findings serve a useful triage function. A critical CVSS score helps prioritise which vulnerability to patch first. But CVSS scores were designed to rate the inherent severity of a vulnerability class, not the risk of a specific finding in a specific application context. Three problems arise when severity ratings are applied to individual findings without chain analysis.
The underestimation problem: A finding that appears medium or low in isolation may be the first step of a critical attack path. An unauthenticated information disclosure finding that returns internal user IDs has a low inherent severity: it exposes data but does not itself enable access to protected resources. If the application also has an IDOR vulnerability in its user management API, those user IDs are the exact input the IDOR requires to access any user's account. The information disclosure is not low severity in this application. It is the entry point to full account takeover.
The overestimation problem: A critical finding in a completely isolated system with no path to any valuable asset has lower actual business risk than a medium finding in the system that processes all customer payments. CVSS base scores do not incorporate business context or asset criticality. Chain analysis that maps findings to the assets they can reach provides a more accurate risk picture than CVSS alone.
The remediation prioritisation problem: If findings are remediated in severity order without chain analysis, it is possible to spend significant engineering effort on critical findings that lead nowhere while leaving lower-severity findings that are the linchpin of a high-impact attack chain. Chain analysis identifies which finding to fix first based on its role in the highest-impact chains, not its individual severity score.
These examples illustrate how individually-moderate findings combine into high-impact breach routes. Each is constructed from finding classes that appear regularly in application penetration test results.
Finding A (Informational): The password reset endpoint returns different error messages depending on whether an email address exists in the system. "Email not found" vs "Reset email sent." This is a standard username enumeration finding, typically rated informational or low.
Finding B (Low): The user profile API endpoint (/api/users/{id}) includes the user's primary email address in its response when called by an authenticated user. This is a minor information disclosure, rated low.
Finding C (Medium): The password reset flow does not enforce rate limiting on the token submission endpoint. A valid reset token can be brute-forced because the application does not lock the account or throttle submission attempts after repeated failures. This is a medium finding: it requires a valid reset to have been initiated, so it is not directly exploitable without additional preconditions.
The chain: An attacker enumerates valid email addresses using Finding A. They initiate password resets for those accounts. They brute-force the reset tokens using Finding C. They now control those accounts. Using those compromised accounts, they call the profile API (Finding B) to harvest additional email addresses that were not in the original enumerated list. They repeat the cycle across the expanded email list.
The chain severity: Critical. Full account takeover of arbitrary users at scale. No individual finding above medium. Without chain analysis, this path is invisible in a severity-sorted finding list.
Finding A (Low): The user account creation endpoint accepts additional parameters that are not in the documented API schema. The application silently ignores most undocumented parameters, but the behaviour with specific parameter names has not been fully audited.
Finding B (Medium): The application assigns user roles based on a role field in the user creation request. For standard user registration, the frontend sends role: "user". The API does not validate that the role value is within the set of values a self-registering user is permitted to claim.
Finding C (Informational): An error message during failed administrator login attempts references the role value "admin" in its error response body, confirming the role name used internally.
The chain: An attacker observes Finding C to identify the internal role name. They register a new account using Finding B, including role: "admin" in the registration payload. The application assigns the admin role to the new account. The attacker now has administrator access from a self-registered account.
The chain severity: Critical. Privilege escalation to administrator from unauthenticated state in three steps. Finding C (informational) is the intelligence step; Finding B (medium) is the actual vulnerability; Finding A (low) is the discovery step that confirms parameter injection is processed. All three were necessary to construct the path.
Finding A (Medium): The invoice download endpoint (/api/invoices/{id}/download) does not validate that the authenticated user owns the invoice with the requested ID. This is a classic IDOR: access control applied at authentication level but not at object ownership level.
Finding B (Informational): Invoice IDs are sequential integers beginning at a low number. The current authenticated user's most recent invoice has ID 48,293. This means invoice IDs from 1 to approximately 48,292 likely exist and are accessible.
Finding C (Low): The API does not implement rate limiting on the invoice download endpoint. Requests can be made at high speed without triggering any throttling or account lockout.
The chain: An attacker authenticates as any legitimate user (obtained through a phishing campaign, a credential breach, or even a free trial account). They iterate through invoice IDs 1 through 48,292 using Finding A with the speed permitted by Finding C, downloading every invoice. They exfiltrate the financial data of every customer who has ever used the platform. Finding B (informational) provided the count; Finding A (medium) provided the access; Finding C (low) provided the throughput.
The chain severity: Critical. Mass exfiltration of all customer financial records from a single compromised or free-trial account. The IDOR (medium) is the exploitable finding, but without the enumeration range (informational) and the rate-limit absence (low), the scope of the exfiltration would be limited and the finding would remain medium.
Understanding why automated scanners produce finding lists rather than attack chains requires understanding how they operate.
A DAST scanner maintains a single authenticated session. It fires payloads at accessible inputs, observes responses, and matches those responses against known vulnerability signatures. Each test is independent. The scanner does not accumulate context between tests: it does not remember that the response to test 47 contained an internal user ID that could serve as the input to test 312. It has no mechanism for carrying information discovered in one test into the design of a subsequent test.
This is not a limitation that can be engineered around through more sophisticated payload libraries or broader coverage. It is structural. Building an attack chain requires:
State accumulation: The value discovered in one test must be remembered and applied to a different test later in the session. The username enumeration finding (Finding A in Chain 1) must produce an output (a valid email address) that becomes the input to the next step.
Cross-endpoint reasoning: The connection between a finding in one endpoint and a vulnerability in a different endpoint must be identified. The information disclosure in the profile API (Finding B in Chain 1) enables the attack against the password reset endpoint (Finding C in Chain 1) only if the tester understands that both are connected to the same underlying target: the user account.
Hypothesis formation: The tester must form a hypothesis about what the chain might look like before executing it. "If I can enumerate user emails, and if the password reset is brute-forceable, then I can take over those accounts" is a hypothesis about a chain. It requires understanding application logic, not just firing payloads.
Multi-step execution: The chain must be executed as a sequence, with each step's success determining whether the next step is attempted. A scanner that executes tests independently cannot execute a sequence where Step 3 depends on the success of Step 2.
How DAST compares to agentic AI pentesting on real-world coverage maps the DAST gap across vulnerability classes. The security gaps DAST and standard testing misses covers this in the context of the broader coverage gap. Penetration testing automation: beyond scripted scans maps where different automation levels sit on the spectrum: chain construction is the capability that separates agentic testing from scripted scanning.
Agentic penetration testing accumulates context across the test session and uses that context to generate test hypotheses: the same process an expert human tester follows.
Context accumulation: When an agentic testing system observes a response that contains an internal identifier, a role name, an endpoint reference, or any other information that could serve as input to a subsequent test, it retains that information as context. The informational finding about invoice ID ranges in Chain 3 is not discarded after it is noted: it becomes a parameter for the subsequent IDOR testing.
Cross-finding hypothesis generation: When a finding is confirmed, the system generates hypotheses about what other vulnerabilities might combine with it. An IDOR finding that reveals user IDs triggers a hypothesis: "Are there other endpoints that accept user IDs and could be tested for similar access control failures?" This hypothesis drives the next phase of testing across related endpoints.
Sequential chain execution: Agentic systems can execute multi-step attack sequences where each step uses the output of the previous step. The chain from credential enumeration to account takeover (Chain 1) is executed as a sequence: enumerate, reset, brute-force, confirm access, not as three separate independent tests.
Chain severity assessment: When a chain is confirmed, its severity is assessed based on the end-state impact, not the severity of the individual findings. A confirmed account takeover path is critical regardless of whether the contributing findings were individually rated medium, low, and informational.
Agentic pentesting and continuous security validation covers the architecture in full. Broken access control: why it is still the number one web risk covers IDOR, the most chain-enabling finding class, in detail. API vulnerabilities standard penetration tests miss covers how API-layer findings feed application attack chains.
A penetration test report that includes attack path analysis presents findings in two layers:
Individual finding layer: Each confirmed vulnerability is documented with severity, proof-of-exploitation evidence, and remediation guidance. This is the standard finding format.
Chain layer: Findings that combine into attack chains are additionally documented as chains, with the chain sequence, the stepping-stone logic connecting each finding to the next, the end-state impact, and the combined chain severity. What's in a penetration testing report: a buyer's breakdown covers the full report anatomy. For chain documentation specifically, the chain section shows the path from entry point to high-value target as a sequence: Finding A enables Finding B because [reasoning]; Finding B enables Finding C because [reasoning]; together they produce [impact].
MITRE ATT&CK mapping: Application attack chains map to MITRE ATT&CK techniques and tactics. Credential access, privilege escalation, collection, and exfiltration are all tactic categories that appear in application-layer chains. Mapping chain steps to ATT&CK provides a standardised language for communicating the attack sequence to security operations teams, compliance reviewers, and technical leadership who are familiar with the framework.
Prioritisation output: The chain layer produces a prioritisation recommendation that may differ from the severity-sorted individual finding list. When a medium individual finding is the linchpin of a critical chain, it should be prioritised above isolated critical findings that lead to no valuable targets.
Attack path analysis sits within the CTEM validation stage. Continuous threat exposure management and how agentic pentesting fits in covers the full CTEM framework. In CTEM terms, chain analysis converts the prioritisation stage's output (a list of exposures ranked by individual exploitability) into the validation stage's output: confirmed breach routes ranked by business impact.
Vulnerability management automation: where AI agents fit in the pipeline covers how attack path analysis feeds the prioritisation stage of the VM pipeline with business-context-adjusted risk scores that reflect chain membership rather than individual CVSS scores.
For penetration testing services in the US that include attack path analysis as part of the standard engagement deliverable, agentic penetration testing for continuous chain discovery at deployment cadence, and PTaaS for ongoing coverage, the 10x Pentest platform covers application and API security testing with chain analysis in the findings output. See pricing or get in touch to discuss how chain analysis changes the risk picture compared to a standard finding list.
Q1. What is attack path analysis in cybersecurity?
Attack path analysis is the process of mapping how individual vulnerabilities or weaknesses chain together into breach routes: sequences of steps an attacker follows to move from an initial position toward a high-value target. In infrastructure security, attack path analysis typically maps lateral movement through network topology and cloud resource configurations. In application security, attack path analysis maps how individual findings from a penetration test chain together: an information disclosure finding that enables an authentication bypass that enables privilege escalation, or an IDOR finding combined with an absence of rate limiting that enables mass data exfiltration. The key insight of attack path analysis is that findings do not operate in isolation: the risk of a finding depends on what other findings it enables access to.
Q2. Why is severity-based prioritisation of individual findings insufficient?
Individual severity ratings assess each vulnerability in isolation without considering what other vulnerabilities it enables. A medium-severity IDOR finding that reveals user IDs has a medium inherent severity. If the application also has a brute-forceable password reset and lacks rate limiting, those user IDs are the entry point to full account takeover of arbitrary users, a critical chain assembled from medium and low findings. Severity-sorted finding lists will prioritise individual critical findings above this chain, potentially leading to engineering effort on isolated high-severity findings while the account takeover chain remains unaddressed. Attack path analysis inverts this: it identifies the highest-impact chains first, then traces back to the individual findings that form them, prioritising remediation of the chain-enabling findings regardless of their individual severity ratings.
Q3. Can automated scanners perform attack path analysis?
Standard DAST scanners cannot perform attack path analysis. Scanners operate with a single authenticated session, execute tests independently, and match responses against known vulnerability signatures: they do not accumulate state between tests, form hypotheses about how findings might combine, or execute multi-step sequences where each step uses the output of the previous one. Building an attack chain requires state accumulation (remembering values discovered in one test and using them in another), cross-endpoint reasoning (connecting findings in different parts of the application), and sequential execution (where later steps depend on earlier steps succeeding). These are capabilities of expert human testers and agentic testing systems, not signature-matching automation.
Q4. What is the difference between an attack path and an attack vector?
An attack vector is a single entry point or method by which an attacker gains initial access to or interacts with a target system: a phishing email, an exposed API endpoint, an unpatched vulnerability. email, an exposed API endpoint, an unpatched vulnerability. An attack path is a sequence of steps, potentially using multiple attack vectors, that leads from an initial position to a high-value target. A single SQL injection in a login endpoint is an attack vector. The chain from that SQL injection to credential extraction to authenticated access to admin functionality to full database exfiltration is an attack path. Attack path analysis focuses on the path rather than the individual vector, because the business impact of a vulnerability depends on what it enables in sequence rather than on what it achieves in isolation.
Q5. How does attack path analysis affect remediation prioritisation?
Attack path analysis changes remediation prioritisation in two ways. First, it identifies findings that are critical because of their role in chains, not their individual severity: a low-severity finding that is the linchpin of a critical account takeover path should be prioritised above an isolated critical finding that leads to no valuable target. Second, it identifies which finding in a chain is the most efficient point to break the chain: fixing the first finding in the chain eliminates the entire path, while fixing a later step in the chain leaves the earlier steps available for other uses. Attack path analysis produces a different prioritised remediation order than a severity-sorted finding list, and that different order is more aligned with actual business risk.
Broken access control has topped the OWASP Top 10 since 2021. Most testing misses it. Scanners cannot find authorization flaws. Here is what broken access control actually looks like and how multi-role testing finds it.
Tejas Dhokane Oct 1, 2026 
OWASP promoted software supply chain to A03 in 2025. Every result explains what supply chain attacks are. This post covers what supply chain security testing actually involves and what it finds.
Tejas Dhokane Sep 30, 2026 
The pentest report is the beginning of the security work, not the end. This guide maps the full remediation lifecycle — triage, routing, developer handoff, SLAs, retest, and compliance evidence.
Tejas Dhokane Sep 18, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
