Verify exploitability
Don't guess if a SAST finding is real.
Prove it's exploitable.
A SAST finding tells you code might be vulnerable. Exploitability tells you whether an attacker can actually use it. This is the step-by-step way to move a finding from flagged to proven — and what the evidence should look like when you're done.
Static scanners predict. Proof confirms.
What does it mean for a SAST finding to be exploitable?
A SAST finding is exploitable only when an attacker can actually trigger the flagged code path and cause impact — not just when the pattern exists in source. A finding can be present and still be unexploitable if the code is unreachable, the input is sanitized, the required configuration is disabled, or an existing control blocks the attack. Static analysis flags the pattern; it can't confirm any of those runtime conditions.
All four conditions must hold for a finding to be exploitable:
- 1
Attacker access
An untrusted user can reach the entry point that exercises the vulnerable path.
- 2
Attacker-controlled data flow
Untrusted input actually reaches the vulnerable sink in the form the exploit needs.
- 3
Environment match
The configuration and version conditions the exploit requires are true in this deployment.
- 4
No neutralizing mitigation
No sanitizer, framework default, or control stops the attack before it has effect.
If any one of these is false, the finding is not exploitable here — regardless of how the scanner scored it. Reachability narrows the list, but “reachable” still isn't “exploitable.”
How to prove a SAST finding is exploitable, step by step
Moving a finding from “flagged” to proven is a repeatable procedure. Here's the loop, whether you run it by hand or let AutoProof run it for you.
- 1
Extract the exploit conditions from the finding
Pin down the exact sink, the affected version range, the required configuration, and the input the exploit needs. The library being present is not the same as the vulnerable path being reachable.
- 2
Confirm reachability and data flow
Trace whether an attacker-controlled entry point reaches the sink — including indirection through frameworks and dependencies that static call graphs routinely miss.
- 3
Build a safe proof-of-concept
Construct the minimal input that would trigger the flaw. The PoC is the difference between “this looks risky” and “this executes.”
- 4
Run it in a controlled sandbox
Execute the PoC against the code in an isolated environment — never production. If it runs, the finding is real and exploitable; if it can't, it's noise with the reasoning attached.
- 5
Capture evidence and a verdict
Record the exploitability verdict, the execution evidence, the affected code path, and a suggested fix — so the finding is defensible, prioritized, and ready to patch.
AutoProof automates this entire loop — ingesting Opengrep, Semgrep, and SARIF-compatible findings and returning an evidence-backed verdict per finding.
See the proof behind every verdict.
AutoProof reports include the original SAST finding, exploitability verdict, redacted PoC summary, execution evidence, affected code path, suggested fix, patch workflow, and retest result.
Proof Report — Fictional Sample
AUTOPROOF · Report ID AP-2026-04219
- Original SAST finding
- Semgrep · sql-injection · src/api/users.ts:42 (Critical)
- Verification result
- Exploitable — verified in AutoProof controlled environment
- Redacted PoC summary
- Crafted parameter triggers unsafe SQL concatenation in user lookup. Payload details redacted.
- Execution evidence
- DB query log + HTTP 200 response captured during sandbox run
- Patch PR / MR
- GitHub PR #482 — parameterized query, opened for developer review
- Retest result
- Not reproduced under tested conditions after patch applied
Proving exploitability, answered.
What does it mean for a SAST finding to be exploitable?
+
A finding is exploitable only when an attacker can actually trigger the flagged code path and cause impact. The pattern existing in source isn't enough; the path has to be reachable with attacker-controlled input, under matching configuration, with no mitigation blocking it.
Why can't a SAST scanner tell me if a finding is exploitable?
+
Static analysis never executes the code, so it has no runtime context — it can't confirm whether a path is reachable with attacker-controlled input or whether existing controls neutralize the issue. It predicts potential paths; it can't prove them.
Isn't reachability analysis enough to confirm exploitability?
+
No. Reachability is necessary but not sufficient. Conservative analysis marks most findings as reachable, and it can't express configuration, attacker access, or data flow — so “reachable” still leaves you triaging by hand.
What is a proof-of-concept (PoC) in this context?
+
A PoC is the minimal input that triggers the flagged flaw. Running it in a controlled sandbox turns a theoretical finding into proven, evidence-backed risk — or rules it out.
Is it safe to generate exploits to verify findings?
+
Yes, when they run in an isolated, controlled environment rather than production. AutoProof generates and executes safe PoCs in a sandbox and returns only the evidence and verdict — no live systems are touched.
How does AutoProof prove exploitability automatically?
+
It ingests Opengrep, Semgrep, and SARIF-compatible findings, generates and runs safe PoCs per finding, and returns an exploitability verdict with execution evidence and a suggested patch — so engineers only review what's proven real.
Ready to prove your SAST findings?
Start free, review a sample proof report, or book a short demo with the AutoProof team.