Verified Vulnerabilities

Every SAST finding Trace produces today is verified at the code level — the engine articulates the attack vector, traces the data flow, and substantiates the exploit scenario with code citations. That's already a higher bar than rule-based scanners can clear.

Verified Vulnerabilities pushes that bar further. For findings where it's safe and feasible to do so, Trace will run the exploit against your application — in a sandbox or against a staging environment you provide — and capture a recorded proof of exploitation. The vulnerability gets stamped with not just "this is real" but "here is the request that exploited it."

The animation below walks through what this looks like end-to-end: cloning the repository, starting the application, signing in as a normal user, sending the exploit payload, and confirming the privilege escalation.

What changes

For supported finding types, the vulnerability record will include:

• A reproduction artifact — the exact request, payload, or sequence of operations that triggered the issue.
• A recorded session — depending on the finding type, this is HTTP traffic capture, a video of the browser flow, or a transcript of the agent's exploitation steps.
• A confirmed impact — the data, capability, or access actually gained, rather than what the engine inferred from static analysis.
• A "verified live" badge in the dashboard, paralleling how Secrets findings already work today.

Findings that can't be safely reproduced (anything that could cause data corruption, persistent state changes, or production impact) won't be verified through exploitation. They'll still ship with the same code-level verification that today's SAST findings have.

What we expect to support at launch

The first iterations of Verified Vulnerabilities will focus on web-application classes that can be reproduced cleanly against an isolated target:

• Injection (SQL, command, template) where the attack surface is reachable via HTTP and side effects can be contained.
• Cross-site scripting (XSS) — reflected, stored, and DOM-based.
• Authentication and authorization bypasses — IDOR, missing authz checks, role-confusion bugs.
• Server-side request forgery (SSRF) and open redirects.
• Deserialization vulnerabilities where the payload effect can be observed.

Findings outside this scope continue to ship as today — verified at the code level, with full threat-model context, but without an exploitation artifact.

How the environment works

Trace runs the exploit against a target you designate — typically a staging or pre-production stack that mirrors your production configuration. You don't grant Trace access to production for verification. The reproduction artifact gets stored alongside the vulnerability so you (and any auditor) can see exactly what was triggered, in what environment, with what payload.

For organizations that don't have a runnable staging environment, Trace will support a sandbox mode where the engine spins up a containerized copy of the relevant service from your repository for the duration of the verification.

Why this matters

A verified vulnerability closes the gap between "the scanner says this is real" and "here is the request that exploited it." Triage stops being a debate. Remediation becomes verifiable. Auditors get evidence they can actually inspect.

This level of confidence has historically required an internal pentest team or a hired pentest firm. Verified Vulnerabilities makes it continuous, automated, and available across your entire codebase.

If you're an existing Trace customer and want early access to the beta, reach out to the Trace team.