fp-checklisted

# 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