Source Code Assisted PentestingThe agent reads the repo before it attacks.
Hand the agent your source and it stops guessing where the input lands.
It traces the sink back to a route, builds the request that reaches it, and fires.
Trusted by security teams at
What is source code assisted penetration testing?
What changes when the agent has the code
Reading the source turns a guessing game into a targeted one.
Finds the hidden routes
Admin endpoints, debug handlers, and feature-flagged paths show up in the router even when no link points at them.
Traces sink to request
The agent follows a dangerous call back through the handler and works out which HTTP request reaches it.
Confirms by exploiting
A suspicious line in the code becomes a finding only after the agent lands the request against the running app.
Cuts the false positives
Running the exploit tells you whether the sanitizer three frames up already handled the sink that static analysis flagged.
Patches the real line
Knowing the file and the function means the fix arrives as a diff against that exact line.
Scopes to the diff
On a pull request the agent limits itself to what changed, which keeps the run short enough to gate a merge.
How the boxes compare
Three ways to scope an engagement, sorted by how much the tester knows going in.
Black box
No internal knowledge. Closest to an outside attacker, and slowest to reach anything deep.
Gray box
Credentials and some documentation. The usual shape of a commissioned engagement.
White box
Full source and architecture. Highest coverage per hour of testing.
Code assisted testing vs black box testing
Same agent, different amount of information at the start.
With source access
Black box only
With source access
Black box only
With source access
Black box only
With source access
Black box only
With source access
Black box only
With source access
Black box only
With source access
Black box only
With source access
Black box only
From issue to fix in seconds
Find critical issues, auto-validate, and auto-fix with merge-ready PRs.
SSRF via URL Parameter in /api/proxy
TL;DR
The /api/proxy endpoint accepts a user-supplied URL without validation. An attacker can access internal services, read cloud metadata, and exfiltrate credentials.
Impact
Access to cloud metadata at 169.254.169.254, potential credential theft, and internal network scanning.
Location
acme/api · proxy-handler.ts:23Severity
CVSS
8.6Fix Effort
LowDiscovered
2h agoDiscover & Validate
Pentests your entire attack surface continuously. Reproduces each finding, confirms exploitability with proof, and prioritizes by real impact.
How do I fix it?
Validate and restrict the target URL using an allowlist of permitted hostnames. Reject private/internal IP ranges and enforce HTTPS-only.
| 23 | 23 | const targetUrl = req.query.url; |
| 24 | const resp = await fetch(targetUrl); | |
| 24 | const parsed = new URL(targetUrl); | |
| 25 | if (!ALLOWED_HOSTS.has(parsed.hostname)) { | |
| 26 | throw new ForbiddenError("blocked"); | |
| 27 | } | |
| 28 | const resp = await fetch(parsed.href); | |
| 25 | 29 | return res.json(await resp.json()); |
Auto-Fix
Generates a fix, retests to confirm the vulnerability is gone, and delivers a merge-ready PR. Review, merge, done.
Frequently asked questions
Questions about white box and code assisted engagements.
Point it at your repo
Connect a repository and the first review starts right away.