该技能是面向 Bugcrowd 平台的专项漏洞报告策略，定位为通用报告撰写技能的配套内容。当研究者需要处理 VRT（漏洞评级分类）映射、对 OOS（范围外）条款进行反驳，或按项目规则选择目标资产时使用。若需要通用平台模板（HackerOne、Bugcrowd、Intigriti、Immunefi 的报告正文），应使用 report-writing 技能；若要在决定是否上报前进行 7 问筛选，应使用 triage-validation。
一、VRT 分类选择 提交表单要求选择一个 VRT 节点，下拉框默认严重性与所选节点绑定，选错可能导致表单自动给出过低优先级。技能建议按以下顺序搜索：漏洞主类（如 IDOR、XSS、SSRF、认证绕过、2FA 绕过）→ 泄露的数据类别（如 PII、敏感数据暴露、机密泄露）→ 被绕过的控制（如越权访问、认证绕过）→ 端点类型（如登录表单无限速、改密表单无限速）→ 通用父节点。原则是选择仍能准确描述漏洞的最高严重性匹配项，不得为抬高默认严重性而选择失实分类。若找不到合适节点，可选 Server Security Misconfiguration → Other 或 Broken Access Control → Other，并在正文开头加“VRT 映射说明”。技能还列出若干常见映射，如改密缺少 2FA 导致账户接管、无速率限制的密码验证、GraphQL introspection/APQ 白名单绕过、用户名到真实姓名 PII 枚举、认证端点邮件/短信轰炸、令牌暴力破解等，并提醒 VRT 默认严重性并非固定常量，会随版本和项目配置变化，应以当前表单实际建议值为准。
二、手动严重性覆盖 表单允许将技术严重性与 VRT 默认值分开设置。当链式结果严重性更高、VRT 分类仅为近似、项目 Focus Areas 明确列出更高严重性，或泄露数据类别比 VRT 示例更敏感时，可手动覆盖。操作步骤为：选择最准确的 VRT、记录自动建议的严重性、在 Technical Severity 字段手动选择请求的级别、在正文首段加入严重性申请段落。技能强调不要过度抬高，P1 仅保留给无交互账户接管、RCE、大规模 PII 外泄、资金盗取等关键影响。
三、严重性申请段落 当 VRT 默认值低估影响时，正文第一段应写严重性申请，模板以“Severity request — please review carefully before applying VRT default”开头，说明所选 VRT 及其默认 P 级，然后逐条列出影响理由，并可选对比 VRT 默认示例与实际影响的差异。语气上避免使用“could potentially”“may allow”等弱化表述，引用项目 Focus Areas 的准确名称，交叉引用时使用完整提交 UUID。
四、OOS 条款反驳 技能提供多种反驳模板：针对“非认证端点限速”条款，论证目标端点属于认证原语；针对“调试信息泄露”条款，论证这是控制绕过而非信息泄露（如 GraphQL 白名单绕过解锁 mutation 面）；针对“低风险用户枚举”条款，论证泄露的是真实姓名等 PII 而非仅账号存在性；针对“理论问题不可利用”条款，以端到端 PoC 证明可利用性。若缺乏端到端证明，技能建议不要提交，先补齐证据。
五、链式漏洞交叉引用 项目规则为“每份报告一个漏洞；若需链式展示影响可合并但需清晰说明”。技能建议先以各自独立严重性分别提交链式原语，再提交描述完整链式影响的消费者报告，并在提交后回填彼此 UUID 实现双向引用。不要在每份原语报告中粘贴完整链式叙述，也不要把每个原语都声称为 P1。
六、目标选择（QA 与生产） 技能给出选择目标下拉项的对应关系：测试生产应用/API 选生产目标；按项目规则测试 QA 选 QA 目标；无对应 QA 目标时选最接近的生产目标并在正文加 QA 免责声明；跨资产漏洞选择漏洞起源或影响最大的资产，并在正文列出其他受影响目标。QA 测试时需在“Notes for triagers”段落说明测试环境、生产可能存在的额外控制、仅使用自己的测试账号，以及所选目标与 VRT 为最接近匹配。
七、研究者侧规范 技能提到多数 Bugcrowd 托管项目要求研究者使用 @bugcrowdninja.com 别名作为目标账户邮箱，以便标记流量。资料到此中断，其余规范暂未提供。
限制说明：该技能为写作与流程指导，不提供自动化脚本；具体项目的 VRT 默认值、费率、Focus Areas 均以项目当前页面为准。