| name | fp-check |
| description | Systematic false positive elimination for security findings. 6-gate verification, 13-item checklist, devil's advocate questioning. MANDATORY before any CVE submission. |
| priority | 100 |
| metadata | {"filePattern":["**/verdict*","**/finding*","**/poc_*"],"bashPattern":["fp-check|false.positive|verify.finding"]} |
False Positive Check — MANDATORY Pre-Submission Verification
When to Use
Before ANY finding is submitted. No exceptions. This is the final gate.
When NOT to Use
- Finding or hunting for bugs (use Hunter workflow instead)
- General code review for style/performance
- Feature development or non-security tasks
Rationalizations to Reject
| Rationalization | Why It Is Wrong | Action |
|---|
| "This pattern looks dangerous" | Pattern recognition is not analysis | Trace actual data flow |
| "Similar code was vulnerable elsewhere" | Each context differs | Verify this specific instance |
| "This is clearly critical" | LLMs are biased toward seeing bugs | Complete devil's advocate |
| "Skipping verification for efficiency" | No partial analysis allowed | Run all gates |
Step 0: Restate the Claim
Restate the vulnerability in one precise sentence. If you cannot, it's likely false.
- What: exact vulnerability type and root cause
- Where: file:line of the sink
- How: data flow from attacker input to sink
- Impact: concrete security consequence
- Who: attacker privilege level required
- Bug class: consult references/bug-class-verification.md
Half of false positives collapse at this step — the claim doesn't make coherent sense.
Route: Standard vs Deep
Standard — clear claim, single component, well-understood bug class, no concurrency.
Deep — ambiguous claim, cross-component flow, race conditions, logic bugs, or standard was inconclusive.
Start with Standard. It has built-in escalation checkpoints.
6-Gate Review — ALL Must Pass
Gate 1: Process Completeness
Gate 2: Reachability
Gate 3: Real Impact
Gate 4: PoC Validation
Gate 5: Math / Bounds
Gate 6: Environment
13-Item False Positive Checklist
| # | Check | If YES |
|---|
| 1 | README warns against untrusted input? | Gray area — document it |
| 2 | Documented/intended behavior? | FALSE POSITIVE |
| 3 | Library handles this gracefully? | FALSE POSITIVE |
| 4 | Alpha/beta/pre-release? | Unlikely to get CVE |
| 5 | JSON.parse does the same? | Show REAL crash beyond JSON.parse |
| 6 | OOM crash or caught RangeError? | RangeError = lower severity |
| 7 | Requires admin privileges? | Check if access is genuinely new |
| 8 | Exact version already patched? | DUPLICATE |
| 9 | Framework sanitizes at middleware? | FALSE POSITIVE |
| 10 | Runtime blocks this? | FALSE POSITIVE |
| 11 | >10 prior CVEs on this project? | Over-audited — proceed with caution |
| 12 | Different package with similar name? | Verify exact package |
| 13 | Only works with non-default config? | Severity drops significantly |
Devil's Advocate — 7 Questions
- Am I seeing a vulnerability because the pattern "looks dangerous"?
- Am I incorrectly assuming attacker control over trusted data?
- Am I hallucinating this? LLMs are biased toward seeing bugs everywhere.
- Am I dismissing complexity that makes exploitation impractical?
- Am I inventing mitigations I haven't verified in source code?
- Am I conflating "unsafe-looking code" with "exploitable vulnerability"?
- Would a senior security researcher at Trail of Bits agree this is real?
Verdict Format
VERDICT: TRUE POSITIVE / FALSE POSITIVE / NEEDS MORE INFO
Gates passed: X/6
Checklist flags: [list any concerns]
Devil's advocate: [key doubt and resolution]
Evidence: [concrete proof]
Confidence: HIGH / MEDIUM / LOW
References
