Vulnerability Verification
The process of validating a reported security finding to determine whether its asserted weakness genuinely exists, followed by separate assessment of reachability, exploitability, and risk treatment.
Primary question: What is vulnerability verification and how does it differ from initial detection?
Direct answer
Vulnerability verification is the post-detection lifecycle that includes validity confirmation, reachability and exploitability assessment, risk treatment decisions, and post-remediation fix verification — going beyond initial detection to confirm genuine weaknesses and validate that remediation was effective.
Vulnerability verification is the post-detection lifecycle that begins with validity confirmation and extends through reachability assessment, exploitability evaluation, risk treatment, and post-remediation fix verification. Detection identifies potential weaknesses; verification confirms whether they are genuine and whether remediation was effective.
Verification is followed by separate steps: reachability assessment (is the path accessible?), exploitability assessment (can an attacker produce a security impact?), and risk treatment (remediation, mitigation, acceptance, or exception). These steps are distinct from validity assessment.
Definitions
Vulnerability verification
The process of confirming whether a reported security finding's asserted weakness actually exists under the defined validation criteria. Verification establishes validity — it does not prove production exploitability.
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.
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 validation, 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 validation- 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:
Separate verification (optional)
Second opinion validation- 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 or automated triage tools examine the finding's code context and data flow.
- The finding is assessed for validity — does the asserted weakness actually exist?
- If validated as a true positive, the weakness is assessed for reachability, exploitability, severity, and business impact, then assigned for risk treatment.
- If validated as a false positive, it is documented with rationale and dismissed.
- For high-severity or ambiguous findings, optional separate verification provides additional evidence.
- 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
- 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 establishes validity, not production exploitability. 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 exploitability separately from validity
Relationship: related-toVulnerability Prioritization with Code Context
How validated findings are prioritized for risk treatment
Relationship: related-toValidate SAST Findings
How to validate individual SAST findings for validity
Relationship: related-toCanonical terms used: Vulnerability verification; Finding validation; True positive verification; Validity 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