Attack Path Mapping at Scale in Large SaaS Codebases

Attack path mapping is a structured methodology, not a tool or a scan. It produces a model of how an attacker moves through a system. That distinction matters more than most security teams realize until something goes wrong.

It starts with asset enumeration: every entry point, authenticated and unauthenticated endpoints, internal service interfaces, admin consoles, third-party webhooks, cloud management APIs. Then trust boundary identification, mapping where data crosses a security domain. Where does user input reach the database layer? Where does one service authenticate to another? Where does cloud IAM grant cross-account access? These boundaries are where the interesting things happen. They have no single owner and no single code file, which is exactly why they stay broken for so long.

From there, you trace sensitive data, PII, session tokens, secrets, tenant identifiers, from ingestion through processing to storage and egress. Where data travels determines where interception or manipulation becomes possible. You also map privilege transitions: every point where an identity's effective permissions can be elevated, role assignment logic, token issuance, assumed IAM roles, the sudo-equivalent API call that someone added three years ago and quietly never documented.

Then comes chaining. This is where the work either pays off or doesn't. Each individual finding gets composed into a sequence: if A is exploitable, what does that make reachable, and is that reachable thing itself exploitable? A public API endpoint leaks an internal user ID. That ID enables an IDOR in a billing microservice. The billing microservice issues a privilege escalation to an admin role. That admin role unlocks all tenant data. No individual step in that chain is a critical finding on its own. The chain is what constitutes real risk.

Finally, validation. Every proposed path must be proven with a working exploit, not inferred from pattern-matching. Unconfirmed chains are hypotheses. The difference between a finding and a path is the difference between a symptom and a diagnosis.

Almost all of this is manual work. Scanning informs it, not the reverse. Business logic flaws and authorization bypasses, the vulnerability classes most likely to anchor a real chain, are not discoverable by automated tooling. They require understanding the application's intended behavior well enough to recognize deviation. That understanding is not automatable — and anyone selling you otherwise is selling you a scanner with better marketing.

Why Blackbox and Greybox Testing Cannot Map Paths at Scale

Blackbox testing's advantage is also its ceiling. It simulates an external attacker with no prior access, a realistic perimeter simulation. But everything behind the perimeter is invisible until broken into. Internal service interactions, data flows, IAM structures, code-level logic: none of it gets examined unless a surface-level exploit exposes it. In a large SaaS codebase, the majority of the attack surface is internal. Blackbox misses most of it by design, not by failure.

Greybox improves on this. Credentials, API documentation, some architectural context: coverage of authenticated flows gets better. You can test role separation, IDOR, some logic flaws. But the tester is still blind to the actual code implementing those flows, the infrastructure configuration behind the API, the secrets management approach, and any logic that isn't documented. Documentation is always a subset of what's deployed. The gap between the two is precisely where vulnerabilities accumulate, because that gap has no owner and receives no scrutiny.

The enumeration problem compounds at scale. Without source code access, a tester must infer the existence of endpoints, parameters, and behaviors through probing. In a large codebase, this is combinatorially incomplete. Entire service interfaces remain undiscovered. An attack path that begins at an endpoint the tester never found is never assessed. That's not a skill gap; it's a structural constraint on the access model.

Chaining requires knowing what's connected. A tester cannot trace a path through an internal message queue, a background job, or a cross-service RPC call they cannot see. Blackbox and greybox engagements systematically miss these transitions. The skilled testers running those engagements know it, too. They're operating under an access model that makes those transitions structurally invisible, and there's genuinely nothing they can do about it.

The cadence problem sits underneath all of this. A test run once against a static target cannot track a codebase that changes continuously. The 2025 Verizon Data Breach Investigations Report found that vulnerability exploitation surged meaningfully year over year and now accounts for a significant share of all breaches, which reflects how quickly new paths become real breach vectors when monitoring cadence doesn't match development cadence. A quarterly or annual blackbox engagement was never going to catch that.

What Whitebox Access Actually Gives a Tester That Changes the Mapping

Source code is the complete, canonical description of everything: every endpoint, parameter, authentication check, authorization decision, data transformation, and error path. With it, a tester can enumerate the full attack surface rather than a sampled subset. Business logic is readable, not inferred. Intent can be compared directly to implementation.

Dead code, deprecated endpoints, undocumented admin interfaces: these are visible in source, and they are disproportionately vulnerable precisely because they receive less maintenance scrutiny. Nobody's monitoring the API route that hasn't been in the docs since a platform migration two years ago. That's where things go wrong quietly.

Cloud configuration access adds the other half of the picture: IAM policies, security group rules, storage bucket policies, network ACLs, service account permissions. Privilege escalation paths in cloud environments often exist entirely in configuration, not in application code. A misconfigured IAM role with overly broad permissions combined with an SSRF in the application is a classic chain. Whitebox sees it end to end. Blackbox sees only one side, if it sees the SSRF at all. The CVE Program published over 28,000 CVEs in 2025, up from roughly 25,000 in 2024 and roughly 20,000 in 2023, with a growing share tied to cloud-native components whose risks only materialize in configuration context. Without cloud config access, those risks stay theoretical until an attacker proves otherwise.

Data flow visibility changes the tenant isolation picture entirely. In multi-tenant SaaS, isolation is enforced at specific points in the data layer. Only code access reveals where those points are and whether they hold under all conditions. A missing tenant\_id check in an internal service is unreachable from the perimeter but reachable from another compromised service. Whitebox finds the internal path; everything else misses it.

Architecture documents close one more gap: the one between what was designed and what was built. Design documents reveal intended trust boundaries. Code reveals actual trust boundaries. The delta between those two is the attack surface nobody is explicitly maintaining, and it grows quietly until it doesn't.

