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: file.ts:42 VERDICT: [TRUE POSITIVE | FALSE POSITIVE | NEEDS INVESTIGATION] EVIDENCE: - [What you checked] - [What you found] - [Why you reached this conclusion] REASONING: [Detailed explanation of why this is/isn't a real finding] CONFIDENCE: [HIGH | MEDIUM | LOW] [If LOW, explain what would increase confidence]
Common False Positive Patterns
1. Scanner Doesn't Understand Context
Scanner says: "Hardcoded password detected" Actual code: const DEFAULT_LABEL = "password" Verdict: FALSE POSITIVE -- it's a UI label, not a credential Evidence: Variable is used only in form field label rendering
2. Framework Protection Not Recognized
Scanner says: "SQL injection in query" Actual code: db.query("SELECT * FROM users WHERE id = $1", [userId]) Verdict: FALSE POSITIVE -- parameterized query prevents injection Evidence: $1 is a parameter placeholder, userId is bound safely
3. Dead Code / Unreachable Path
Scanner says: "XSS in renderUserInput()" Actual code: renderUserInput() exists but is never called Verdict: FALSE POSITIVE -- function is dead code Evidence: grep shows no callers; function should be removed anyway WARNING: Verify it's truly unreachable, not just unused currently
4. Test Code Flagged
Scanner says: "Hardcoded API key" Actual code: const TEST_KEY = "test-key-123" in test/fixtures.ts Verdict: FALSE POSITIVE -- test fixture, not production code Evidence: File is in test directory, key is clearly a test value WARNING: Verify the key isn't a real key used in test environment
5. Intentional Behavior
Scanner says: "Insecure random number generation" Actual code: Math.random() used for UI animation timing Verdict: FALSE POSITIVE -- not used for security purposes Evidence: Used only for visual jitter in animation, no security impact
Red Flags: When "False Positive" Is Actually Real
Do NOT dismiss if:
| Red Flag | Why It Matters |
|---|---|
| "It's behind a VPN" | VPNs get compromised, zero trust is the standard |
| "Only admins can reach it" | Admin accounts get compromised |
| "The input is from our other service" | Services can be compromised too |
| "We sanitize it elsewhere" | Verify the "elsewhere" actually runs |
| "It's just a low severity" | Low severity findings chain into high impact |
| "The scanner is always wrong about this" | Verify EACH instance independently |
| "We've never been exploited" | Survivorship bias |
Verification Techniques
1. Data Flow Tracing
Follow the data from source to sink:
Source (user input) -> [validation?] -> [transformation?] -> [sanitization?] -> Sink (dangerous operation) If ANY step is missing or bypassable, it's a TRUE POSITIVE.
2. Control Flow Analysis
Check all paths to the vulnerable code:
Can the code be reached without authentication? Can the code be reached with different parameters? Can the code be reached through an alternative route?
3. Exploit Attempt
Construct a minimal proof:
Input: [specific malicious input] Expected: [what should happen if vulnerable] Actual: [what actually happens] Blocked by: [what prevents exploitation, if anything]
4. Historical Check
bash# Has this code had real vulnerabilities before? git log --grep="fix\|vuln\|security\|CVE" -- <file> # Has the scanner been wrong about this pattern before? # Check past triage decisions for this rule
Batch Triage Template
For large scan results:
markdown# Security Scan Triage - [Date] Scanner: [tool name and version] Scan target: [repo/branch/commit] Total findings: [N] ## Summary | Verdict | Count | |---------|-------| | True Positive | X | | True Positive (mitigated) | X | | False Positive | X | | Needs Investigation | X | ## True Positives (Action Required) 1. [SEVERITY] file.ts:42 -- [description] -- [recommended fix] ## False Positives (Documented) 1. file.ts:88 -- [reason it's false positive] ## Needs Investigation 1. file.ts:120 -- [what additional info is needed]
Integration with vibecosystem
- security-reviewer agent: Use fp-check after running security scans
- sast-scanner agent: Triage Semgrep results with this methodology
- code-reviewer agent: When flagging potential issues, verify first
- verifier agent: Include false positive check in quality gate
Inspired by Trail of Bits fp-check plugin.
