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.
  • HTTP request and response: the exact request (method, URL, headers, body) that triggers the vulnerability and the response that proves exploitation. You can replay it to verify the issue.
  • 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 discovering agent assigns an initial rating, and the triage pass refines it by exploitability, impact, and context. See Triage: severity levels.
  • Status starts as open and moves through your reviews: confirmed, fixed, false positive, accepted risk, or duplicate. See Concepts: Finding.

The triage pass re-examines every finding, confirms or rejects it, deduplicates by root cause, and assigns a confidence score. The findings list in the dashboard is your review queue: filter by severity or status, confirm the real ones, and reject the rest. See Triage.