漏洞赏金计划运营实战：vibe 项目从定价到发放的完整指南

2026 年 10 月 1 日，Google 宣布暂停其开源软件漏洞赏金计划（OSS VRP）的新产品漏洞报告受理，理由是一句话："This pause is due to a significant rise in automated submissions, the vast majority of which are not valid."（暂停源于自动化提交的显著增长，其中绝大多数无效。）TechCrunch 在 10 月 4 日的报道里补了一句背景：Google 工程师和开源维护者已经被无效报告和幻觉式漏洞描述淹没了。一个连 Google 都扛不住的教训是：漏洞赏金计划真正的成本从来不是发出去的赏金，而是审核每一份报告的人力。这篇指南不讲具体防御技术怎么做——那是《vibe 项目 Web 安全基线指南》的地盘——只讲赏金计划的运营机制：什么时候开、怎么定价、范围怎么写、报告怎么分级、AI 生成的垃圾报告怎么过滤、赏金怎么发。一人团队或小团队照着做，就能搭起一套不被报告淹没、不被账单吓到的赏金体系。

一、什么时候该开赏金计划：三个信号与两条替代路线

先说一个反直觉的结论：赏金计划不是安全建设的起点，而是放大器。它放大的前提是你已经有一套能运转的安全响应流程——有人能读报告、有人能复现、有人能排期修复。如果这三件事没人做，赏金计划只会把你淹没在报告里，顺便把预算烧光。

判断"该开了"的三个信号：

1. 你在处理真实用户的数据或钱。有付费用户、有登录体系、有支付链路、有用户上传的隐私数据——这时候一个未被发现的漏洞的代价，已经超过开赏金计划的成本。反过来，MVP 还在验证 PMF、用户全是测试账号、数据库里没几条真实记录，那就别开。报告来了你修不过来，猎人还会觉得你不专业。

2. 你已经做过至少一轮基础安全功课。依赖扫描跑过一遍、OWASP Top 10 的常见坑自己先扫过一遍、最好做过一次外部渗透测试。赏金猎人最擅长找的是"你没想到的"，而不是"你懒得修的"。如果计划一开就收到一堆"缺 security header""cookie 没加 HttpOnly"这种基础项，说明你开早了——这些本该在内部解决，每一份还要占用你的分级时间。

3. 有人能响应，哪怕只是你自己。赏金计划的隐性成本是人力：读报告、复现、定级、沟通、排期修复。HackerOne 的行业数据里，一个新计划首年赏金预算通常在 3 万到 10 万美元，但这不包括你自己的时间。一个人团队不是不能开，而是要把范围收得很小（见第三节），并且接受响应会慢一点——但必须在政策里把响应时限写清楚（见第四节）。

如果三个信号只满足一个，走替代路线：

替代路线 A：先上 VDP（漏洞披露政策），不设赏金。VDP 是一份公开声明："如果你发现了我们的漏洞，请通过这个渠道告诉我们，我们承诺在 X 天内响应、不追究善意研究者。"它零成本，能先把"有人愿意告诉你"这个通道建起来。很多团队跑 VDP 跑了半年，攒够了报告量和分级经验，再转成付费赏金计划，定价和范围都有数据支撑，不拍脑袋。

替代路线 B：定期渗透测试 + 依赖扫描自动化。每季度请外部做一次渗透测试（或用众测平台的单次测试服务），配合 Dependabot / Renovate 这类自动化依赖更新。对代码量不大、迭代快的 vibe 项目来说，这条路线的单位成本往往比赏金更低、产出更可预期。

渐进路线总结：VDP（免费，先建通道）→ 私人赏金计划（邀请制，小范围试水）→ 公开赏金计划（全面开放）。每一步都以前一步的数据做决策，预算和人力都不会失控。

二、赏金定价表：四档定价与低预算起步策略

定价是赏金计划里最容易拍脑袋、也最容易出事的一环。定高了，账单爆炸；定低了，好猎人不来，来的全是 AI 批量生成的垃圾报告。下面是一套给初创和小团队的起步定价表，按 CVSS 3.1 基础分映射：

严重度	CVSS 区间	典型例子	起步赏金（美元）
Critical	9.0–10.0	无需登录的远程代码执行、支付绕过、任意用户数据批量泄露	1000–3000
High	7.0–8.9	需登录的越权访问、存储型 XSS 拿管理员权限、敏感接口未授权访问	300–1000
Medium	4.0–6.9	反射型 XSS（需用户交互）、CSRF（有实际影响）、信息泄露（非敏感）	100–300
Low	0.1–3.9	缺安全响应头（单独报告）、版本号泄露、轻微信息泄露	0–100

