Open Bug Bounty

定义

Open Bug Bounty 是一个非营利性质的漏洞悬赏与漏洞披露平台，官方把它描述为开放、去中介化、免费且由社区驱动的协调漏洞披露平台，流程与 ISO 29147 标准兼容^[2]。它允许独立安全研究人员把以非侵入式手段发现的跨站脚本等漏洞提交上来，由平台核验后通知网站运营方^[4]。平台本身不向研究者或网站所有者收取费用，悬赏是否给予、给多少由双方自行商定^[3]。

平台上的报告分为两类路径。一类是网站所有者建立的托管悬赏项目，研究人员按该项目页面上公布的规则提交；另一类面向没有托管项目的任意网站，只接受用非侵入方式发现的跨站脚本等常见 Web 漏洞^[5]。SQL 注入、远程代码执行等必须借助侵入式测试才能确认的高危漏洞不在受理范围内，这类报告需要直接发送到悬赏项目负责人公布的邮箱^[5]。

原理

流程从研究者提交报告开始。平台团队随后对提交内容进行核验，并按通用漏洞评分系统给出风险分值、按通用弱点枚举进行分类^[5]。核验通过后，平台按 ISO 29147 的要求向网站所有者以及研究者指定的安全联系人发出告警。平台的作用只限于独立核验与通知，通知完成之后，网站所有者与研究人员直接联系，协商修复与披露安排，平台不再充当中介^[6]。

披露时间有明确安排。研究人员可以选择只告知网站运营方，也可以在提交满 90 天后公开漏洞技术细节；若漏洞已被修复，公开时间可提前到提交后 30 天。由漏洞扫描器等自动化工具发现的结果不得提交，因为这类工具可能影响网站性能或造成其他负面影响。

费用机制与商业平台不同。作为非营利项目，平台不发放赏金，也不向网站所有者收取程序托管和分类费用，在托管项目中报酬由项目所有者直接付给研究人员，有的项目以礼品或其他形式表示感谢^[5]。对没有托管项目的网站，网站所有者没有付款义务，提交漏洞属于志愿性质的工作^[5]。平台不使用传统账号密码体系，网站上所有人统一通过一次性口令完成身份验证，目的是不在服务器中留存用户相关数据^[7]。

发展历程

平台在 2014 年 6 月由一批独立安全研究人员发起，初衷是让安全研究者与网站所有者以透明、彼此尊重且双方受益的方式建立联系^[1]。它由跨站脚本漏洞资料站 XSSPosed 发展而来^[4]。到 2017 年 2 月，平台累计记录了 10 万个漏洞，其中 3.5 万个得到修复^[4]。同年 8 月，其社区已帮助修复超过 7 万个漏洞^[8]。

2018 年 2 月，平台宣布已修复漏洞数达到 10 万个^[4]。从 2018 年 6 月起，任何经过验证的网站所有者都可以免费为自己的网站建立正式悬赏项目，平台免费对跨站脚本、跨站请求伪造、访问控制错误等无需侵入式测试的提交做分类和核验^[9]。当时平台称其社区已帮助各类组织修复超过 11.9 万个缺陷^[9]。

平台 2019 年的年度报告显示，当年共收到 203,449 个漏洞报告，同比增长约 32%；101,931 个漏洞被网站所有者修复；新增 5832 名研究者，研究者与专家总数达到 13,532 人；网站所有者新建 383 个项目，项目总数 657 个，可用于测试的网站有 1342 个^[10]。当时平台已托管 680 个悬赏项目，为 50 多个国家的研究人员提供有报酬或无报酬的项目，奥地利电信、Acronis、United Domains 等公司在平台上运行自己的项目^[10]。截至 2019 年底，平台公布的已修复漏洞累计为 272,020 个^[4]。

2022 年 10 月 27 日，平台宣布社区帮助修复的漏洞数突破 100 万个，当时托管项目的主体包括 A1 Telekom Austria 和 Drupal，研究者超过 2 万名。德国媒体报道称，此时已有 3.1 万多名安全研究人员向平台提交了约 138.8 万条发现。平台首页此后显示的累计已修复漏洞数超过 150 万个。

应用

平台的主要用途是众测式的漏洞披露，尤其适合对互联网上公开暴露的资产做快速、低开销的测试。在欧盟 NERO 项目中，Bugcrowd、OpenBugBounty 与 WhiteHub 三个众包平台被接入参与试点的中小企业系统，其中 OpenBugBounty 的公开项目吸引了范围更广的参与者，便于迅速了解暴露在外的系统状况^[11]。平台也被用来托管企业自建的悬赏项目，Lidl Digital、A1 Telekom Austria、Drupal 等都曾在此发起项目。

接受帮助的一方涵盖多种类型的组织。戴尔、宜家、推特、Verizon、飞利浦以及若干政府机构、国际组织、法学院和律师事务所都曾对通过该平台提交漏洞的研究者表示感谢^[10]。平台方面表示，越来越多的网络安全学生把它当作实践起点，软件工程师借助它帮助同行改善安全性，专业漏洞猎手则把它视为商业悬赏平台之外更透明的选项^[10]。平台在 2021 年被 The Hacker News 列入年度前五漏洞赏金项目，2022 年又进入 Infosec Institute 的前六榜单^[12]。

局限

平台的受理范围有清楚边界。受资源限制，它不接受需要侵入式测试才能验证的漏洞，也不对远程代码执行、SQL 注入这类高敏感提交提供人工分类。按平台自己的统计，被拒绝的漏洞中有 99.9% 属于不受理的类型或者无法复现，而核验本身需要时间：跨站脚本等较简单的漏洞通常最多 5 天，不当访问控制等更复杂的问题可能长达 10 天^[5]。

经济回报并不确定。平台本身不支付赏金，也不向网站所有者收费，未建立托管项目的网站所有者对研究者没有付款义务，因此研究者能否获得报酬、报酬多少都无法保证^[5]。平台的角色止于核验和通知，不介入此后的修复与披露，也不提供商业平台那种覆盖全生命周期的管理服务^[6]。有研究材料指出，与同时期其他众包平台相比，该平台面向公众的项目流程简单、开销低，但其合规文档较为有限^[11]。

运作模式也曾引起外界质疑。德国 Heise Security 指出，这类平台存在被用作向网站所有者施压渠道的可能，即研究者以公开漏洞为条件索取赏金，但该媒体同时说明 Open Bug Bounty 禁止这类做法^[4]。平台规则要求研究者以尊重、礼貌的方式对待网站所有者，且在漏洞真正修复之前不得谈论报酬；如果研究者以索要好处作为删除提交的条件，或者拒绝向网站所有者提供漏洞细节，相关提交会被立即删除，违规者可能被暂停乃至永久封禁账号^[5]。

参见

• 漏洞赏金 —— Open Bug Bounty 的基本运作形式，网站所有者以奖励换取有效的漏洞报告。

• ISO 29147 —— 平台披露流程所遵循的漏洞披露国际标准。

• 跨站脚本 —— 平台受理的主要漏洞类型之一，也是其早期主要来源。

• HackerOne —— 商业漏洞赏金平台，常与 Open Bug Bounty 在收费模式与平台角色上被对比。