fp-check

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

• Source identified (where attacker input enters)
• Sink identified (where dangerous operation occurs)
• Complete data flow traced source to sink
• All transformations/validations documented

Gate 2: Reachability

• Attacker can reach the vulnerable endpoint
• Attacker controls the data that reaches the sink
• No auth barrier blocks access (or bypass is part of finding)
• Input is not sanitized before reaching sink

Gate 3: Real Impact

• Exploitation produces real security consequences
• Impact exceeds what attacker could already do at their privilege level
• Behavior is NOT documented/intended design
• Impact manifests in observable behavior

Gate 4: PoC Validation

• PoC runs successfully against latest version
• PoC succeeds 3/3 times (fail 3x = FALSE POSITIVE, no exceptions)
• Evidence matches claimed impact exactly
• Default configuration only

Gate 5: Math / Bounds

• For DoS: growth rate is actually exponential/quadratic (not linear)
• For overflow: values actually exceed the boundary
• For ReDoS: backtracking is catastrophic (>1s for reasonable input)
• For bombs: expansion ratio is dangerous (>100x)

Gate 6: Environment

• Runtime does NOT block this at a lower level
• Framework middleware does NOT sanitize automatically
• OS-level protections do NOT prevent exploitation
• Default security headers do NOT mitigate

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

1. Am I seeing a vulnerability because the pattern "looks dangerous"?
2. Am I incorrectly assuming attacker control over trusted data?
3. Am I hallucinating this? LLMs are biased toward seeing bugs everywhere.
4. Am I dismissing complexity that makes exploitation impractical?
5. Am I inventing mitigations I haven't verified in source code?
6. Am I conflating "unsafe-looking code" with "exploitable vulnerability"?
7. 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

• Standard Verification
• Deep Verification
• Gate Reviews
• Bug-Class Verification
• False Positive Patterns
• Evidence Templates