| name | finding-verification |
| description | Pre-report finding verification contract. Re-checks whether each vulnerability has a real external Source, reachable Sink, bypassable or missing sanitization, and practical exploitability before final reporting. |
Finding Verification Skill
报告前真实性复核 — 逐个漏洞复查 Source、Sink、净化、可利用性，并按证据强度保留或降级。
触发条件
当 audit-report dispatch @audit-verification 并要求 [VERIFY_FINDING]、报告前复核 时加载本 skill。漏洞挖掘 agent 不应执行常规报告前复核。
复核目标
对已发现漏洞做真实性审查，不寻找新的漏洞，不扩展新的攻击面。每个 finding 必须回答：
- 是否存在真实外部 Source？
- Source 是否能到达报告中的 Sink？
- 中间链路是否有净化、参数化、权限校验或路径限制？
- 攻击者是否有实际可行的利用方法？
- 原始严重等级是否应该保持、降级或删除？
Source 真实性分级
| 等级 | 判定 | 示例 | 报告影响 |
|---|
| TRUE_SOURCE | 真实攻击者可控输入 | HTTP 参数/Header/Cookie/Body、上传文件、MQ/RPC/Webhook 入站、OAuth/OIDC 回调、低权限用户可写数据库字段 | 可支撑 Critical/High |
| CONDITIONAL_SOURCE | 条件可控输入 | 管理员可编辑配置、部署 Profile、内部 API、需高权限写入的数据 | 通常降 1 级 |
| PSEUDO_SOURCE | 弱 Source 或假 Source | 常量、测试样例、启动参数、只读配置、不可被攻击者控制的内部变量 | 通常降到 Low/Info |
| NO_SOURCE | 未找到 Source | 只有 Sink 命中，无入口和调用链 | 删除或标记误报 |
复核操作
- Read 原始 finding 中的文件和行号，确认代码仍存在。
- Read Source 节点代码，确认输入来自真实外部边界。
- 沿 Source → Transform → Sanitizer → Sink 逐跳核验，每一跳必须有实际代码。
- 检查净化点是否有效：参数化、白名单、路径规范化、协议限制、权限校验、签名验证等。
- 给出攻击者视角的最小利用路径。若无法说明利用路径，不得保持 Critical/High。
降级规则
| 条件 | severity_action |
|---|
| TRUE_SOURCE + Sink 可达 + 无有效净化 + 可描述利用方法 | KEEP |
| TRUE_SOURCE + Sink 可达，但中间链路缺 1 个关键节点 | DOWNGRADE_1 |
| CONDITIONAL_SOURCE + Sink 可达 | DOWNGRADE_1 |
| PSEUDO_SOURCE 或仅 Sink 命中 | DOWNGRADE_2 |
| NO_SOURCE、Sink 不存在、文件/行号不真实、有效净化不可绕过 | DROP |
输出格式
[VERIFY]
finding_id: {id}
verdict: VERIFIED | PARTIAL | SINK_ONLY | FALSE_POSITIVE
source_status: TRUE_SOURCE | CONDITIONAL_SOURCE | PSEUDO_SOURCE | NO_SOURCE
sink_status: CONFIRMED | UNCLEAR | NOT_FOUND
sanitizer_status: NONE | BYPASSABLE | EFFECTIVE | UNKNOWN
exploitability: PRACTICAL | CONDITIONAL | THEORETICAL | NOT_EXPLOITABLE
severity_action: KEEP | DOWNGRADE_1 | DOWNGRADE_2 | DROP
真实Source: {file}:{line} {为什么攻击者可控}
关键断点: {若链路缺失，说明缺哪一跳}
利用方法: {攻击者如何触发 Source 到 Sink}
结论: {保留/降级/删除的理由}
Critical/High finding 必须达到 VERIFIED 或 PARTIAL + TRUE_SOURCE，否则最终报告必须降级。
落库要求
复核完成后，@audit-verification 必须执行两步写库。第一步保存复核结论:
audit_save_verification(finding_id, verifier_agent, verdict,
source_status, sink_status, sanitizer_status,
exploitability, severity_action,
true_source?, key_gap?, exploit_method?, conclusion?)
第二步把复核阶段补充的事实写回最终 finding 和 sink chain:
audit_update_finding_after_verification(
finding_id,
severity?, confidence?, description?, attack_vector?, poc?,
vuln_code?, file_path?, line_number?, cwe?, cvss_score?,
sink_chain_steps?
)
写回规则:
- 若复核找到了更真实的 Source，必须用
sink_chain_steps 替换旧链路。
sink_chain_steps 必须是非空 JSON 数组；每项优先使用固定字段：
{"step_type":"Source|Transform|Sanitizer|Sink","file_path":"...","line_number":42,"code_snippet":"...","notes":"..."}- 禁止传空数组、空对象或无位置/代码/说明的步骤。若工具返回
error、saved=0 或 replaced_steps=0，必须修正参数重试，不得继续生成最终报告。
- Critical/High/Medium 至少写回一个 Source 和一个 Sink；Source/Sink 必须有文件行号或真实代码片段。
- 若复核补充了攻击者利用方法，必须写入
attack_vector。
- 若复核补充或修正了 PoC，必须写入
poc。
- 若发生降级，必须更新
severity 和 confidence，不只写 severity_action。
- 若判定
DROP 或 FALSE_POSITIVE，至少将 confidence 更新为 误报/已排除 或将 severity 更新为 Info，避免最终报告继续按高危展示。
最终 Markdown/HTML 报告必须依据更新后的 findings、sink_chains、finding_verifications 三类最终数据库结果生成；没有复核结果时只能根据 Sink 链做弱推断，并应标记为需复核。
报告统计、漏洞编号和详情分组必须使用 severity_action 后的报告等级；原始等级只作为属性保留。
