Skip to main content

Findings

A white-box pentest draws its findings from both parts. The source part finds latent issues and the code that explains them, and the live part confirms which of those issues an attacker can reach. The Checklist and report mark each result as Code, Live, or Both, so a source-only result is never presented as if the live target confirmed it.

Classes detected​

The findings combine what each part 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.

When live testing refutes a candidate, it does not become a finding. A source issue that has no live counterpart in the tested target, or that no request can demonstrate, may still be published as a code-only finding under its source component. It carries a Code marker and makes no claim about the running target.

Evidence​

A finding marked Both combines the two 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 captured request and response that proved the issue, with the check AISafe ran on the response. Headers keep their values, including Authorization and Cookie, so you can replay the request exactly as it was sent. Each body is kept as a text preview of up to 4,096 characters.
  • 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. See Triage: severity levels.
  • Status starts as open. Your reviews move it to confirmed, false positive, accepted risk or duplicate. AISafe sets fixed or not fixed when it re-tests the finding. See Concepts: Finding.

A white-box pentest deduplicates and triages its findings. When two audits reach the same issue at the same place, AISafe makes them one finding and tests it once. Several live-proved instances of a single underlying weakness become one finding with systemic scope and retain the proof for each instance. You review findings in the findings list in the dashboard: filter by severity or status, confirm the real ones, and reject the rest. See Triage.