用途
该技能为漏洞赏金发现提供一个提交前的结构化验证框架。典型使用时机包括：发现潜在漏洞之后、撰写完整报告之前；不确定某发现是否值得提交时；发现看似有效但影响存疑时；想判断低危发现能否通过漏洞链提升时；收到 triage 返回 Informational 或 N/A 想理解原因时；以及在最终提交前审阅报告草稿质量时。
主要能力
该技能依次执行以下流程并汇总为最终裁决：
-
7 问题关卡（7-Question Gate）：逐题回答 YES 或 NO，7 题必须全部为 YES 才能继续，任一 NO 立即 KILL。问题涵盖：是否有真实 HTTP 概念验证而非纯理论推理、影响是否被项目政策接受、受影响资产是否明确在范围内、是否无需特权或管理员权限即可利用、是否非已知或已记录行为、能否证明超出“技术上可能”的影响、是否不在始终被拒清单上。
-
始终被拒清单（Always-Rejected List）：对照清单逐项比较，命中即自动 KILL，与第 1 步结果无关。完整清单见 REFERENCE.md，包含 14 种发现类型。
-
漏洞链需求评估：部分发现单独无效，但与另一漏洞链式组合后有效甚至高危。判断发现是否可独立成立，或需要链式伙伴（BV_CHAIN_PARTNER）。若需要但未提供，则裁决为 NEEDS CHAIN。常见涉及 Open Redirect、Self-XSS、Clickjacking、CSRF、IDOR 等。
-
4 道提交前关卡：每道关卡有通过阈值，未通过产生 NEEDS IMPROVEMENT 而非 KILL，修复后可重跑。
- 技术关卡（5 项）：PoC 在干净浏览器配置或全新会话中可用、可用第二个测试账户的 cookie/token 复现、至少 3 个编号明确的复现步骤、每步说明 HTTP 方法/端点/头/正文及预期与实际响应、不依赖无法可靠复现的竞态条件。
- 范围关卡（4 项）：确认确切域名/IP 在范围页列出、确认漏洞类别不在排除清单、确认端点非第三方服务、若为移动应用确认测试版本与当前发布版一致。
- 影响关卡（4 项）：写出一句话业务影响陈述、计算 CVSS 3.1 分数且与演示影响一致、影响陈述引用具体产物、影响与实际利用相称而非理论最坏情况。
- 质量关卡（5 项）：报告遵循平台模板结构、每个关键步骤附截图或 HTTP 日志、不包含真实用户 PII、技术术语附一句话解释、标题不超过 120 字符并含漏洞类别+资产+一行影响。
-
CVSS 3.1 严重性评估：使用 REFERENCE.md 中的快速参考（AV/AC/PR/UI/S/C/I/A 指标权重、严重性分级带及示例、分数合理性检查）计算与可演示影响相符的分数。
-
最终裁决输出：综合所有关卡结果给出 SUBMIT、KILL、NEEDS CHAIN 或 NEEDS IMPROVEMENT。SUBMIT 时附带严重性等级、报告标题和发送前清单。
使用方式
该技能为决策框架，无需外部工具。需提供输入变量：BV_FINDING（发现描述，必填）、BV_ASSET（资产，必填）、BV_VULN_CLASS（漏洞类别，必填）、BV_POC_STEPS（复现步骤数，必填）、BV_IMPACT（一句话业务影响，必填）、BV_AUTH_REQUIRED（none/user/admin，必填）、BV_PROGRAM_SCOPE_URL（范围页 URL，可选）、BV_CHAIN_PARTNER（链式漏洞，可选）。需要至少一对 HTTP 请求/响应证明行为，并了解目标项目的范围页与政策页（如 HackerOne、Bugcrowd、Intigriti 等）。
适用场景
适用于漏洞赏金提交前的发现验证，帮助安全研究人员判断发现是否有效、是否在范围内、是否有足够影响、报告质量是否达标，以及低危发现是否需要链式组合。最终裁决语义为：SUBMIT 表示发现有效、在范围内、有影响、质量达标，立即提交；KILL 表示无效或超出范围，丢弃并记录为研究笔记；NEEDS CHAIN 表示需与其他漏洞链式组合才有效，需寻找链式伙伴并重新验证；NEEDS IMPROVEMENT 表示发现有效但报告质量不足，修复标记项后再检查关卡。
限制
资料未提供具体的错误案例之外的功能边界、支持平台数量或性能数据。已知注意点包括：CVSS 只是起点而非契约，项目方可能应用内部严重性映射，CVSS 7.5 可能按 Medium 计酬；始终被拒清单反映各大平台上持续被返回 N/A 的模式；NEEDS CHAIN 并非死路，许多高危和严重发现由两个低危发现构成；若资产为共享基础设施，不要同时提交给多个项目；收到 Informational 或 Duplicate 后，下次提交类似发现前应重跑此关卡以找出差距。资料未提供价格、收费或平台兼容性信息。