vulnerability-validation

漏洞验证

通过评估安全问题在此代码库的上下文中是否确实可被利用，来验证安全发现。此技能会筛除误报、确认真实漏洞，并生成概念验证攻击代码。

何时使用此技能

• 运行 commit-security-scan 后 —— 在创建问题或阻止 PR 前验证发现
• HIGH/CRITICAL 级别的发现 —— 优先验证严重发现
• 修补前 —— 在投入修复工作前确认漏洞确实存在
• 安全审查 —— 深入验证特定发现

前置条件

• .factory/threat-model.md 必须存在（由 threat-model-generation 技能生成）
• security-findings.json 必须存在（由 commit-security-scan 技能生成）

输入

输入	说明	必填	默认值
发现文件	security-findings.json 的路径	是	security-findings.json
威胁模型	威胁模型的路径	否	.factory/threat-model.md
发现 ID	要验证的特定发现（以逗号分隔）	否	所有发现
严重性筛选条件	仅验证严重性达到或超过此级别的发现	否	所有严重性

操作说明

对每项要验证的发现执行以下步骤：

步骤 1：加载上下文

1. 读取 commit-security-scan 生成的 security-findings.json
2. 读取 .factory/threat-model.md，了解系统上下文
3. 根据输入确定要验证的发现

步骤 2：可达性分析

对每项发现，确定是否可以访问存在漏洞的代码：

1. 追踪入口点

   • 外部用户能否访问此代码路径？
   • 哪些 HTTP 端点、CLI 命令或事件处理器会导向此处？
   • 访问此代码是否需要身份验证？

2. 梳理调用链

   • 从入口点开始，追踪到存在漏洞的代码的路径
   • 记录调用链中的每次函数调用
   • 记录必须满足的分支条件

3. 对可达性分类

   • EXTERNAL —— 可从未经身份验证的外部输入访问
   • AUTHENTICATED —— 需要有效的用户会话
   • INTERNAL —— 只能从内部服务访问
   • UNREACHABLE —— 死代码或受条件阻止

步骤 3：控制流分析

确定攻击者能否控制存在漏洞的输入：

1. 确定来源

   • 被污染数据从何处产生？
   • HTTP 参数、文件上传、数据库查询还是环境变量？

2. 追踪数据流

   • 从来源追踪数据到接收点（存在漏洞的函数）
   • 记录每个转换或验证步骤
   • 记录任何清理、编码或类型转换

3. 评估攻击者的控制能力

   • 攻击者能否完全控制输入？
   • 是否存在长度限制、字符限制或格式验证？
   • 数据是否经过任何清理？

步骤 4：缓解措施评估

检查现有安全控制是否能阻止攻击：

1. 输入验证

   • 输入到达存在漏洞的代码前是否经过验证？
   • 应用了哪些验证规则？

2. 框架保护

   • 框架是否提供自动保护？（例如 ORM 参数化、React XSS 转义）
   • 是否已启用保护并正确配置？

3. 安全中间件

   • 是否存在 WAF 规则、速率限制或其他控制措施？
   • CSP 标头或其他浏览器保护措施是否适用？

4. 参考威胁模型

   • 检查威胁模型中与此威胁类型对应的“现有缓解措施”部分
   • 确认缓解措施确实已落实

步骤 5：可利用性评估

确定利用漏洞的难度：

评级	标准
EASY	无特殊条件，使用标准工具和公开已知的技术
MEDIUM	需要特定条件、时机或串联多个漏洞
HARD	需要内部知识、罕见条件或高级技术
NOT_EXPLOITABLE	理论上存在漏洞，但实际上无法利用

考虑以下因素：

• 攻击复杂度
• 所需权限
• 是否需要用户交互
• 影响范围

步骤 6：生成概念验证

对于已确认的漏洞，创建概念验证：

1. 构造利用载荷

   • 创建能展示该漏洞的最小载荷
   • 使用无害载荷（不会造成实际损害）

2. 记录请求

   • HTTP 方法、URL、请求头、请求正文
   • 或 CLI 命令、文件输入等

3. 描述预期行为与实际行为

   • 应发生什么（安全行为）
   • 实际发生什么（存在漏洞时的行为）

PoC 结构示例：

{
  "payload": "' OR '1'='1",
  "request": "GET /api/users?search=' OR '1'='1",
  "expected_behavior": "Returns users matching search term",
  "actual_behavior": "Returns all users due to SQL injection"
}

