用途
本技能是通用报告撰写技能的配套内容，专门用于 Bugcrowd 平台。当提交需要处理 VRT（漏洞评级分类）映射、OOS 条款反驳或按程序规则选择目标资产时使用。通用多平台报告模板请使用 report-writing 技能；决定是否上报前的七问门控请使用 triage-validation。
一、VRT 类别选择：搜索与回退策略
Bugcrowd 提交表单要求选择一个 VRT 节点，下拉框默认严重性绑定在该节点上，选错会导致表单自动给出较低优先级（常见为 P4），而实际影响可能是 P3 或 P2。
注意：VRT 默认严重性并非固定常量。Bugcrowd 会跨版本修订 VRT 结构，各程序也可通过自身优先级配置重新映射默认值。示例中的 P 值只是撰写时的典型基线，应始终阅读当前表单为该程序实际自动建议的严重性。
搜索层级（按顺序尝试，选仍能准确描述该漏洞的最高严重性匹配）
- 漏洞的主类别，如 IDOR、XSS、SSRF、认证绕过、2FA 绕过
- 暴露的数据类别，如 PII、敏感数据暴露、机密泄露
- 被绕过的控制，如访问控制失效、认证绕过
- 端点类型，如 no rate limiting on form > login、no rate limiting on form > change password
- 通用父节点，如 Server Security Misconfiguration > Other、Broken Access Control > Other
选择原则
绝不要为获得更高默认严重性而选择歪曲漏洞的 VRT，分诊人员会重新指派并可能标记为失实陈述。做法是：选择最具体且准确的 VRT，若默认值不对则使用手动严重性覆盖。
常见映射
- 改密码缺少 2FA 导致账户接管：首选 Broken Authentication & Session Management → Second Factor Authentication (2FA/MFA) → Bypass；回退 Broken Auth → Authentication Bypass → Other
- 无速率限制的密码预言机：首选 Broken Authentication & Session Management → Authentication Bypass → Other；回退 Server Security Misconfiguration → No Rate Limiting on Form → Login
- GraphQL introspection / APQ 允许列表绕过：首选 Server Security Misconfiguration → Other（正文说明理由）；回退 Broken Access Control → Other
- 用户名 → 真实姓名 PII 枚举：首选 Sensitive Data Exposure → PII Leakage / Disclosure of Secrets → Non-Corporate User；回退 Broken Access Control → Other
- 安全敏感操作的状态失同步：首选 Application-Level DoS → Other（以 state-desync 叙述框定）；回退 Server Security Misconfiguration → Other
- 认证流程端点的邮件/短信轰炸：首选 Server Security Misconfiguration → No Rate Limiting on Form → Email-Triggering / SMS-Triggering；回退 Server Security Misconfiguration → No Rate Limiting on Action
- 令牌暴力破解（改邮箱 OTP、密码重置）：首选 Broken Authentication → Authentication Bypass → Other；回退 Server Security Misconfiguration → No Rate Limiting on Action
若没有合适的 VRT，选择 Server Security Misconfiguration → Other 或 Broken Access Control → Other，并在正文开头加一段「VRT mapping note」，说明所选项是最接近的匹配以及漏洞实际是什么。
二、手动严重性覆盖
表单允许将 Technical Severity 与 VRT 默认值分开手动设置。表单原文指出：VRT 建议的严重性不保证就是应用到提交上的严重性。
何时覆盖：链式结果比单一漏洞类别更严重（链 → 账户接管）；VRT 类别只是近似且默认值不反映实际影响等级；程序自身的 Focus Areas 明确以高于 VRT 默认的严重性列出该结果；暴露的数据类别比 VRT 示例更敏感（如真实姓名 PII 对比用户名枚举）。
如何覆盖：按上文选择最准确的 VRT；记下自动建议的严重性；在 Technical Severity 字段手动选择要申请的严重性；按第三节在正文第一部分加入严重性请求段落。
不要过度主张。P1 注水是失去分诊人员信任最快的方式。P1 应保留给无需交互的账户接管、RCE、大规模 PII 外泄、资金盗取等 Critical 桶影响。若通往 P1 需要单独的窃取 cookie 前提，则把单一原语按 P3 提交，并交叉引用明确讨论链路。
三、严重性请求段落：始终置于正文首位
当 VRT 默认低估影响时，正文第一节应为严重性请求段落，这是分诊人员读到的第一段内容，可预防看到表单中 P4 后常见的自动关闭。
模板结构
标题使用固定语句「Severity request — please review carefully before applying VRT default」。随后说明最接近的 VRT 类别及其默认严重性与赏金区间，并请求按 P[M] 评估（单独或与某提交 ID 链式）。列出三条理由，每条对应一个影响维度：为什么超出 VRT 默认示例、常引用程序自身 Focus Areas、常对比同类数据的历史赏金。可选加一段对比 VRT 默认典型示例与实际影响。
语气准则
以固定短语开头，分诊人员能识别且不会自动关闭。加粗要节制，每条理由最多一两处。不要使用「could potentially」或「may allow」，这类措辞会被降级。按准确名称引用程序自身的 Focus Areas / 已接受影响清单。交叉引用链接提交时使用完整提交 ID（UUID 格式）。
四、OOS 条款反驳模板
分诊人员有时不读报告就按 OOS 条款自动关闭。应预先加入范围内论证段，引用 OOS 条款并说明漏洞为何不符。
- 「非认证端点上的速率限制问题」反驳：当漏洞位于认证端点（登录、改密、密码校验、OTP 校验、令牌校验）时，说明该端点是典型认证原语，OOS 条款中的「非认证」限定不适用。
- 「调试信息泄露」反驳（用于 schema/introspection 类漏洞）：说明这不是调试信息问题，允许列表/内省门充当授权控制，绕过使其失效，影响是「变更面解锁」而非信息泄露。
- 「低风险信息的用户枚举」反驳：当泄露的不只是账号存在性时，说明泄露数据既非低风险也非无意义（如真实姓名、姓氏、头像等），属于 PII 泄露而非用户名枚举。
- 「理论问题 / 不可利用」反驳：当可利用性已端到端证明时，简述已证明的利用路径并列出 PoC 证据（脱敏 cookie 的 HTTP 请求、截图、脱敏 HAR 文件等）。
若只有「API 行为」观察而无完整利用路径，该漏洞属于理论性，不要提交。补齐缺失证据后重新评估。提交理论性漏洞会损害研究者平台声誉。
五、链式漏洞：交叉引用策略
程序规则：每个报告提交一个漏洞。若必须串联多个漏洞才能证明影响，可以一起提交，但需清楚说明链路。
提交策略：先确定最高严重性的链式结果（通常对应程序 Focus Areas 中的 P1/P2 示例）；先分别提交链的原语，各自按单独严重性（通常 P3/P4），并预留交叉引用占位；再提交链的消费报告，正文描述完整影响并按链式严重性（如 P1）评价；消费报告提交后回填各原语的消费报告 UUID（Bugcrowd 允许提交后编辑正文）。
交叉引用模板：在消费报告正文靠前位置列出「Chain partners（作为独立报告提交）」，逐条注明提交 UUID 与原语内容，说明各原语有独立修复面、按「一个修复 = 一个赏金」规则分开提交；在各原语正文加入「Chain context」，说明这是 M 个独立原语中的第 N 个，完整链路叙述与链式严重性记录于某提交 UUID，本单独报告按 P3 反映其个体影响。
不要做的事：不要把整段链路叙述粘贴到每个原语正文，应交叉引用；不要声称每个原语单独都是 P1；不要为链路申请单一合并赏金，程序规则意味着每个独立修复面是独立赏金，链路应作为严重性放大器而非合并请求。
六、目标选择：QA 与生产
若测试的是生产应用/API，选择生产目标，最准确，表明影响落在真实用户上；若按程序规则为非美国研究者测试 QA 应用/API，选择 QA 目标（如 Sign In - (QA)、Enrollment - (QA)），符合程序规则；若测试 QA 但无对应 QA 目标，选最接近的生产目标并在正文写明 QA 免责说明；跨资产漏洞选择漏洞起源或影响最高的资产，并在正文列出其他受影响目标。
在 QA 环境测试时，正文加入面向分诊人员的说明：按程序对非美国研究者的指示在 QA 环境测试；生产可能施加 QA 没有的额外控制，请确认生产是否运行相同解析器代码路径；所有测试限于自己的 QA 测试账号，未与其他账号交互；注明所选目标与所选 VRT，说明二者均为最接近的可用匹配，若有更合适选项请重新指派。
七、研究者侧卫生（Bugcrowd 专用）
多数 Bugcrowd 管理的程序要求研究者使用 @bugcrowdninja.com 别名作为目标上的账号邮箱，以将流量标记为友好测试。资料在此处截断，其余卫生条目暂未提供。
限制
资料未提供具体漏洞的发现、验证或利用方法，也未提供各程序的具体赏金金额、评级标准原文或平台政策完整文本；上述 P 值与赏金区间均为示例，需以当前表单与程序配置为准。