Skip to main content

Findings

A white-box pentest draws its findings from both stages. The source stage finds latent issues the code explains; the live stage confirms which ones an attacker can reach. Each confirmed finding carries both sets of evidence, stitched together.

Classes detected​

The findings combine what each stage can detect.

From the static source analysis (as in a code audit):

  • Injection vulnerabilities: SQL injection, command injection, SSRF, LDAP injection, path traversal, traced from where user input enters to where it reaches a query, command, or request.
  • Authentication and authorization flaws: broken access control, privilege escalation, missing auth checks.
  • Secrets and credentials: hardcoded API keys, tokens, and passwords.
  • Cryptographic weaknesses: weak algorithms, insecure random number generation, improper key management.
  • Deserialization and serialization issues: unsafe deserialization, XML external entity (XXE).
  • Logic bugs: race conditions, business logic flaws, state manipulation.
  • Vulnerable dependencies: advisory findings anchored to the manifest or lockfile.

From the live validation (as in a pentest):

  • Injection confirmed over HTTP, including SQL injection, command injection, and SSRF, demonstrated by crafted payloads.
  • Server-side request forgery, where user input steers outbound requests to internal services.
  • Broken access control: insecure direct object references, unauthorized access, privilege escalation, tested as an authenticated user.
  • Information disclosure from verbose errors, exposed debug endpoints, or backup files.
  • Business logic flaws such as price manipulation or transaction race conditions.

Findings that the live stage cannot confirm on the running application do not become confirmed findings.

Evidence​

A white-box finding is stronger than either mode alone because it pairs both views:

  • Code locations and taint flow: the exact file, function, and line range where the issue lives, plus the full path from source to sink, including the sanitization that is missing or insufficient. This shows where the bug is.
  • Validated HTTP evidence: the request method, normalized route, response status, server-checked assertion, and response digest that proved the issue. Raw response bytes and secret header values are not stored in finding evidence.
  • Proof-of-concept: a description of how an attacker exploits the vulnerability, grounded in the actual code and confirmed by the live response.
  • Reproduction steps: a clear, step-by-step description of how to reproduce the issue, so you can hand it to the engineer fixing it.
  • Suggested fix: a concrete remediation recommendation.

Where possible, the agents map each finding to a standard category (CWE or OWASP), so you can cross-reference with your existing security tracking and compliance frameworks.

Severity and status​

Each finding carries a severity and a lifecycle status you control.

  • Severity runs from Critical to Info. The source audit assigns the rating; white-box version 1 does not run a later triage pass. See Triage: severity levels.
  • Status starts as open and moves through your reviews: confirmed, fixed, false positive, accepted risk, or duplicate. See Concepts: Finding.

White-box version 1 does not deduplicate or triage confirmed findings. Findings stay localized and un-triaged: repeated instances of one systemic weakness appear as separate findings, with no systemic scope. The findings list in the dashboard is your review queue: filter by severity or status, confirm the real ones, and reject the rest. Retaining deduplication while preserving one live disposition per candidate is planned follow-up work. See Triage.