AgentSkillsCN

vulnerability-validation

在运行 commit-security-scan 后，通过评估漏洞的可利用性、过滤误报，并生成概念验证漏洞利用，来验证安全检测结果。此步骤可在 commit-security-scan 执行完成后使用，以进一步确认潜在漏洞。

SKILL.md
--- frontmatter
name: vulnerability-validation
description: Validate security findings from commit-security-scan by assessing exploitability, filtering false positives, and generating proof-of-concept exploits. Use after running commit-security-scan to confirm vulnerabilities.
version: 1.0.0
tags: [security, validation, exploitability]

Vulnerability Validation

Validate security findings by assessing whether they are actually exploitable in the context of this codebase.

When to Use This Skill

  • •After commit-security-scan - Validate findings before creating issues or blocking PRs
  • •HIGH/CRITICAL findings - Prioritize validation of severe findings
  • •Before patching - Confirm vulnerability is real before investing in fixes
  • •Security review - Deep-dive validation of specific findings

Prerequisites

  • •.factory/threat-model.md must exist (from threat-model-generation skill)
  • •security-findings.json must exist (from commit-security-scan skill)

Inputs

InputDescriptionRequiredDefault
Findings filePath to security-findings.jsonYessecurity-findings.json
Threat modelPath to threat modelNo.factory/threat-model.md
Finding IDsSpecific findings to validate (comma-separated)NoAll findings
Severity filterOnly validate findings at or above this severityNoAll severities

Instructions

Step 1: Load Context

  1. •Read security-findings.json from commit-security-scan
  2. •Read .factory/threat-model.md for system context
  3. •Identify which findings to validate based on inputs

Step 2: Reachability Analysis

For each finding, determine if the vulnerable code is reachable:

  1. •

    Trace entry points

    • •Can external users reach this code path?
    • •What HTTP endpoints, CLI commands, or event handlers lead here?
    • •Is authentication required to reach this code?
  2. •

    Map the call chain

    • •Starting from the entry point, trace the path to the vulnerable code
    • •Document each function call in the chain
    • •Note any branching conditions
  3. •

    Classify reachability

    • •EXTERNAL - Reachable from unauthenticated external input
    • •AUTHENTICATED - Requires valid user session
    • •INTERNAL - Only reachable from internal services
    • •UNREACHABLE - Dead code or blocked by conditions

Step 3: Control Flow Analysis

Determine if an attacker can control the vulnerable input:

  1. •

    Identify the source

    • •Where does the tainted data originate?
    • •HTTP parameter, file upload, database query?
  2. •

    Trace data flow

    • •Follow the data from source to sink (vulnerable function)
    • •Document each transformation or validation step
  3. •

    Assess attacker control

    • •Can the attacker fully control the input?
    • •Are there length limits, character restrictions?

Step 4: Mitigation Assessment

Check if existing security controls prevent exploitation:

  1. •Input validation - Is the input validated?
  2. •Framework protections - Does the framework provide automatic protection?
  3. •Security middleware - Are there WAF rules, rate limiting?
  4. •Reference threat model - Check existing mitigations

Step 5: Exploitability Assessment

RatingCriteria
EASYNo special conditions, standard tools, publicly known technique
MEDIUMRequires specific conditions, timing, or chained vulnerabilities
HARDRequires insider knowledge, rare conditions, or advanced techniques
NOT_EXPLOITABLETheoretical vulnerability but not practically exploitable

Step 6: Generate Proof-of-Concept

For confirmed vulnerabilities, create a proof-of-concept:

  1. •Craft exploit payload
  2. •Document the request
  3. •Describe expected vs actual behavior

Step 7: Calculate CVSS Score

Assign a CVSS 3.1 score based on:

  • •Attack Vector (AV): Network, Adjacent, Local, Physical
  • •Attack Complexity (AC): Low, High
  • •Privileges Required (PR): None, Low, High
  • •User Interaction (UI): None, Required
  • •Scope (S): Unchanged, Changed
  • •Confidentiality (C): None, Low, High
  • •Integrity (I): None, Low, High
  • •Availability (A): None, Low, High

Step 8: Classify Finding

StatusMeaning
CONFIRMEDVulnerability is real and exploitable
LIKELYProbably exploitable but couldn't fully verify
FALSE_POSITIVENot actually a vulnerability (document why)
NEEDS_MANUAL_REVIEWRequires human security expert review

Step 9: Generate Output

Create validated-findings.json with:

  • •Validation metadata
  • •Validated findings with exploitation paths
  • •False positives with reasoning
  • •Needs manual review items
  • •Summary statistics

Success Criteria

  • • All specified findings have been analyzed
  • • Each finding has a status
  • • Confirmed findings have exploitation paths documented
  • • Confirmed findings have proof-of-concept exploits
  • • False positives have clear reasoning
  • • validated-findings.json is valid JSON
  • • CVSS scores are calculated for confirmed findings

Example Invocations

Validate all findings:

code
Validate the security findings from the last scan.

Validate specific findings:

code
Validate findings VULN-001 and VULN-002 from security-findings.json.

Validate only HIGH/CRITICAL:

code
Validate all HIGH and CRITICAL severity findings from the security scan.