The False Positive Problem
Static analysis security testing (SAST) tools work by matching source code against a library of known-risky patterns — an unchecked strcpy, a format string built from user input, a pointer used after a conditional free. Pattern matching is fast and requires no execution, which is exactly why it scales to enormous codebases. It is also why it produces a high rate of false positives: a pattern match has no way to know whether the surrounding code sanitizes the input three lines earlier, whether the branch is reachable at all, or whether a type invariant elsewhere in the program makes the "unsafe" operation provably safe. The scanner reports the match and leaves the verification work — usually the most time-consuming part — to a human reviewer.
The practical cost compounds at scale. A team running a SAST tool against a large codebase can accumulate hundreds of open findings, the majority of which triage to "not exploitable." Real bugs get lost in that volume, and reviewer fatigue sets in — the well-documented outcome of any alerting system with a high noise floor.
What Proof-Based Research Changes
Proof-based research inverts the reporting decision. Instead of asking "does this code match a risky pattern," it asks "can I make this program crash in a way a sanitizer confirms." The workflow has four stages: form a hypothesis about where the program is likely to misbehave, construct an input or harness designed to trigger that specific misbehavior, execute it against a sanitizer-instrumented build, and only then decide whether to report — based entirely on whether the sanitizer actually fired. A hypothesis that doesn't reproduce is discarded, not downgraded to "low confidence." There is no confidence score in a proof-based report, because there is no need for one: everything reported already happened.
This is the same standard independent security researchers hold themselves to when submitting to a bug bounty program or CVE request: a working proof-of-concept, not a description of a theoretical risk. Proof-based research applies that standard systematically and continuously, rather than only when a human researcher has the time to build a PoC by hand.
Zero False Positives by Construction
"Zero false positives" is a strong claim, and it is only true in a specific, narrow sense: zero false positives among reported findings, not zero missed vulnerabilities. Every candidate that reaches the reporting stage has already crashed the target under a sanitizer — there is no step after that where a false positive could be introduced, because the report is a direct restatement of an observed crash, not an inference about one. This is what "by construction" means: false positives are structurally impossible in the reporting pipeline, not merely reduced by tuning thresholds.
The tradeoff is on the recall side. Incomplete fix detection is one way to reduce that tradeoff — instead of hypothesizing blind, it targets a specific, high-probability location: the exact assumption a recent patch made. Coverage-guided fuzzing is another — instead of hand-picking inputs, it explores the input space systematically at machine speed, at over a million executions per second, discovering paths a human would never think to construct.
Proof-Based Research in Practice
GHSA-8f95-v3jq-cj86, a heap buffer overflow in pymonocypher, is a representative example of the full loop: a hypothesis about unchecked block-index arithmetic in an Argon2 implementation, a 21-line harness constructed to trigger it, a confirmed AddressSanitizer crash, and a report containing nothing more or less than what the sanitizer observed. The finding was confirmed in under two hours and patched within fifteen — a timeline that is only possible because there was no ambiguity to resolve between discovery and disclosure. The maintainer received a crash, not a theory.