White-Box Pentest
White-Box Pentest combines the two assessment modes in one run. AI agents read your source code to find latent vulnerabilities and taint flows, then probe your live application over HTTP to confirm which ones an attacker can actually exploit. Each confirmed finding carries both views: the code path that is vulnerable, and the real request and response that prove it.
The white-box advantage is sight. Reading the code lets the agents see logic that never surfaces through HTTP: tainted data flows, missing sanitization, unsafe deserialization, weak cryptography. The live-target advantage is proof. Sending real requests confirms that a latent issue is reachable and exploitable, and captures evidence you can replay.
When to use it
Use a white-box pentest when:
- You have both the source code and a running application you can reach over HTTP.
- You want real, replayable proof of exploitability, not just a static analysis result.
- A vulnerability only matters to you if you know an attacker can reach it, and you want the taint-flow evidence that explains why.
For comparison, a Source Code Audit reads your code but never touches the running application. A Black-Box Pentest probes the live application but never sees your source. The white-box pentest sits between them: static reachability analysis finds the candidates, runtime probing confirms them.
What it is not
A white-box pentest needs a live runtime target. It reads your source to find candidates, but it confirms them against the running application. If you cannot run the application and give the agents a reachable URL, you cannot run a white-box pentest — use a Source Code Audit instead, and review the taint-flow and proof-of-concept evidence it produces for each finding.
Chapters
- How it works — the two-stage hybrid: source analysis, then live validation.
- Prepare your target — the source inputs and the live-target inputs you supply.
- Findings — the classes detected and the combined evidence each finding carries.
- FAQ — common questions.