Vulnerability Verification
The process of validating a reported security finding through code review, context analysis, and reachability assessment to determine whether it represents a genuine vulnerability requiring a documented risk-treatment decision.
Primary question: What is vulnerability verification and how does it differ from initial detection?
Direct answer
Vulnerability verification is the process of validating a reported security finding through code review, context analysis, and reachability assessment to determine whether it represents a genuine vulnerability requiring a documented risk-treatment decision
Vulnerability verification transforms a raw finding into a verified finding through systematic examination of validity. A SAST or DAST tool reports a potential weakness, but verification determines whether the weakness is genuine and whether the reported data flow actually exists. Exploitability assessment is a separate step that follows validity confirmation. Verification is a human-driven process that may be supported by automated analysis tools.
Verification is distinct from detection. Detection identifies potential weaknesses; verification confirms whether they are genuine. A verified genuine vulnerability has been confirmed to exist under the tested conditions and requires a documented risk-treatment decision. A verified false positive has been confirmed to not represent a genuine vulnerability and can be closed with documented rationale.
Definitions
Vulnerability verification
The process of confirming whether a reported security finding represents a genuine vulnerability by examining the reported code location and data flow. Exploitability and reachability are assessed as separate steps after validity is established.
Reachability
The evidence that a vulnerable code path is accessible from an input source — that user-controllable data can flow from a weak source to a vulnerable sink through the code.
Exploitability context
The conditions required for a vulnerability to be exploitable, including network exposure, authentication requirements, user input availability, and specific configuration or state. Exploitability is assessed after validity is established.
The engineering problem
Security teams may remediate findings without verification, wasting effort on issues that are not genuine vulnerabilities.
Security teams may dismiss findings as false positives without proper verification, missing genuine vulnerabilities that require remediation.
In high-assurance environments, stakeholders may require documented verification evidence before accepting remediation decisions or demonstrating due diligence.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Code-level examination
Finding verification- Artifact
- A reported finding with code context, including the reported source, sink, and data-flow path.
- Risk
- Invalidating genuine vulnerabilities; wasting effort on false positives.
- Output
- A verified finding — confirmed as a genuine vulnerability or confirmed as a false positive — with documented reasoning.
Evidence:
Independent verification (optional)
Second opinion verification- Artifact
- A second analysis tool or separate reviewer examining the same finding.
- Risk
- Both reviewers or tools sharing the same blind spot for a particular vulnerability class.
- Output
- Additional evidence about the finding's validity that supports or challenges the primary verification result.
Evidence:
Verification workflow
- A security analysis tool reports a finding with code context.
- Security engineers examine the finding's code context and data flow to determine validity, with automated triage providing supporting context where configured.
- The finding is assessed for validity — is the reported data flow genuine?
- Reachability and exploitability are assessed separately for prioritization and risk treatment.
- Verified genuine vulnerabilities are assigned for remediation. Verified false positives are documented with rationale and dismissed.
- For high-severity or ambiguous findings, optional separate verification provides additional evidence.
- The verified finding set is used for remediation prioritization and security reporting.
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
- Verification requires security expertise and code knowledge. It cannot be fully automated.
- Two analysis tools may both miss a genuine vulnerability due to the same blind spot.
- Verification is specific to the tested conditions. A verified vulnerability may or may not be exploitable in production, depending on deployment configuration and runtime conditions.
Related knowledge
True Positive Vulnerability
What constitutes a verified genuine vulnerability
Relationship: related-toFalse Positive Vulnerability
What constitutes a verified non-vulnerability
Relationship: related-toVulnerability Exploitability Analysis
Assessing whether a verified vulnerability is exploitable
Relationship: related-toVulnerability Prioritization with Code Context
How code context informs remediation prioritization
Relationship: related-toValidate SAST Findings
How to validate individual SAST findings for accuracy
Relationship: related-toCanonical terms used: Vulnerability verification; Finding validation; True positive verification; Exploitability assessment.
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
Vulnerability verification