这个仓库列出了漏洞赏金项目中会出现的情景以及应当如何处理这些情景。目前，其中许多情景都是逐案处理的，这给黑客、项目所有者和平台带来了大量的不确定性和困扰。本仓库的目标是统一所有赏金平台和项目处理这些边界情况的方式。希望标准化能让各方更频繁地满足彼此的期望。
本文档是一份草案，尚未被任何漏洞赏金平台实施。在此阶段，我请求所有相关方提出意见。
请通过提交 GitHub issue 来贡献。所有合理的已提交 issue 将至少保持开放 30 天以供评论。
你的 issue 应当陈述一种观点，例如：
任何人均可在 issue 下发表评论，但评论必须具有建设性且不带情绪。辱骂行为将不被容忍。
| ID | 情景 | 解决方案 |
|---|---|---|
| 1 | 黑客提交了带有利用证明的漏洞。该漏洞在提交被分诊（triage）之前就已修复。 | 平台必须证明项目方在漏洞修复之前未曾访问该提交。如果项目方曾访问过该提交，则项目方应支付相应的赏金，否则该提交将被标记为重复。 |
| 2 | 黑客提交漏洞后，项目方回应称他们内部已知晓该问题。 | 项目方必须提供证据证明这是一个先前已知的问题，例如包含创建日期的 Jira 工单截图。如果项目方无法提供证据，则应支付赏金，否则该提交应被标记为重复。 |
| 3 | 黑客提交漏洞，但该提交被标记为另一份未充分挖掘漏洞影响的提交的重复。例如，黑客提交了一个可实现账户接管（account takeover）的完整 XSS，却与另一份仅报告 HTML 注入的提交判重。 | 第一位报告者将根据其提交的影响获得赏金；第二位报告者将根据其提交的影响减去第一位报告者已获赏金后的金额获得赏金。 |
| 4 | 黑客提交漏洞后，项目方从未回应。 | 平台支付赏金。 |
| 5 | 黑客提交漏洞，但被错误地与一份较新的报告判重。 | 平台将更改两份报告的状态以使其准确。如果付款已被错误地支付，则由错误执行分诊的组织支付赏金。对于托管式赏金项目，这通常是平台；而对于非托管式项目，这则是项目方。 |
| 6 | 黑客不认同所分配的严重性评级。 | 黑客在工单中提交理由。如果 14 天内没有回应，黑客将理由提交至平台的支持渠道。严重性升级将按每个提交分别裁定。 |
| 7 | 黑客在未经项目所有者明确许可的情况下，公开披露了先前已提交至平台的漏洞。 | 研究人员在以下情况下应能够公开披露漏洞：a) 该漏洞未被接受为有效，即已被标记为 N/A 或 Informative。b) 该漏洞已处于已解决状态 30 天以上。c) 研究人员已获得项目方公开披露的明确许可。在其他情况下，黑客将被平台封禁 30 天，并收到一封说明全部封禁理由的邮件。再次违规将导致永久封禁。 |
| 8 | 黑客提交了一个在项目范围内的漏洞，但该漏洞实际上存在于第三方服务中。 | 每个项目都应在项目简介（brief）中说明是否接受第三方系统上的漏洞。如果未作说明，则默认范围内列出的所有系统（包括第三方系统）均有效并应获得付款。 |
| 9 | 黑客提交了一个零日漏洞，该漏洞影响范围内系统，且不存在任何公开的利用代码或披露信息。 | 如果因该报告而做出了任何更改，即配置更改、将系统下线或应用 WAF 规则，则该报告应被接受并给予奖励。必须区分公开的零日漏洞利用与若非这份赏金报告、你的团队根本不会知晓的零日漏洞利用。 |
| 10 | 黑客向一个项目简介范围开放的项目提交漏洞。该漏洞位于一家被收购公司（acquisition）上。项目所有者并不控制被收购公司的 IT 基础设施或人员。 | 项目所有者应尽善意努力（good faith effort）通知被收购公司，并由平台核实。如果被收购公司因该提交而获益，项目所有者应支付赏金。项目简介应更新以反映被收购公司是否在范围内。 |
