Pentest Overview

Trace is an AI-native whitebox penetration test. You connect your GitHub or Bitbucket organization, point Trace at an application, and Trace tests it the way an attacker would, but with full read access to the source, so it can reason about the code and the running system at the same time. Every finding is reviewed by a security expert before it reaches you, and delivered audit-ready for SOC 2 and similar regimes.

Whitebox, not black-box

A traditional black-box pentest pokes at your application from the outside and guesses at what's behind it. Trace works from the inside out: it clones the repository into an isolated, ephemeral environment and reads the actual code (the auth model, the data flows across files and services, the business logic), then uses that understanding to find and confirm real attack paths.

Because Trace understands what the code is trying to do, it reaches the vulnerabilities a black-box test never sees: multi-step business-logic flaws, broken object-level authorization, cross-tenant isolation gaps, and the subtle bugs that only make sense once you can read both the request and the handler behind it.

Findings you can trust

The thing that separates Trace from an automated scanner is what happens after detection. Every candidate finding goes through a verification pass before it reaches your dashboard: Trace articulates the attack vector, the exploit scenario, the prerequisite access, and the impact (with code citations to back it all up), and a security expert reviews it. Trace doesn't ship a finding it can't substantiate.

The result is fewer findings, but the findings you do see are ones you actually need to fix. Where it's safe and feasible, Trace validates a finding by reproducing the exploit against your live stack, which is what keeps false positives dramatically low. See Verified Findings.

What a finding contains

Every finding carries the full context an engineer needs to triage and fix it:

• Severity and CVSS. A tier (LOW, MEDIUM, HIGH, CRITICAL, INFORMATIONAL) and a CVSS score, so you can rank work and feed risk-tracking systems.
• Category and CWE. The vulnerability class and its CWE classification(s).
• Attack details. The attack vector, the exploit scenario, and the prerequisite access.
• Code context. The affected file, line range, and a snippet at the location, plus the reasoning that ties the code to the impact.
• Remediation guidance. What to change, and how to confirm the fix.

Finding lifecycle

A finding moves through a status as you work it: OPEN → IN_PROGRESS → REMEDIATED, and once Trace re-tests the fix, VERIFIED_FIXED (or VERIFIED_OPEN if the issue is still reproducible). You can also CONTEST a finding, mark it ACCEPTED_WITH_CONTROLS, or DISMISS it. Every state change is recorded with actor, action, and timestamp for audit.

Where findings show up

• The dashboard. A live view of every finding by pentest, severity, and status, with the full report attached.
• The Trace CLI. List pentests and query findings from your terminal. See the pentest commands.
• Notifications. Slack and email, so the right people hear about critical findings as they land.

On-demand by design

Pentests are manual: Trace never fires an engagement automatically. A pentest runs only when you (or the Trace team, during an engagement) explicitly start one. That keeps testing intentional and scoped: you decide which application, which environment, and when.