制定逻辑有三条，缺一不可：

第一，对标市场，但别照抄大厂。成熟项目的公开定价是很好的锚：GitHub 公开赏金计划在 2026 年 7 月调价后是 Critical 10000 / High 5000 / Medium 2000 / Low 250 美元（另有邀请制 VIP 档更高）；Google OSS VRP 历史区间是 100 到 31337 美元。你不需要对标这个量级——猎人看的是"定价是否与你的项目体量匹配"。一个日活几千的 vibe 项目开 Critical 2000 美元是合理的，开 20000 美元反而会引来超出你处理能力的报告量。

第二，用预算倒推，而不是用野心正推。公式很简单：全年赏金预算 ≈ 预计有效报告量 × 加权平均赏金。新计划第一个季度通常是报告高峰（猎人集中扫一遍），之后回落。按 Vendr 统计的 HackerOne 交易数据，新计划首年赏金预算中位数在 3 万到 10 万美元——但那是中型公司的数字。vibe 项目可以按"首年 5000 到 15000 美元"起步，关键是把"定价每季度复盘一次"写进政策，报告量超预期就收紧范围或降档，而不是硬扛。

算一笔具体的账：假设你首年赏金预算是 8000 美元。按新计划的经验分布，Critical 占 5%、High 占 20%、Medium 占 45%、Low 占 30%，取各档中位数（Critical 2000、High 650、Medium 200、Low 50），加权平均每份有效报告约 335 美元。8000 美元对应约 24 份有效报告——也就是平均每月 2 份。这个数字告诉你两件事：范围必须小到让月报告量落在个位数，以及 duplicate 规则必须严格，否则预算会在第三季度见底。预算公式反过来用就是范围设计的依据，这是很多团队第一次算清的账。

第三，低预算起步的四个具体策略。一是私人计划先行：只邀请 20 到 50 个有历史成绩的猎人，不公开，报告量可控，单价可以给得稍高；二是低档起步、公开承诺上调：政策里写"本计划处于早期阶段，定价将随计划成熟度每季度上调"，猎人对涨价的容忍度远高于对降价的容忍度；三是非货币激励补位：公开致谢榜（Hall of Fame）、漏洞细节的署名披露权、推荐信，对很多猎人是实打实的收益；四是重复与已知问题只致谢不发赏金，这条必须写进政策，否则你的预算会被 duplicate 报告吃掉一半。

三、范围界定：in-scope / out-of-scope 写法模板

范围文档是赏金计划最重要的法律与运营文件。它决定了三件事：猎人测哪里、你为什么报告付钱、出了纠纷以什么为准。写范围的原则是：宁可一开始写窄，逐步放宽；绝不要一开始写宽，再收紧——收紧范围会被社区解读为"赖账前兆"。

In-scope 写法模板（直接可用）：

