AMD 赏金拒付事件：漏洞赏金流程设计的工程反思

事件回顾：当政策条款成为拒付理由

2025 年初，安全研究员 Paul LaRosa 向 AMD 披露了一个严重漏洞：Windows 版自动更新器通过未加密的 HTTP 连接下载软件，攻击者可在网络层实施中间人攻击，向用户系统注入恶意代码实现远程代码执行（RCE）。按照 AMD 漏洞赏金计划的奖励标准，此类关键漏洞的赏金为 $10,000。

然而，AMD 最终拒绝支付这笔赏金，理由是「中间人攻击（MITM）属于政策排除范围」。更具争议的是，AMD 在 2 月请求研究员延迟公开披露，承诺 90 天内修复，实际却耗时 124 天 —— 远超行业最佳实践建议的 5-14 天关键漏洞修复窗口。更令安全社区质疑的是，所谓的「修复」仅将下载协议改为 HTTPS，文件校验仍使用可被篡改的 CRC32 而非加密签名。

这一事件暴露的不仅是单个厂商的决策问题，更折射出整个漏洞赏金生态在流程设计、争议处理和激励体系上的系统性缺陷。

政策设计缺陷：模糊边界与选择性解释

AMD 赏金政策将 MITM 攻击排除在奖励范围之外，但这一条款的适用边界存在严重模糊性。LaRosa 发现的漏洞并非单纯的网络层攻击演示，而是直接影响数百万用户的自动更新基础设施 —— 攻击者可利用此漏洞向 Ryzen Master 等核心工具推送恶意更新，实现大规模系统入侵。

行业最佳实践表明，赏金政策中的排除条款应当满足两个条件：

第一，排除范围必须具体且可验证。 优秀的漏洞赏金计划会明确区分「理论性 MITM」与「可导致实际用户数据泄露或系统入侵的传输层漏洞」。例如，Google 的赏金政策要求 MITM 漏洞必须证明在真实用户场景下的可利用性，而非简单排除整个攻击类别。

第二，排除条款不应成为降低赏金的工具。 当漏洞的实际影响达到 Critical 级别时，厂商应当基于影响评估而非政策字面条款做出赏金决策。AMD 将自动更新器的 RCE 漏洞归类为「排除项」，实质上是利用政策漏洞规避支付义务。

从工程治理角度，建议厂商在设计赏金政策时采用「影响优先」原则：先评估漏洞对用户的实际风险，再对照政策条款确定赏金等级。对于边界案例，应设立由安全、法务、产品三方组成的仲裁委员会，避免单一部门的主观裁量。

支付争议处理：缺乏透明度的黑箱机制

AMD 事件中另一个值得关注的细节是争议处理过程的不透明。研究员在提交漏洞后，未获得明确的拒付理由说明，也缺乏申诉渠道。这种「黑箱式」决策严重损害了安全研究者的参与积极性。

成熟的漏洞赏金计划应当建立分层的争议处理机制：

第一层：技术复核。 当研究员对赏金评定有异议时，应提供技术层面的复核通道，由独立安全工程师重新评估漏洞的技术影响。复核过程应在 5-10 个工作日内完成，并给出详细的技术分析。

第二层：仲裁委员会。 对于技术复核仍无法达成一致的案例，应提交至由厂商安全负责人、外部安全专家和法律顾问组成的仲裁委员会。仲裁结果应形成书面记录，用于后续政策优化。

第三层：公开披露。 在保护敏感技术细节的前提下，定期发布争议案例的匿名化总结，帮助研究社区理解厂商的赏金评定标准。这种透明度本身就是对研究者的尊重，也能减少重复争议。

AMD 在此次事件中未能提供任何层级的有效争议处理，124 天的修复周期内，研究员处于信息不对称的弱势地位。这种权力失衡会长期抑制外部安全研究者向该厂商报告漏洞的意愿。

修复质量与赏金激励的错位

事件的另一个技术细节值得深入分析：AMD 的「修复」方案仅将 HTTP 升级为 HTTPS，但文件完整性校验仍使用 CRC32 校验和。CRC32 是一种非加密哈希算法，攻击者可以构造具有相同校验值的恶意文件，绕过完整性验证。

从赏金激励的角度，这种「半修复」方案暴露了两个问题：

