Skip to main content

什么是 bug bounty

注意：本文档是英文原版的自动翻译。

什么是 bug bounty

bug bounty（漏洞赏金）是一种项目向独立安全研究人员提供经济奖励的计划，奖励对象是那些发现其代码中的漏洞并负责任地进行披露的人。bug bounty 不再仅仅依赖内部团队或聘请的审计方，而是把寻找漏洞的工作向全球安全社区开放——任何具备相应技能的人都可以参与，而项目只在发现有效漏洞时才支付报酬。

可以把 bug bounty 想象成雇佣一群锁匠来测试你大楼里的每一把锁，并给出一个长期有效的承诺：如果有人发现一把可以被撬开的锁，他就能拿到钱。除非真的发现了缺陷，否则你不必付费；而锁匠们也有动力更加努力地寻找，因为奖励与他们所发现问题的严重程度成正比。在加密货币领域，同样的原则适用于智能合约代码、协议逻辑和基础设施安全。

简而言之： bug bounty 是一种众包安全计划，向独立研究人员支付报酬以发现并报告漏洞——它提供持续、开放式的安全覆盖，与结构化的审计形成互补。

bug bounty 如何运作

计划结构

一个 bug bounty 计划会定义若干关键要素：

  • 范围（Scope） —— 哪些合约、代码仓库、前端、API 或基础设施组件可以提交报告。范围之外的项被明确排除，以避免无谓的工作和虚假报告。
  • 严重程度分级（Severity tiers） —— 漏洞按影响进行分类，通常采用诸如 Critical（严重）、High（高）、Medium（中）和 Low（低）这样的等级。每个级别都有规定的奖励范围。
  • 奖励金额（Reward amounts） —— 赔付额从低严重程度发现的几百美元，到可能导致用户资金损失的严重漏洞的数十万美元（甚至更多）不等。一些主要的 DeFi 协议会为严重漏洞提供超过一百万美元的奖励。
  • 参与规则（Rules of engagement） —— 研究人员必须遵循负责任披露的做法：私下报告，不利用该漏洞，在修复部署之前不公开披露，并且不在 mainnet 上使用真实用户资金进行测试。违反这些规则通常会使提交失去资格。

提交与分诊

当研究人员发现一个潜在漏洞时，他们会通过 bug bounty 平台或直接向项目提交一份详细报告。报告包含对漏洞的描述、一个演示漏洞利用的概念验证（proof of concept）、预估的影响，以及（如适用）建议的修复方案。

项目的安全团队（或 bug bounty 平台的分诊团队）会审查提交内容、验证发现、评估其严重程度，并确定相应的奖励。这一过程根据问题的复杂程度可能需要数天到数周。一旦漏洞被确认并修复，研究人员便会收到报酬，并且在征得研究人员同意的情况下，该发现可能会被公开披露，以建立社区的信任和知识。

bug bounty 平台

有几个平台专门为区块链项目管理 bug bounty 计划：

  • Immunefi —— DeFi 和区块链 bug bounty 领域的主导平台，托管着主要协议的计划，拥有业内一些最大的奖励池。
  • HackerOne 和 Bugcrowd —— 通用型 bug bounty 平台，也被一些加密货币项目使用，尤其用于 web 应用和基础设施安全。

这些平台负责处理提交管理、分诊支持、支付处理，并在研究人员与项目之间提供一层信任。它们还会维护研究人员的公开排行榜和声誉系统。

为什么 bug bounty 对加密货币 AI 项目很重要

持续的安全覆盖

智能合约审计是一次时间点上的审查——它检查的是某个特定时刻存在的代码。审计之后，代码可能会改变，新的合约可能会部署，协议也可能与新的外部系统交互。bug bounty 则提供持续的安全覆盖：只要计划处于活跃状态，全世界的研究人员就有动力在当前正在运行的代码版本中寻找漏洞。

多元化的专长

没有任何单一审计团队能够覆盖所有可能的攻击向量。bug bounty 计划吸引了背景、专长和视角各异的研究人员。有些专精于重入攻击，有些专精于经济利用，有些专精于跨链桥漏洞，还有些专精于链下基础设施。这种专长的多样性提高了发现单一审计团队可能遗漏漏洞的概率。

激励对齐

bug bounty 为研究人员创造了一种经济激励，使其去报告漏洞而非利用漏洞。在没有 bug bounty 的情况下，发现严重缺陷的研究人员面临一个选择：免费报告（或最多得到一句小小的感谢），或者利用它获取可能巨大的经济收益。一个资金充足的 bug bounty 通过让负责任披露成为更有利可图的选项，改变了这种权衡。