资产类型	写法示例	备注
Web 应用	app.example.com（含所有子路径）	明确是否含营销官网
API	api.example.com/v2/*	注明版本号，旧版本另行说明
移动端	iOS App v3.2+ / Android App v3.2+（应用商店最新版）	注明最低版本，旧版漏洞不受理
测试账号	提供专用的测试账号与测试环境地址	禁止用真实用户数据测试

Out-of-scope 与明确排除项（每一条都要写，没有"默认排除"这回事）：

1. 第三方服务与组件。支付网关（Stripe / 支付宝）、CDN、云服务商控制台里的漏洞不归你修，也不该你付钱。写法："运行在第三方基础设施上的问题请直接报告给相应厂商。"但注意：如果是因为你错误配置第三方服务导致的漏洞（比如 S3 存储桶公开），那是你的责任，算 in-scope。

2. 拒绝服务与暴力测试。DoS / DDoS、登录接口暴力破解、自动化扫描器无脑扫全站——这些会伤害真实用户，必须明确禁止。允许的是"证明存在速率限制缺失"的单次 PoC，而不是真的把服务打挂。

3. 社会工程学。钓鱼、冒充客服、针对员工的社工，一律排除。这是红线中的红线，写进政策能帮你挡掉大量纠纷。

4. 已公开漏洞（N-day）与自带理论漏洞。依赖库里已经公开 CVE 编号、你还没升级的——这属于你的运维欠账，猎人报告了可以致谢，但通常不付赏金（除非你的政策明确说付）。没有 PoC、只有"理论上可能"的报告，直接按无效处理。

写范围时还要处理"灰色地带"。比如你的 vibe 项目用了 Supabase / Firebase 做后端，猎人报了一个"Supabase 配置问题"——到底算你的还是算 Supabase 的？规则是：谁能修归谁。如果是你控制台里一个开关没打对，那就是你的 in-scope；如果是 Supabase 平台本身的漏洞，那就是 out-of-scope，请猎人去报 Supabase 的赏金计划。把这类常见灰色地带各举一例写进政策的 FAQ，能省掉日后一半的扯皮。

5. 低影响单项。单独报告的缺 security header、点击劫持（无实际影响链条）、版本号泄露、SPF 记录缺失——这些要么合并到"加固建议"类别给固定小额赏金，要么直接列为不受理。否则你的分级队列会被这类报告塞满，而这正是 AI slop 的重灾区。

四、安全政策与披露渠道：security.txt、PGP 邮箱与 SLA 承诺

赏金计划需要一个"门面"：让猎人 30 秒内找到"去哪报告、找谁、多快有回复"。这个门面由三件套组成，缺一件都会流失报告——而流失的报告不会消失，只会变成公开的 0day。

1. security.txt（RFC 9116）。在网站根目录和 /.well-known/ 路径下放置 security.txt，内容模板如下：

Contact: mailto:security@example.com
Contact: https://example.com/security-policy
Expires: 2027-06-30T00:00:00.000Z
Encryption: https://example.com/pgp-key.asc
Preferred-Languages: zh, en
Policy: https://example.com/security-policy
Hiring: https://example.com/jobs

注意四个细节：Expires 必须写，且不超过一年，到期前更新，否则会被视为过期政策；security.txt 的 Content-Type 建议设为 text/plain，确保纯文本可读；Encryption 指向你的 PGP 公钥，让猎人可以加密发送敏感细节；Contact 不要只留邮箱，政策页链接也要有，因为邮箱可能被当成垃圾邮件过滤掉。

2. 专属安全邮箱 + PGP。用 security@你的域名 这样的专属地址，不要用创始人个人邮箱——人员变动时交接是灾难。PGP 公钥发布在政策页和 Keybase（或 WKD）上，指纹写进 security.txt。实操建议：这个邮箱设置独立的收件规则和自动回复（"已收到，48 小时内响应"），不要让它淹没在日常邮件里。

3. 响应 SLA 写进政策页。猎人决定要不要测你的第一依据就是"这家靠不靠谱"，而靠谱的唯一可验证信号就是 SLA。建议的承诺档：

节点	承诺时限
首次响应（确认收到）	48 小时内
初步分级（有效/无效）	7 天内
修复排期告知	分级确认后 14 天内
赏金发放	修复验证后 30 天内

写 SLA 的底气来自前面的判断：如果连 48 小时响应都做不到，说明你还没到开计划的时候，退回 VDP。SLA 是承诺，不是 aspiration——第一次食言，猎人社区的口碑就崩了，而口碑是小团队唯一的获客渠道。

五、平台选择：入驻还是自建

四条路线，按成本与工作量从高到低排：

	HackerOne	Bugcrowd	Intigriti	自建（邮箱+表单）
平台年费	约 5 万–15 万美元（自助） 托管约 10 万–25 万美元	量级接近 HackerOne	相对低，常按报告量计费	约 0
赏金预算	另计（新计划首年通常 3 万–10 万美元）	另计	另计	自己定，可低至数千美元
分级服务	有（托管计划含人工分级）	有（众包分级是强项）	有	全靠自己
猎人流量	最大	大	欧洲强	零，要自己攒口碑
适合谁	预算充足、要规模	想要快速分级	预算敏感、欧洲用户多	年预算 < 1 万美元的小团队

（费用数据来自 Vendr 统计的 HackerOne 平台交易与 2026 年行业报告，实际以各平台最新报价为准。）

给 vibe 项目的选型建议很直接：年预算低于 1 万美元就自建。平台年费本身就吃掉你全部预算，还没算赏金。自建的核心工作量就四件：写好政策页（抄平台模板改）、搭一个报告表单（强制字段见第七节）、定一个每周固定时间批量分级、准备好 PayPal / Wise 发赏金。自建的真正短板是两点：一是没有猎人流量，前期要去 X / Discord / 安全社区主动邀请；二是没有平台的信誉背书，SLA 必须超预期执行才能攒出口碑。

自建计划冷启动时，去哪里找第一批猎人？三个免费渠道：X 上搜 "bug bounty" 话题下活跃的研究者，直接私信邀请；Discord 的安全社区（如各大 CTF 战队的频道）发招募帖；把你的 VDP 链接提交到 HackerOne / Intigriti 的公开目录（只上目录、不开付费计划）。邀请话术要具体："我们是 XX 领域的 SaaS，核心资产是 app.example.com，首期赏金 Critical 2000 美元起，48 小时内响应"——猎人每天收到大量邀请，写清范围和响应承诺的才会被点开。

预算在 1 万到 5 万美元之间，选平台的私人计划：不公开，只邀请有历史成绩的猎人。报告量可控（通常每月个位数），平台的分级服务帮你挡掉 80% 的无效报告，这是小团队最划算的一笔钱。超过 5 万美元再考虑公开计划。记住一个顺序：先用自建 VDP 验证你能处理报告，再花钱买平台流量——顺序反了，平台流量只会把你淹没得更快。

六、漏洞分级与去重：CVSS 实操与 duplicate 判定

分级是赏金计划里技术含量最高、也最容易吵架的环节。规则必须在前、执行必须一致，否则每一份 High 都会变成猎人要求改成 Critical 的谈判。

CVSS 实操：抓大放小。CVSS 3.1 的基础分由三组指标决定：可利用性（攻击向量是网络还是本地、攻击复杂度、是否需要权限、是否需要用户交互）、影响（机密性/完整性/可用性的受损程度）、范围（是否影响到漏洞组件之外的系统）。vibe 团队不需要背下全部指标，记住这套简化心法：

先看攻击向量：无需登录、远程可利用的，直接起步 High；需要登录或用户交互的，往下压一档。再看影响：能拿 shell、能绕过支付、能批量拖库的，Critical；只能看不能改、或只能影响自己的，Medium 起。最后看范围：漏洞在一个组件、影响扩散到整个系统的（比如 SSRF 打到内网），升一档。用 NVD 的 CVSS 计算器跑一遍分数，把"分数→赏金档"的映射表公开在政策页，猎人自己就能预判定级，争议少一半。

举个完整的打分例子：猎人报告你的 SaaS 应用存在"越权访问"——普通用户把订单接口里的 order_id 改成别人的，就能看到别人的订单详情和收货地址。打分过程：攻击向量是网络（AV:N）、攻击复杂度低（AC:L）、需要登录但只需要普通用户权限（PR:L）、无需受害者交互（UI:N），机密性受损为高（C:H，看到他人隐私数据）、完整性无影响（I:N）、可用性无影响（A:N），范围未变更（S:U）。CVSS 3.1 计算器给出的基础分是 6.5，对应 Medium 偏上。你的政策映射表里 Medium 档是 100–300 美元，结合"涉及他人隐私数据"的影响加成，可以定到 250 美元。把这套推理过程（而不只是分数）回复给猎人，争议会少很多——猎人要的不是高分，是"我的报告被认真读过"的证据。

分级流程固定为三步：收到报告 48 小时内给初步评级（可以是"待复现"状态）；技术复现后定终级；终级一旦发出，除非有新的技术证据，否则不改。朝令夕改是分级公信力的头号杀手。

Duplicate（重复报告）判定规则——这是预算的守门员：

1. 同一根因算一份。同一个 SQL 注入点，猎人 A 报了登录接口、猎人 B 报了注册接口，根因是同一处代码没做参数化——这是一份报告，赏金给先到的 A。判定标准是"修复是否只需要改同一处代码"，而不是"利用路径是否相同"。
2. 先到者得，以报告时间为准。精确到分钟，平台自动记录；自建就用邮箱/表单时间戳。时间相同看 PoC 完整度。
3. "已在修复中"的合并处理。维护一份内部已知问题清单（不需要公开细节，只需要编号）。新报告命中清单里的已知问题，标记为 duplicate，通知报告人"该问题已在修复中"，给小额致谢赏金（比如 50 美元固定）或 Hall of Fame 署名，但不按正常档位付费。这条规则必须写进政策，否则猎人会觉得你在赖账。
4. 变体报告的奖励。如果第二份报告展示了同一根因的、危害显著更大的利用链（比如从"只能读"推进到"能写"），可以升级原报告的定级并补发差价，而不是开一份新报告。这是留住顶级猎人的关键细节。

七、AI slop 报告对抗：2026 年 10 月的教训

这是 2026 年下半年每个赏金计划运营者都必须面对的新现实。时间线很清晰：2026 年 1 月底，curl 的 Daniel Stenberg 彻底结束了在 HackerOne 上的付费赏金，原因是 AI 生成的无效报告；3 月，Google 称其 OSS VRP 遭遇 AI 生成报告的"massive surge"（大规模激增），报告里有 hallucinated（幻觉出来的）漏洞，也有真实存在但按项目安全模型根本不可利用的代码问题，Google 当时的应对是收紧证据要求——某些内存破坏类报告开始要求提供精确的 OSS-Fuzz 复现步骤或已合并的补丁；5 月，HackerOne 报告全行业报告量同比激增超过 100%；7 月，GitHub 把公开赏金砍半（Critical 从 2 万多美元降到 1 万美元），同时开了邀请制的 VIP 高价档；10 月 1 日，Google 直接暂停了 OSS VRP 的新产品漏洞报告受理，承诺 2027 年第一季度再给更新。Bugcrowd 的分级团队给这类报告起了个名字："sloptimism"——提交得又快又乐观，作者对模型输出的信任超过了对证据的信任。

这场风波里还有一组值得记的数字：Google 在 2025 年向 700 多名安全研究者支付了创纪录的 1710 万美元赏金，比 2024 年的 1200 万美元增长 40%——赏金支出在涨，审核人力没涨，这就是 slop 能淹没通道的结构性原因。HackerOne 的 2025 年度报告也提到，经确认有效的 AI 辅助报告当年增长了 210%，全自动"hackbot"提交了 560 多个有效发现——说明 AI 本身不是敌人，真正的问题永远是"不可验证的报告消耗了本该属于有效报告的审核资源"。

核心矛盾要讲透：LLM 没有让发现真实漏洞变多，它让"看起来可信的报告"变得几乎零成本。而分级本质上是人工活——要读报告、尝试复现、下判断。提交成本归零，审核成本原地踏步，Google 这个量级的团队都被淹没了，小团队如果没有过滤机制，开计划等于开闸放水。

过滤机制分三层，对应下图的漏斗：

第一层：格式门槛——PoC 必备字段。报告表单设为"缺字段无法提交"：受影响的产品与版本号、复现步骤（编号列表，一步都不能少）、PoC 代码或请求报文、实际影响说明（"攻击者能得到什么"，不是"可能很危险"）、测试环境说明。AI 生成的报告最常见的死法就是卡在这一层：复现步骤含糊其辞，PoC 一跑就报错。注意，这不是刁难人——HackerOne 在 2026 年 9 月也开始强制要求部分计划提交严重度评级，行业方向一致：把举证责任还给提交者。

第二层：复现验证——无法复现就不分级。规则写死："我们只对可复现的报告定级"。复现不了的报告先打回，附上你的复现环境说明，给猎人一次补充机会；补充后仍无法复现，关闭。这一层的关键是速度——slop 报告的特点是"看起来都差不多"，批量处理，不要在每一份上纠结半小时。

第三层：有效性分级——确认有效才进赏金流程。只有通过复现的报告才进入 CVSS 定级和赏金流程。Google 在 2026 年 3 月的教训值得抄：真实存在但"按你的安全模型不可利用"的问题，明确标为"不符合安全模型"，不付赏金。这条要写进政策，否则猎人会拿着静态扫描器扫出来的 warning 挨个找你要钱。

模板化驳回话术（中英各一条，直接可用）：

中文："感谢提交。经复现，该报告描述的问题在我们当前版本中无法复现（详见附件复现记录）。根据我们的报告政策，可复现是定级的前提。如果你能提供在 X.Y.Z 版本、按附件环境可稳定复现的步骤，欢迎重新提交。"

英文："Thanks for the submission. We could not reproduce the described issue on our current version (see attached reproduction notes). Per our policy, reproducibility is a prerequisite for triage. If you can provide steps that reliably reproduce it on version X.Y.Z in the attached environment, feel free to resubmit."

最后一条原则：别误伤用 AI 做辅助研究的猎人。Google 自己也承认 AI 能加速漏洞发现，问题从来不是"用了 AI"，而是"报告不可验证"。政策里的措辞应该是"我们欢迎 AI 辅助的研究，但所有报告必须满足可复现的证据标准"，而不是"禁止 AI 生成的报告"——后者既执行不了，也会赶走真正的高手。

八、赏金猎人沟通 SOP：五个节点的模板与时限

猎人对你的评价，一半来自赏金金额，一半来自沟通体验。小团队在金额上拼不过大厂，沟通体验是唯一能赢的战场。五个节点，每个节点一句话模板加一个时限：

节点一：首次响应（48 小时内）。目的只有一个：让猎人知道报告没掉进黑洞。模板："已收到你的报告（编号 #2026-XXXX），我们将在 7 天内完成初步分级。复现过程中可能需要补充信息，请留意邮件。"编号很重要——有了编号，后续所有沟通都有据可查，猎人也觉得正规。

节点二：分级确认（7 天内）。有效："经复现确认，该问题有效，初步定级为 High（CVSS 7.5）。已进入修复排期，预计 X 周内修复。"无效："经复现，该问题不符合我们的受理范围（原因：out-of-scope / 无法复现 / 已知问题），本次不予受理，详见附件说明。"无效的判定一定要给具体原因，"不符合政策"四个字等于没说，是纠纷的主要来源。

节点三：修复中（分级后每 2 周更新一次）。很多团队在这里沉默两个月，然后被猎人公开挂出来。模板："#2026-XXXX 仍在修复中，当前进度：已定位根因 / 补丁开发中 / 内部测试中。预计 X 月 X 日前上线。"哪怕进度是"还没排上"，也要说。沉默是最差的沟通。

节点四：已修复（上线后 7 天内）。"#2026-XXXX 已于 X 月 X 日修复上线。我们邀请你在 14 天内进行复测验证，确认修复有效。"复测邀请是标准动作，既是对猎人工作的尊重，也是免费的质量门。

节点五：赏金发放（复测确认后 30 天内）。"#2026-XXXX 定级为 High，赏金 800 美元，将通过 PayPal / Wise 在 30 天内发放。请回复确认收款账号与 Hall of Fame 署名（可匿名）。"把金额、方式、时限一次说清，不要分三封邮件。

定级争议的标准处理流程：猎人对定级不满时，先请他用 CVSS 计算器给出他的打分和每项指标的理由，你再逐项回应分歧点（多数分歧出在"攻击复杂度"和"影响范围"两项上）。如果仍无法达成一致，引入你预先指定的外部仲裁（比如平台的分级服务，或一位你信任的独立安全研究员），仲裁结果为终局。把这条流程写进政策，争议就从"吵架"变成"走流程"。

三条铁律：所有沟通留书面记录（邮件或平台内消息，不用即时通讯软件谈定级）；不在公开渠道争论技术细节（有分歧拉回邮件，公开吵架没有赢家）；对无效报告也保持礼貌——今天被你模板驳回的 slop 提交者，可能是明天的顶级猎人，社区口碑是按"最难看的那次沟通"计算的。

九、修复 SLA 与复测：时限表、复测流程与 Hall of Fame

分级定的是"多严重"，SLA 定的是"多快修"。没有 SLA 的赏金计划，报告会变成永远排不上的 backlog，而 backlog 是披露纠纷的温床。建议的修复时限（从"分级确认"起算）：

严重度	修复目标	说明
Critical	7–15 天	可考虑临时缓解措施先行（如 WAF 规则、下线相关功能）
High	30 天	常规排期，纳入最近两个迭代
Medium	60–90 天	可与版本发布节奏对齐
Low	下个版本顺带修复	不单独排期，但要给猎人明确预期

一个实操技巧：把 SLA 时限和你的发版节奏对齐。比如你每两周发一个版本，High 的 30 天修复目标正好是两个迭代；Critical 的 7–15 天对应一次 hotfix 窗口。对齐之后，修复排期不需要额外的项目管理动作，赏金报告自然流进你现有的开发节奏，小团队才跟得上。

注意措辞：政策里写"目标"而不是"保证"。vibe 项目经常一个人身兼数职，写"保证 15 天修复 Critical"然后食言，不如写"目标 15 天，延迟会主动告知"。猎人要的是可预期，不是奇迹。

复测流程四步：修复上线后通知报告人并给 14 天复测窗口；报告人确认修复有效（或提出绕过——绕过视为新证据，升级处理）；内部做回归测试，确保补丁没引入新问题；关闭报告、进入赏金发放节点。如果报告人 14 天内不回复，视为默认确认，直接关闭——这条也要写进政策，否则报告永远关不掉。

Hall of Fame（公开致谢榜）是低预算团队最重要的非货币激励，做法很简单：政策页上一个表格，列年份、署名（猎人自选，可匿名）、漏洞类型、严重度。进榜门槛是"有效报告"，不要求 Critical。它的价值被严重低估：很多猎人把 Hall of Fame 截图放进简历，对学生和新人猎人尤其有吸引力——而这部分人恰恰是小团队赏金计划的主力报告者。榜单按年份归档，每年年初发一次"年度致谢"，仪式感拉满，成本为零。

十、常见坑：披露窗口、法务免责与内部规则

坑一：猎人公开漏洞细节的时间窗口。标准做法是 coordinated disclosure（协同披露），默认 90 天——这是 Google Project Zero 定下的行业惯例：报告提交后 90 天内厂商修复，之后报告人可以公开细节。你的政策里必须写明三点：默认 90 天窗口；需要延期要提前协商（不能单方面宣布延期）；未经你书面同意不得提前公开细节。最常见的纠纷就是猎人在第 60 天觉得你修得太慢，直接发了 X。预防的办法不是威胁，而是第八节的节点三——保持沟通，猎人通常愿意给在积极修复的厂商延期。

坑二：法务免责条款（Safe Harbor）。政策里必须有一段授权声明，大意是："在遵守本政策范围与规则的前提下进行的安全研究，我们承诺不追究法律责任，并会在必要时为你作证这是授权行为。"没有这段话，猎人测你的系统在技术上可能构成"未经授权访问"，没人愿意冒这个险。这段话建议找律师看一遍再发布——别自己编，编错了等于没写。美国有司法部的善意安全研究不起诉政策可参考，欧盟和中国也有各自的法律框架，政策措辞最好本地化。

坑三：内部员工与关联方参与规则。写死三条：公司员工（包括兼职与实习生）不得参与领赏金——自己代码的漏洞自己修是本职工作；离职员工设 6 到 12 个月冷却期，期内报告只致谢不发赏金；外包供应商在合同期内的相关项目同样排除。不写这条，等于花钱请自己人找自己早该修的 bug，还可能引发"是不是故意留洞"的猜疑。

坑四：赏金发放的实操细节。跨境支付提前测试 PayPal / Wise 到目标地区的可用性；大额赏金确认税务处理方式（有些地区需要代扣）；赏金只发到报告人本人验证过的账号，不接受"转给朋友"。这些细节第一次发放前就要跑通，不要等猎人催款时才发现 Wise 不支持他的国家。

坑五：范围写得太宽导致账单爆炸。新计划最常见的死法：把"*.example.com"全写进范围，第一周收到 40 份报告，其中 30 份是营销站 WordPress 插件的 N-day。对策：第一期只放核心产品域名，营销站、文档站、测试环境明确列为 out-of-scope；跑一个季度看报告量和质量，再逐步放宽。范围是阀门，不是宣言。

坑六：把赏金计划当营销噱头。"我们上线了漏洞赏金计划，最高奖励 10 万美元！"——然后范围只写了个营销官网，核心产品根本不在 scope 里。猎人社区对这种操作极其敏感，一次就会进黑名单。赏金计划的营销价值是真实存在的（它向客户传递"我们重视安全"的信号），但前提是计划本身是真实的：范围覆盖核心资产、SLA 说到做到、赏金按时发放。营销是运营做好的副产品，不是目的。

结语：先建通道，再谈赏金

把这篇指南压缩成一张行动清单：今天先把 security.txt 和安全邮箱搭起来，发布 VDP；下个月跑完一轮渗透测试，整理出已知问题清单；再下个月开私人赏金计划，定价按本文的起步表，范围只放核心域名；跑一个季度，有了报告量和分级手感，再决定要不要公开、上不上平台。Google 用暂停一个运营了四年的计划告诉我们：赏金计划的生死从来不取决于你愿意付多少钱，而取决于你能不能以合理的成本处理每一份报告。先建通道，再谈赏金——顺序对了，预算和人力都不会失控。