第一，赏金支付与修复质量脱钩。 理想的赏金机制应当将部分奖励与修复验证挂钩 —— 研究员不仅发现漏洞，还应协助验证修复方案的有效性。当厂商提供的修复存在明显缺陷时，研究员应有权要求重新评估赏金或延迟公开披露。

第二，修复 SLA 的刚性约束缺失。 AMD 承诺 90 天修复，实际耗时 124 天，超期比例达 38%。对于关键级别的自动更新器漏洞，这一修复速度远低于行业 acceptable 标准。赏金计划应当内置 SLA 违约条款：当厂商未能在承诺时间内提供有效修复时，自动触发额外的赏金补偿或公开披露豁免。

建议厂商在设计赏金流程时，将修复验证作为支付前置条件之一。具体而言，赏金可分两阶段支付：第一阶段在漏洞确认后支付 30%，第二阶段在研究员验证修复有效性后支付剩余 70%。这种机制既保护了厂商的修复时间窗口，也确保研究员的劳动获得完整回报。

激励体系的长期影响：信任资本的流失

漏洞赏金计划的本质是一种信任契约：厂商承诺对负责任的漏洞披露给予公平回报，研究者承诺在修复完成前保密技术细节。AMD 此次事件损害的不仅是单个研究者的利益，更是整个赏金计划的信誉资本。

安全研究社区具有高度网络化特征，负面体验的传播速度远超正面案例。当研究者发现某厂商存在「找理由拒付」的行为模式时，理性选择可能是：

• 转向其他赏金计划更透明的厂商
• 直接在公开渠道披露漏洞，放弃赏金但获得声誉
• 停止对该厂商产品的安全研究投入

对于 AMD 这样的基础设施厂商，第三种结果尤为危险。CPU 和驱动程序层面的漏洞往往具有极高的利用价值，一旦外部研究者的善意披露意愿下降，这些漏洞更可能流入地下市场，最终损害的是普通用户的安全。

从工程实践角度，建议厂商建立「研究者体验」指标，定期调研参与者的满意度、争议率和复购率（即同一研究者多次提交漏洞的比例）。当指标出现异常时，主动审查赏金政策的执行一致性。

可落地的流程设计清单

基于上述分析，为漏洞赏金计划的设计者提供以下可落地的工程实践清单：

政策设计层面：

• 排除条款必须附带具体的验证标准，避免主观解释空间
• 建立「影响优先」的评估原则，边界案例提交仲裁委员会
• 定期（建议每季度）审查政策条款与实际执行的一致性

流程执行层面：

• 设立 24-72 小时的初始响应 SLA，5-10 工作日的技术评估 SLA
• 赏金分阶段支付，将修复验证作为最终支付条件
• 建立三层争议处理机制：技术复核 → 仲裁 → 公开总结

透明度建设层面：

• 定期发布赏金统计报告，包括平均响应时间、争议率、修复 SLA 达成率
• 对重大争议案例进行匿名化复盘，展示改进措施
• 建立研究者反馈渠道，将体验指标纳入计划健康度评估

激励对齐层面：

• 对于关键基础设施漏洞，设置「修复质量奖金」，奖励发现修复缺陷的研究者
• SLA 违约自动触发补偿机制，保护研究者的时间成本
• 建立「白帽荣誉榜」，非金钱激励与赏金支付并行

结语

AMD $10,000 赏金拒付事件的价值，在于它揭示了漏洞赏金计划中容易被忽视的制度细节。当政策条款成为拒付工具、当争议处理缺乏透明度、当修复质量与赏金脱钩，整个安全研究生态的激励相容性就会受到侵蚀。

对于运行漏洞赏金计划的厂商而言，短期节省的赏金支出，可能换来长期的安全债务积累。而对于安全工程师和研究者，理解这些流程设计的陷阱，有助于在选择参与目标时做出更理性的决策。

漏洞赏金不是慈善，而是一种精算过的安全投资。只有当流程设计的各个环节都能对齐「鼓励负责任披露、保障用户安全」的核心目标时，这种投资才能产生预期的回报。

参考来源

• Gadget Review: "AMD Stiffs Researcher $10,000 Bug Bounty After Critical Security Flaw" (2026-06-12)
• OWASP Vulnerability Disclosure Cheat Sheet
• Critical Thinking: "Bug Bounty Program Best Practices"

security