vulnerability-validation

To filter false positives from security scan findings, analyze per-finding reachability and attacker input control to determine if the vulnerable code path is actually exploitable. This classifies results into CONFIRMED, LIKELY, FALSE_POSITIVE, or NEEDS_MANUAL_REVIEW, cutting wasted time on incorrect reporting.

Vulnerability validation is the process of confirming whether security scan findings are actually exploitable in a specific codebase. It assesses reachability from attacker source to sink, verifies mitigations against the threat model, and produces CVSS 3.1 scores with proof-of-concept details for confirmed vulnerabilities.

Verify exploitability by tracing attacker control from source to sink and checking for existing sanitization or mitigations. For confirmed vulnerabilities, generate a proof of concept and CVSS 3.1 scoring, outputting the exploitation paths and PoC details into a validated-findings.json file.

Yes, you need a threat model file to validate security findings accurately. The validation process requires reading a threat model to verify mitigations against repository-specific contexts, ensuring that reachability and exploitability assessments align with your defined security boundaries.

You should run vulnerability validation after a commit security scan and before opening issues or blocking pull requests. Validating HIGH and CRITICAL findings ensures that only true vulnerabilities with confirmed exploitation paths are escalated, preventing incorrect reporting.

Reachability analysis determines false alarms by tracing whether an attacker can actually reach the vulnerable code path. It classifies reachability as EXTERNAL, AUTHENTICATED, INTERNAL, or UNREACHABLE, filtering out findings where attackers lack the input control to trigger the vulnerability.