vulnerability-validation

Name: vulnerability-validation
Availability: InStock
Author: oElberte

Validate security findings for exploitability and generate PoC details.

Updated Aug 23, 2026

Search Tags:#security #threat modeling #proof of concept #exploitability #vulnerability validation #CVSS 3.1 #false positive filtering

Ready to run

npx skills add https://github.com/oElberte/dotfiles --skill vulnerability-validation-oelberte

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: vulnerability-validation
Source: https://github.com/oElberte/dotfiles/tree/main/private_dot_factory/plugins/marketplaces/factory-plugins/plugins/security-engineer/skills/vulnerability-validation
Command: npx skills add https://github.com/oElberte/dotfiles --skill vulnerability-validation-oelberte

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It reduces wasted time and incorrect reporting by validating whether security scan findings are actually exploitable and actionable in your specific codebase.

Core Features & Use Cases

Reachability analysis: Traces whether an attacker can reach the vulnerable code path (EXTERNAL, AUTHENTICATED, INTERNAL, UNREACHABLE).
Control flow and input control: Determines whether the attacker can control the vulnerable input from source to sink and whether mitigations or sanitization exist.
Exploitability and PoC generation: Rates exploit difficulty, classifies each finding (CONFIRMED, LIKELY, FALSE_POSITIVE, NEEDS_MANUAL_REVIEW), and produces a proof-of-concept plus CVSS 3.1 scoring for confirmed issues.
Use case: After running commit-security-scan, validate HIGH/CRITICAL findings before opening issues or blocking PRs so only true vulnerabilities are escalated.

Quick Start

Ask the AI to validate all findings from the scan using the threat model at .factory/threat-model.md and produce validated-findings.json.

Frequently Asked Questions about vulnerability-validation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I filter false positives from security scan findings?▼

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.

What is vulnerability validation in software engineering?▼

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.

How do I verify exploitability and generate a proof of concept for a vulnerability?▼

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.

Do I need a threat model to validate security findings?▼

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.

When should I run vulnerability validation on my codebase?▼

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.

How does reachability analysis determine if a vulnerability is a false alarm?▼

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.