How it works
A white-box pentest runs two linked parts at the same time. The source part reads your code, builds a model of it and produces candidate vulnerabilities with the code evidence that explains them. The live part tests your running application. It starts early in the run, as soon as the source part has mapped the application's entry points and the checks that guard them, and it maps the application while the source audit continues. The two parts share what they learn, and near the end the live part tests the source candidates and confirms which ones an attacker can actually reach and exploit.
Each part is itself a multi-agent workflow. The whole run works without human intervention: you start it, the agents do the work, and you review the results when they are ready. The assessment page shows the same stages as a source code audit: Understanding, Analysis, Audit, Triage and Report.
The source part: static source analysis
The agents acquire your source and build a structural model of the codebase: entry points, frameworks, data flows, and trust boundaries. This model enables taint analysis, call graph traversal, and cross-file data flow tracking.
The analysis follows data flows from source to sink, noting where user input enters the system, where the system sanitizes it (or fails to), and where it reaches a sensitive operation. The agents map authentication checks, authorization boundaries, and configuration to understand where the application enforces security. For each candidate vulnerability, an agent traces the full path from source to sink, checks for sanitization or validation that would block exploitation, and records the code evidence: the vulnerable locations, the taint flow, and a proof-of-concept description.
The source part finds what static source analysis can see and a purely black-box run cannot: latent vulnerabilities and taint flows, unsafe deserialization in library code, weak cryptography, and logic that never surfaces through HTTP. It produces candidates for live validation. If a source component is outside the tested target, a source-triaged result can remain code-only rather than borrowing live evidence from another component.
The live part: live validation
The live part runs a black-box pentest of your target alongside the source audit. It first signs in your test users, then crawls the application, following links and submitting forms to record each endpoint and parameter, respecting your excluded paths and rate limits. The source part tells it which live endpoints correspond to which code and hands it leads to test, so it knows where to probe.
After the source audit has finished and merged duplicate candidates, the live part tests each candidate the source analysis raised on an endpoint it reached. An agent crafts a payload, sends the request, and inspects the response. If the response suggests the candidate is exploitable, the agent refines the payload to confirm exploitation and capture proof, iterating until it either confirms the issue or rules it out. A candidate the live part proves carries Both evidence. A source-only finding carries Code evidence and is listed separately under its source scope; it is not described as live-confirmed.
Watching a live run
Every request the live part sends passes through a capture proxy, and you can read it while the run is still going.
The assessment page shows a running count of captured requests and the most recent one. Open Traffic from the tools list to see the full list: method, URL, status, timing, and the headers and body of both sides of each exchange. Both surfaces refresh every few seconds while the run is live. The count starts climbing early in the Understanding stage, when the live part signs in and starts mapping your application.
Sync and report
Before live validation, the workflow folds exact duplicates so one source defect buys one live test. After validation, source triage decides candidates for which live testing produced no disposition. Confirmed instances of one systemic weakness can then be consolidated before the findings are authored for the customer.
The report also includes an entry-point verification chapter. It groups the assessment by source scope, endpoint and vulnerability class. Each cell says whether its evidence came from code analysis, live testing or both, and an open cell keeps the reason it could not be decided.
The dashboard uses the same grouping in the Checklist tab. Entry points carry a Code, Live or Both marker, and an expanded cell shows its linked findings, captured live proof and the source roles matched to test roles. Business rules and disagreements between source controls and live behavior stay visible as their own cells.
Documentation, Threats, Entry points and Checklist all read the same combined application model. A required part that could not be recorded is shown as unavailable with a reason; the dashboard does not turn it into an empty section.
The live phase keeps three outcomes distinct: a supported assertion failed against a resolved transaction, the leaf produced no result, or the leaf failed. A completed leaf that produces no live disposition does not erase the source candidate; after the live attempts finish, source triage still decides it.
Why the two sources together
Each part makes up for a weakness in the other.
- A source-only audit finds a latent issue but cannot prove an attacker can reach it, because the application never runs.
- A black-box test sees only what surfaces over HTTP, so it cannot reason about the code behind the request.
Because the agents have read the code, the live part knows where to probe and does not have to explore the application blind. Probing the live target gives reached source findings proof of exploitability. The Code, Live, or Both marker tells you which evidence each result actually has.
Before you start
You need two kinds of input: the source to read, and a live target to validate against. See Prepare your target.