fp-check

# False Positive Verification Not every finding is real. But dismissing a real finding as "false positive" is worse than investigating a false one. This skill provides a systematic approach to verify findings without bias. ## Verification Process ### Step 1: Reproduce the Claim Before dismissing anything, attempt to confirm: ``` FINDING: SQL injection in /api/users CLAIM: User input reaches database query unsanitized VERIFICATION: 1. Read the actual code at the reported location 2. Trace the data flow from input to sink 3. Check for sanitization/validation between input and sink 4. Check for framework-level protections (ORM, parameterized queries) 5. Attempt to construct an exploit payload ``` ### Step 2: Evidence-Based Triage | Verdict | Criteria | Evidence Required | |---------|----------|-------------------| | TRUE POSITIVE | Vulnerability exists and is exploitable | Code path + exploit scenario | | TRUE POSITIVE (mitigated) | Vulnerability exists but other controls prevent exploitation | Code path + mitigation proof | | FALSE POSITIVE (provable) | Finding is wrong due to tool limitation | Specific reason why tool was wrong | | FALSE POSITIVE (contextual) | Code is technically flagged but context makes it safe | Context documentation | | NEEDS INVESTIGATION | Cannot determine without more analysis | What additional info is needed | ### Step 3: Document the Decision ``` FINDING: [scanner/auditor finding description] SOURCE: [which tool/person reported it] LOCATION...