FAQ
Why choose a white-box pentest over a code audit alone?
A code audit reads your source and finds latent vulnerabilities with taint-flow and proof-of-concept evidence, but it never runs your application. It cannot prove an attacker can reach the bug. A white-box pentest validates the candidates against the live target, so you get findings that are both explained in the code and confirmed by a real request and response. If you only have the source and cannot run the target, stay with a Source Code Audit.
Why choose a white-box pentest over a black-box one alone?
A black-box pentest is blind. It probes the live application over HTTP and sees only what surfaces there, so it cannot reason about logic hidden behind the requests. A white-box pentest reads the source, so it finds latent issues — tainted data flows, unsafe deserialization, weak cryptography — and then reaches the live target to prove which are exploitable. If you have no source to grant, use a Black-Box Pentest.
What do I need to provide?
Two things. First, the source to read, one of three ways: a private repo from your GitHub or GitLab integration, a public repository URL, or an uploaded tar.gz archive. Second, a live target to validate against: one or more target URLs, plus optional authentication, custom headers, rate limits, and excluded paths. See Prepare your target.
What if I cannot reach a live target?
You cannot validate anything. The white-box pentest confirms its candidates against the running application, so without a reachable live target there is no runtime stage. Run a Source Code Audit instead; it produces taint-flow and proof-of-concept evidence for each finding from the source alone.
How is the sandbox isolated?
Each agent runs in an isolated sandbox with no share of filesystem or memory with other sandboxes or the host, controlled network egress, and no persistent storage. The sandbox reaches the targets you specify and no others, and it does not follow redirects outside your scope. AISafe destroys the sandbox when the run completes, with no state persisting between assessments. See Sandbox isolation.
Is my live target safe from accidental damage?
Three controls protect it. The runtime crawl respects your excluded paths, so you can shield destructive actions. You can set a rate limit to avoid overwhelming the target. The sandbox egress is allowlisted, so the agents cannot reach anything outside your scope. The validation stage also checks the target and auth flow before any serious probing, and stops early with a clear message on failure.
Do I need to give production credentials?
No. Authentication is optional. Without credentials the agents test only what is reachable anonymously. To reach authenticated areas, describe the login flow and provide test credentials — use a dedicated test account, not a real one.
Do I need to give source access? I have a live app only.
If you have no source to grant, a white-box pentest cannot run its source stage. Use a Black-Box Pentest, which probes your live application without receiving or inspecting source code.
How do I know a finding is real and not a false positive?
A triage agent re-examines each finding's evidence from both stages, confirms or rejects it, deduplicates findings that share a root cause, and assigns a confidence score. The final call is yours: from the dashboard you can confirm a finding, mark it a false positive, accept the risk, mark it a duplicate, or mark it fixed. See Triage.
What does a finding look like?
Each confirmed finding pairs the source and live evidence: the vulnerable code locations and taint flow, the exact HTTP request and the response that proves exploitation, a proof-of-concept, reproduction steps, and a suggested fix. It maps to a category (CWE or OWASP) where applicable, carries a severity, and moves through a status lifecycle you control.