False Positive Vulnerability
A reported security finding that verification has confirmed does not represent a genuine vulnerability, and can be closed with documented rationale.
Primary question: What is a false positive vulnerability and how is it distinguished from a true positive?
Direct answer
A false positive vulnerability is a reported finding whose asserted weakness or data flow is not present under the defined validation criteria — it can be closed with documented rationale rather than remediation
A false positive vulnerability is a reported finding whose asserted weakness or data flow is not present under the defined validation criteria. A genuine weakness with low, conditional, or currently absent exploitability remains a true positive and is handled through risk assessment.
Distinguishing false positives from true positives requires systematic verification of validity. Automated tools may report findings based on pattern matching or incomplete data-flow analysis. Verification examines the actual code and the completeness of the reported data flow. Exploitability and reachability are assessed separately and do not determine the true-positive or false-positive classification. Only after validity is established can a finding be confidently classified.
Definitions
False positive (vulnerability)
A reported finding whose asserted weakness or data flow is not present under the defined validation criteria. A genuine weakness with low, conditional, or currently absent exploitability remains a true positive and is handled through risk assessment, not false-positive classification.
Verified false positive
A finding that has undergone systematic verification and been confirmed as a non-vulnerability, with documented reasoning. This is distinct from an unverified dismissal, which may overlook a genuine weakness.
True positive
A finding that has been verified to represent a genuine vulnerability. A true positive requires a documented risk-treatment decision according to organizational policy.
The engineering problem
Security teams may dismiss findings as false positives without proper verification, missing genuine vulnerabilities that require remediation.
Over-dismissal of findings as false positives can create a false sense of security and allow genuine vulnerabilities to reach production.
Inconsistent false-positive classification across teams can lead to unreliable security metrics and poor remediation prioritization.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Code context examination
Finding validation- Artifact
- A reported finding with code location, reported data flow, and supporting context from the analysis tool.
- Risk
- Dismissing a genuine vulnerability as a false positive without adequate evidence.
- Output
- A verified classification — confirmed false positive or confirmed true positive — with documented reasoning.
Evidence:
Independent review (optional)
Second opinion verification- Artifact
- A second reviewer or separate analysis examining the same finding.
- Risk
- Both reviewers sharing the same blind spot for a particular vulnerability class.
- Output
- Additional evidence supporting or challenging the false-positive classification.
Evidence:
Verification workflow
- A security analysis tool reports a finding with code context.
- Security engineers examine the reported data flow to determine whether the asserted weakness actually exists in the code, with automated triage providing supporting context where configured.
- The finding is assessed for validity — does the reported data flow genuinely exist?
- Reachability and exploitability are assessed separately for prioritization and risk treatment, but do not determine whether the finding is a true or false positive.
- If verification confirms the finding does not represent a genuine vulnerability, it is classified as a verified false positive and documented with rationale.
- If verification confirms the finding represents a genuine vulnerability, it is classified as a true positive and assigned for remediation.
- Verified false positives are documented with rationale and tracked to ensure consistent classification and reliable security metrics.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides SAST analysis with DerTriage and DerCodeFix available within static analysis to support finding review.
DerScanner performs static analysis and provides DerTriage and DerCodeFix, which are available within static analysis to support finding review. [derscanner-sast]
Limits of verification
- False-positive classification requires security expertise and code knowledge. It cannot be fully automated.
- A finding classified as a false positive in one environment may represent a genuine vulnerability in a different deployment configuration.
- Two analysis tools may both miss a genuine vulnerability due to the same blind spot, creating a shared false-negative pattern.
Related knowledge
Vulnerability Verification
The verification process that distinguishes false positives from true positives
Relationship: related-toTrue Positive Vulnerability
The counterpart classification — a verified genuine vulnerability
Relationship: related-toVulnerability Exploitability Analysis
Assessing whether a verified vulnerability is exploitable
Relationship: related-toSAST False Positives
Why SAST tools report findings that are not genuine vulnerabilities
Relationship: related-toSecurity Finding Validation
The broader validation process across security analysis techniques
Relationship: related-toCanonical terms used: False positive vulnerability; Verified non-vulnerability; Finding dismissal; Verified false positive.
Evidence and references
- DerScanner SAST documentationDerScanner performs static analysis of supported source and binary formats, provides configuration-file analysis, and reports and compares analysis results. DerTriage and DerCodeFix are available within static analysis.
derscanner-sast
False positive classification