The Vulnerability Classes That Only Surface Through Whitebox Path Analysis

Insecure deserialization is essentially impossible to identify reliably from blackbox probing. Exploitability depends on reading the serialization and deserialization logic in source. Chain it with a reachable endpoint and you can get remote code execution. Without source access, you're guessing at whether the deserialization logic even exists.

Hardcoded secrets, API keys, database credentials, signing secrets embedded in code or committed to repositories, are invisible to network-level scanners. In source, they're immediate. These are frequently the first step in a lateral-movement chain. A hardcoded AWS key in application code combined with an overpermissioned IAM role is a complete breach path. Whitebox finds both ends; anything else finds neither.

SSRF impact depends entirely on what internal infrastructure the server can reach, which means it depends on cloud topology, which only cloud configuration access provides. SSRF against a metadata service endpoint in a misconfigured cloud environment can yield instance credentials. Without the cloud config, you're confirming the SSRF exists without knowing whether it leads anywhere meaningful. That's a finding. It's not a path.

Broken object-level authorization, the broad family of IDOR variants, requires understanding the data model: what objects exist, how they're keyed, which roles should and shouldn't have access. That information lives in the ORM and schema, not in the HTTP interface. A tester probing from outside is reverse-engineering a data model that a whitebox tester can simply read.

SQL injection in internal APIs deserves particular attention. Injection points in endpoints not exposed to the public internet are only findable through source review, and they are more dangerous than surface-level injection because they sit behind authenticated trust boundaries where developers apply less scrutiny. The thinking is that nobody outside can reach this code, so it doesn't need hardening. That thinking has caused a lot of incidents. I've seen it firsthand — you could call it security through obscurity, except there's nothing secure about it.

The common thread across all of these: every class requires understanding context that only exists inside the codebase and configuration. Access is not a luxury for thoroughness; it's the prerequisite for finding what actually matters.

How Scale Changes the Tooling and Process Requirements for Path Mapping

A large SaaS codebase is dozens to hundreds of services, each with its own dependency graph, data model, and authentication assumptions. Manual analysis alone cannot enumerate the full attack surface in any reasonable engagement window. I've watched teams try, and the result is thorough coverage of one service and a vague, apologetic handwave at the rest.

Static analysis and code intelligence tools compress the reconnaissance phase. Taint analysis traces user-controlled input to sensitive sinks. Dependency graphs map inter-service calls. Automated detection flags known-bad patterns. These tools don't replace the analyst; they give the analyst a map instead of a blank page.

Cloud security posture tooling maps the IAM graph: which principals can assume which roles, which roles carry what permissions, which permission sets create escalation paths. Rendered as a traversable graph, the cloud attack surface becomes something you can actually reason about at scale, rather than something you approximate by staring at policy JSON until your eyes cross.

The graph model is the right mental framework. Treat the codebase and cloud configuration as a graph where nodes are assets (endpoints, services, data stores, IAM roles) and edges are transitions (calls, data flows, permission grants). Attack paths are paths through this graph from attacker-controlled nodes to high-value targets. This framing converts an overwhelming enumeration problem into a tractable traversal problem.

AI-assisted path enumeration accelerates candidate path generation, surfacing potential chains for human analysts to evaluate. But AI alone cannot validate exploitability. Every proposed path requires a working exploit before it becomes a finding. The human expert review is the step that converts a candidate path into a signed, audit-ready finding; it brings adversarial reasoning to the output and separates real chains from theoretical noise.

The cadence problem is persistent and underappreciated. A large codebase changes continuously. A path that didn't exist last quarter exists today because a new service was introduced or a dependency was upgraded. Pull-request-level scanning extends path monitoring into the development cycle, catching new attack surface at introduction rather than at the next annual test. The development pace and the testing pace have to match. The gap between them is where breaches happen.

What a Complete Attack Path Report Looks Like Versus a Flat Findings List

A flat findings list describes N vulnerabilities, each in isolation, with a CVSS score and a remediation suggestion. It answers the wrong question.

A path report structures findings as narratives. Each narrative identifies the entry point, traces each intermediate step, and terminates at a business-meaningful outcome: data exfiltration, tenant cross-contamination, privilege escalation to the production environment. Every step is supported by a working exploit. The path is proven, not theorized.

Risk prioritization changes completely under this model. A medium-severity finding that is step two of a critical path deserves more remediation urgency than a standalone critical finding with no viable chain. CVSS scores rate individual vulnerabilities; path analysis rates actual attacker progress. These are different measurements, and conflating them produces a misallocated remediation budget. Engineering teams have finite capacity, and a flat list sorted by CVSS reliably sends that capacity to the wrong places.

Remediation guidance in a path report targets the weakest link in the chain, often the cheapest fix that breaks the most paths. There's a real difference between telling a team "fix these twelve things" and telling them "fix this one thing and you sever three attack chains." The second framing is actionable. The first is a backlog.

Audit utility is materially different, too. A path-structured report demonstrates to auditors that controls were tested in realistic combination, not in isolation. This is directly relevant to SOC 2 CC4.1, ISO 27001 Annex A Control 8.8, and the proposed 2025 HIPAA Security Rule update requiring annual penetration testing for covered entities. Evidence of chained exploitation is stronger compliance evidence than a list of isolated findings because it demonstrates adversarial testing rather than checkbox scanning.

The red flag in a delivered report: every finding is self-contained, no cross-references, no path narratives, no discussion of what chains are possible. That is a scanner report, regardless of how it's presented. If you cannot tell from the report what an attacker would actually do with what was found, the report hasn't answered the question that matters.