一句话版本
一个安全研究者发现了漏洞，有几种选择：私下告诉厂商、直接公开、卖给出价最高的人、或者自己利用。负责任披露（也叫协调披露）是业界主流做法：先私下通知厂商，给一段合理的修复时间（常见是 90 天），之后再公开细节。
漏洞赏金用金钱奖励把研究者留在"白帽"这一边。对一个项目来说，至少要做到两件小事：公开一个安全联系方式（security.txt），以及承诺不起诉善意的研究者。
全文分三层：
- 通俗理解：发现邻居家门没锁，该怎么办
- 实际用处：90 天期限、漏洞赏金平台、加密货币领域的"白帽谈判"
- 原理与工程要点：security.txt、披露流程、赏金计划的设计、安全港
第一层：通俗理解
1.1 发现邻居家门没锁
你发现邻居家的门没锁。合理的做法是：
- 私下告诉邻居；
- 给他时间修锁；
- 如果他一直不修，可以提醒其他邻居注意（因为小偷也可能发现）。
不合理的做法是：在小区群里公布"某某家门没锁"（直接公开），或者自己进去拿东西（利用），或者把这个消息卖给小偷。
1.2 两难
| 立刻公开 | 永远保密 |
|---|---|
| 厂商来不及修，攻击者先利用 | 厂商可能永远不修，用户一直处于危险中 |
协调披露是两者的折中：给厂商一个期限，期限内保密；期限一到，无论修没修都公开，倒逼厂商重视。
第二层：实际用处
- 谷歌 Project Zero 的 90 天政策：谷歌的漏洞研究团队向厂商报告漏洞后，给 90 天修复时间，到期公开细节（已被积极利用的漏洞期限更短）。这个做法一度引发争议，但大大推动了厂商的修复速度，现在被广泛效仿。
- CVE：公开披露的漏洞会获得一个 CVE 编号（如 CVE-2024-3094），全行业用这个编号来追踪和沟通同一个漏洞。
- 漏洞赏金平台：HackerOne、Bugcrowd 等平台帮助企业运营赏金计划；加密货币领域有 Immunefi 等专门平台，单个高危漏洞的赏金可达数百万甚至上千万美元。例如 2022 年，Wormhole 就向一位报告了严重漏洞的研究者支付了 1000 万美元赏金。
- 加密货币的"白帽谈判"：很多被盗事件后，项目方会在链上给攻击者留言，提出"归还大部分资金，剩余部分作为赏金，我们不追究"。2021 年 Poly Network 被盗约 6.1 亿美元后，攻击者最终归还了几乎全部资金。这种做法游走在法律和道德的灰色地带，但在资金难以追回的现实下被广泛采用。
- 安全港（safe harbor）：为了鼓励白帽在攻击进行中"抢救"资金（先于攻击者把资金转到安全地址），加密货币安全社区（如 SEAL）在 2024 年推出了白帽安全港框架，事先约定白帽救援的规则、赏金比例和法律保护。
第三层：原理与工程要点
3.1 security.txt
一个放在网站固定位置的文本文件（RFC 9116，2022 年），告诉研究者怎么联系你：
# https://example.com/.well-known/security.txt
Contact: mailto:[email protected]
Expires: 2027-12-31T23:59:59Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security-policy
Preferred-Languages: zh, en
几分钟就能做好。没有它，研究者发现漏洞时可能找不到人报告，只能发给客服，或者干脆放弃。
3.2 一个最小的披露政策
| 内容 | 说明 |
|---|---|
| 范围 | 哪些域名、应用、合约在范围内；哪些不在（比如第三方服务） |
| 怎么报告 | 邮箱、表单；希望包含哪些信息（复现步骤、影响） |
| 响应承诺 | 多久内确认收到、多久内给出初步评估 |
| 研究规则 | 不访问他人数据、不影响服务可用性、不进行社会工程、测试网优先 |
| 安全港声明 | 承诺不对遵守规则的善意研究者采取法律行动 |
| 公开时间 | 修复后多久可以公开；是否致谢 |
3.3 赏金计划的设计
| 要点 | 说明 |
|---|---|
| 按影响定价 | 能直接偷走资金的漏洞，赏金应与潜在损失挂钩（加密货币领域常见做法是按"受影响资金的一定比例，设上限"） |
| 赏金要有竞争力 | 如果黑市价格远高于赏金，就留不住研究者 |
| 处理要快 | 拖延、压价、不回复，会让研究者转向公开披露 |
| 明确的严重程度标准 | 减少争议 |
| 不要只靠赏金 | 赏金是审计和测试的补充，不是替代（见《合约审计与形式化验证》） |
3.4 收到报告之后
- 快速确认收到，感谢研究者；
- 复现并评估严重程度；
- 如果是高危，按事故处理（见《事故响应与复盘》）：可能需要立即暂停功能；
- 修复、验证、部署；
- 和研究者协调公开时间，致谢，支付赏金；
- 发布公告或安全通告，必要时申请 CVE。
3.5 对研究者的提醒
- 只在明确授权的范围内测试；有赏金计划就遵守它的规则；
- 不要越过证明漏洞所需的最小范围（证明能读一条数据就够了，不要下载整个数据库）；
- 保留沟通记录；
- 遇到无法联系的厂商，可以通过 CERT 等协调机构转达。
总结
| 层次 | 要点 |
|---|---|
| 原则 | 先私下通知，给修复期限（常见 90 天），到期公开 |
| 机制 | CVE 编号、漏洞赏金平台、加密货币的白帽谈判与安全港 |
| 最低要求 | 发布 security.txt；写一份带安全港声明的披露政策 |
| 赏金设计 | 按影响定价、有竞争力、处理要快、不替代审计 |