True Positive Vulnerability
A true positive is a reported finding whose asserted weakness genuinely exists under the defined validation criteria. Reachability, exploitability, severity, and business impact are assessed separately for prioritization and treatment.
Primary question: What constitutes a true positive vulnerability and how is it distinguished from a false positive?
Direct answer
A true positive establishes that the reported weakness exists. Reachability, exploitability, severity and business impact are assessed separately for prioritization and treatment. Low or absent current exploitability does not make a real weakness a false positive.
A true positive establishes that the reported weakness exists. Reachability, exploitability, severity and business impact are assessed separately for prioritization and treatment. A true positive does not require that exploitation conditions are currently present in production — it requires only that the asserted weakness genuinely exists under the defined validation criteria.
Low or absent current exploitability does not make a real weakness a false positive. Factors such as missing reachability, production configuration blocking exploitation, required authentication, or compensating controls belong to reachability, exploitability, exposure, and risk treatment. A genuine weakness with low exploitability remains a true positive and is handled through a documented risk-treatment decision.
Definitions
True positive vulnerability
A reported finding whose asserted weakness genuinely exists under the defined validation criteria. A true positive does not need to be currently exploitable in production to remain a true positive. It requires a documented risk-treatment decision.
Verification
The process of confirming whether a reported finding represents a genuine vulnerability by examining code context and data flow. Verification establishes validity — it does not automatically prove production exploitability.
The engineering problem
Security teams may treat all reported findings as true positives, wasting effort on false positives while genuine vulnerabilities may be dismissed prematurely.
Without structured validation, teams may incorrectly classify false positives as true positives (wasting effort) or true positives as false positives (leaving vulnerabilities unaddressed).
Automated triage tools may incorrectly classify findings. Organizations may require human review for high-severity findings, ambiguous cases, and policy exceptions as a governance policy.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Validation process
Finding validation- Artifact
- A reported finding examined for validity — whether the asserted weakness actually exists.
- Risk
- Misclassifying a true positive as a false positive; misclassifying a false positive as a true positive.
- Output
- A verified classification — true positive or false positive — with documented reasoning.
Evidence:
Risk treatment
True positive treatment- Artifact
- A verified true positive vulnerability assessed for severity, exploitability, exposure, and business context.
- Risk
- Delayed or missed remediation of verified vulnerabilities.
- Output
- A documented risk-treatment decision — remediation, mitigation, acceptance, or exception — with rationale.
Evidence:
Verification workflow
- A security analysis tool reports a finding.
- The finding is validated — does the asserted weakness actually exist?
- If validated as a true positive, the weakness is assessed for reachability, exploitability, severity, and business impact.
- A documented risk-treatment decision is made — remediation, mitigation, acceptance, or exception.
- If validated as a false positive, it is documented with rationale and dismissed.
- After remediation, fix verification confirms the weakness is no longer present.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides SAST analysis with DerTriage, which evaluates findings in context and can assign Confirmed or Rejected statuses when configured.
DerScanner performs static analysis and provides DerTriage, which evaluates findings in context and can assign Confirmed or Rejected statuses when configured. [derscanner-sast]
Limits of verification
- Validation requires security expertise and code knowledge. It cannot be fully automated.
- A finding classified as a true positive in one environment may have different exploitability 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 validation process that establishes whether a finding represents a genuine vulnerability
Relationship: related-toFalse Positive Vulnerability
The counterpart classification — a verified non-vulnerability
Relationship: related-toVulnerability Exploitability Analysis
Assessing exploitability separately from validity
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: True positive vulnerability; Verified genuine vulnerability; Finding remediation; Verified true 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
True positive treatment