安全承诺的信号

对于在 DecAIHub 中列出的项目，一个具有可观奖励金额的活跃 bug bounty 计划，表明团队将安全视为一项持续的关切，而不是一次性的打勾任务。一个既完成了审计又拥有活跃 bug bounty 的项目，展现出一种分层的安全方法——这是基于智能合约的系统所能达到的最成熟姿态。

这在 DecAIHub 项目卡片中出现的位置

  • Bug bounty 字段 (yes/no/—) —— 表示该项目是否维护着一个活跃的 bug bounty 计划。指向该计划、平台（Immunefi、HackerOne 等）和条款的链接放在 links_* 字段和/或 Evidence 表中。
  • Evidence：Bug bounty —— 证据表中记录活跃计划存在性及其链接的那一行。
  • Security and incidents 部分 —— 卡片中记录 bug bounty 状态、审计以及项目威胁模型的部分。

一个拥有可观奖励的活跃计划，比一个奖励极少的计划或根本没有计划，是更强的安全信号。审计状态与 bug bounty 状态的组合，有助于评估项目链上基础设施的整体安全成熟度：两者都没有的项目代表更高的风险；两者都有的项目则代表最成熟的安全姿态。

仅有 bug bounty 并不能证明什么

  • 不存在漏洞 —— bug bounty 激励研究人员去寻找漏洞，但没有被报告的发现并不能证明代码是安全的。这可能意味着没有人足够仔细地查看过，范围太窄，或者奖励不足以吸引顶尖研究人员。
  • 代码质量 —— bug bounty 是一种被动机制。它在漏洞已存在之后才捕捉它们，但并不会改进产生这些漏洞的开发流程。整洁的代码、彻底的测试和稳健的架构是另外的考量。
  • 仅限链上安全 —— 大多数 bug bounty 计划聚焦于智能合约和协议层面的漏洞。它们可能不覆盖链下基础设施、前端应用、API 服务器或 AI 推理流水线。范围定义决定了实际覆盖的内容。
  • 公平的奖励分配 —— 研究人员与项目之间就严重程度分级和奖励金额发生争议是会出现的。并非所有计划都被公平地管理。平台的声誉以及项目在处理提交方面的过往记录都很重要。
  • 去中心化或治理质量 —— bug bounty 是一种安全机制，而不是一种治理结构。一个拥有强大 bug bounty 计划的项目，仍然可能拥有完全中心化的控制、不透明的治理或集中的 admin keys。

请勿混淆

术语 区别
审计 审计是由选定团队进行的结构化、有时间限制的代码审查。bug bounty 是面向任何人的开放、持续的漏洞寻找邀请。审计是主动的；bug bounty 是被动且持续的。它们彼此互补。
负责任披露 负责任披露是在公开漏洞之前，先私下向受影响方报告漏洞的做法。bug bounty 是一种用经济奖励来激励负责任披露的计划。并非所有的负责任披露都通过 bug bounty 进行。
赏金计划（非安全类） 一些项目为非安全任务提供赏金——文档、翻译、社区建设。bug bounty 专门针对代码和基础设施中的安全漏洞。单独的“bounty”一词可能含义不明确。

常见问题

bug bounty 与审计有何不同？

审计是一种结构化、有时间限制的工作，由一支选定的安全专家团队系统地审查代码并产出一份全面的报告。bug bounty 则是一种开放、持续的邀请，面向任何有资格的研究人员去寻找并报告漏洞。审计是主动且有计划的；bug bounty 是被动且持续的。它们服务于不同目的，并且在一起使用时最为有效。

什么让一个 bug bounty 计划有效？

三个因素决定其有效性：范围（计划必须覆盖最关键的组件）、奖励（赔付必须足够大以吸引技能娴熟的研究人员——尤其是对于严重级别的发现），以及响应性（项目必须及时分诊提交、透明沟通并公平支付）。一个奖励低、范围窄或分诊声誉差的计划，将难以吸引认真的研究人员。

任何人都可以参与 bug bounty 吗？

一般来说，可以。大多数区块链 bug bounty 计划对任何具备识别漏洞技术技能的人开放。研究人员不需要正式的认证或隶属关系——重要的是其提交内容的质量。然而，参与者必须遵循计划的规则：负责任披露、不利用漏洞，以及不在 mainnet 上使用真实用户资金进行测试。出于法律合规原因，受制裁的个人或实体可能会被排除在外。

外部参考

另请参阅

No comments to display

Back to top