步骤 7：计算 CVSS 评分

根据以下指标分配 CVSS 3.1 评分：

指标	选项
攻击向量（AV）	网络（N）、相邻（A）、本地（L）、物理（P）
攻击复杂度（AC）	低（L）、高（H）
所需权限（PR）	无（N）、低（L）、高（H）
用户交互（UI）	无（N）、需要（R）
影响范围（S）	未改变（U）、已改变（C）
机密性（C）	无（N）、低（L）、高（H）
完整性（I）	无（N）、低（L）、高（H）
可用性（A）	无（N）、低（L）、高（H）

示例：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1（严重）

步骤 8：对发现进行分类

根据分析结果，对每项发现进行分类：

状态	含义
CONFIRMED	漏洞真实存在且可利用
LIKELY	可能可以利用，但无法完全验证
FALSE_POSITIVE	实际上并非漏洞（请说明原因）
NEEDS_MANUAL_REVIEW	需要由人工安全专家审核

步骤 9：生成输出

创建 validated-findings.json：

{
  "validation_id": "val-<timestamp>",
  "validation_date": "<ISO timestamp>",
  "scan_id": "<from security-findings.json>",
  "threat_model_version": "<from threat-model.md>",
  "validated_findings": [
    {
      "id": "VULN-001",
      "status": "CONFIRMED",
      "original_severity": "HIGH",
      "validated_severity": "HIGH",
      "exploitability": "EASY",
      "reachability": "EXTERNAL",
      "existing_mitigations": [],
      "exploitation_path": [
        "User submits search query via GET /api/users?search=<payload>",
        "Express router passes query to searchUsers() handler",
        "Handler passes unsanitized input to SQL template literal",
        "PostgreSQL executes malicious SQL"
      ],
      "proof_of_concept": {
        "payload": "' OR '1'='1",
        "request": "GET /api/users?search=' OR '1'='1",
        "expected_behavior": "Returns users matching search term",
        "actual_behavior": "Returns all users due to SQL injection"
      },
      "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "cvss_score": 9.1,
      "validation_notes": "Confirmed via code tracing. No input validation or parameterization."
    }
  ],
  "false_positives": [
    {
      "id": "VULN-003",
      "original_severity": "MEDIUM",
      "reason": "Input is validated by Joi schema in middleware before reaching this code. Schema enforces UUID format which prevents injection.",
      "evidence": "See src/middleware/validation.js:45 - Joi.string().uuid()"
    }
  ],
  "needs_manual_review": [
    {
      "id": "VULN-005",
      "original_severity": "HIGH",
      "reason": "Complex data flow through message queue. Unable to fully trace if sanitization occurs in consumer service."
    }
  ],
  "summary": {
    "total_analyzed": 10,
    "confirmed": 5,
    "likely": 2,
    "false_positives": 2,
    "needs_manual_review": 1,
    "by_severity": {
      "CRITICAL": 1,
      "HIGH": 3,
      "MEDIUM": 1,
      "LOW": 0
    }
  }
}

成功标准

满足以下条件时，技能即告完成：

• 已分析所有指定的发现
• 每项发现都有状态（CONFIRMED、LIKELY、FALSE_POSITIVE、NEEDS_MANUAL_REVIEW）
• 已记录已确认发现的利用路径
• 已为已确认发现创建概念验证利用代码
• 已为误报提供明确的理由
• validated-findings.json 是有效的 JSON
• 已计算已确认发现的 CVSS 评分

验证

完成前运行以下检查：

# Verify output exists and is valid JSON
cat validated-findings.json | jq . > /dev/null && echo "✓ Valid JSON"

# Check all findings have status
jq '.validated_findings | all(.status)' validated-findings.json

# Check confirmed findings have PoC
jq '.validated_findings | map(select(.status == "CONFIRMED")) | all(.proof_of_concept)' validated-findings.json

# Check false positives have reasoning
jq '.false_positives | all(.reason)' validated-findings.json

调用示例

验证所有发现：

Validate the security findings from the last scan.

验证指定发现：

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

仅验证 HIGH/CRITICAL：

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

使用指定文件进行验证：

Validate findings in security-findings.json using threat model at .factory/threat-model.md.

参考资料

• CVSS 3.1 计算器：https://www.first.org/cvss/calculator/3.1
• OWASP 测试指南：https://owasp.org/www-project-web-security-testing-guide/
• 示例：validation-examples.md（位于此技能目录中）
• 上游：commit-security-scan 技能