速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

开源测试:测试人员应该拥抱而不是害怕捉虫赏金计划

作者:Rhian Lewis

  • 2022-07-22
  • 本文字数:3420 字

    阅读完需:约 11 分钟

开源测试:测试人员应该拥抱而不是害怕捉虫赏金计划

开源软件改变了测试人员和开发人员的工作方式。我们比以往任何时候都更多地使用开源库和包,这意味着 Bug 将通过我们团队无法控制的依赖项被引入到我们的软件中。

 

现在,我们也进入了一个开源测试的世界。越来越多的开源项目(以及许多闭源项目)正在采用捉虫赏金计划,要求组织之外的人参与质量和安全过程。

 

基于区块链的 Web3 生态系统日益增长的重要性表明,社区测试是多么的重要。最近的一些例子表明,开源测试人员发现的 Bug 为项目节省了数千万美元。

 

测试界的一些人认为这种趋势是一种威胁。然而,这实际上是一个机会。捉虫赏金计划和开源测试对测试团队来说是一个很好的补充工具,测试人员有充分的理由拥抱这一新趋势而不是害怕它。

测试开源软件所面临的挑战

 

有两个主要的挑战:一个是关于决策,另一个是关于集成。关于决策,根据项目的不同,决策过程也会有所不同。例如,Rails 的开发团队会就发布时间表等东西达成共识。然而,在去中心化的生态系统中,这些决策可能是由社区做出的。例如,去年,DeFi 协议项目 Compound 发现自己处在这样的一种状况:为了达成修复某个 Bug 的共识,代币持有者必须投票批准该提议。

 

因此,你可能不像开发专有软件的公司那样拥有自上而下的组织层级。在这些公司中,有专门的经理或一组经理负责发布软件。

 

在涉及到集成时,这些常常会给测试人员造成麻烦,即使他们的产品不是开源的。开发人员把社区志愿者开发和维护的包或模块带入项目,这些包或模块没有有效的 SLA,如果你的应用程序因为第三方开源库没有更新而发生中断,或者如果你的构建脚本引入了与被测试的应用程序不兼容的版本,无法获得赔偿。连接数据库的辅助包或 API 特别容易受到攻击。

捉虫赏金计划及其目的

 

捉虫赏金计划是一种众包测试的方式。作家 James Surowiecki 在他的《群体的智慧》一书中普及了这个观点,即关注问题的人越多,他们就越有可能找到正确的解决方案。在一个复杂的包含了多种依赖项和集成的系统中,一个小漏洞就可能导致数百万美元的损失,单个测试人员或测试团队不太可能拥有足够的专业知识和预测能力来识别每个潜在的问题。因此,通过赏金激励更广泛的社区来寻找漏洞正变得越来越流行。

 

你可以在自己的网站上发布条款和条件以及奖励表,通过奖励的方式激励社区来查找漏洞。但更常见的情况是,像 HackerOne、BugCrowd 和 ImmuneFi 这样的平台会为你处理整个过程,并为既希望展示自己的能力又希望获得奖励的测试人员和安全研究人员提供一站式服务。

 

对于商业软件,捉虫赏金计划的决定是由高层的少数人做出的。对于开源软件,这个过程就不一样了,尤其是在 Web3 生态系统中。基金会或去中心化自治组织将投票决定是否释放一定比例的资金作为捉虫赏金。

 

典型的例子是Compound的捉虫赏金计划和我协助建立的Boson协议捉虫赏金计划

 

ImmuneFi 的 Compound 捉虫赏金计划就是一个很好的例子,因为它根据漏洞的严重程度明确列出了可获得的奖励(最高可达 5 万美元),并且明确只在一个特定的拉取请求中。ImmuneFi 负责处理所有与支付或争议相关的事项。

 

相比之下,Boson 协议的赏金计划针对所有智能合约——奖金差不多也为 5 万美元——但不包括所有相关网站和非智能合约资产。赏金是直接提供的,而不是通过中间人。

开源捉虫赏金计划优缺点

 

开源测试的优势,即使是对于闭源项目,在于它扩大了漏洞捕捉网,让更多的人为系统的安全做出贡献,而不只是依赖项目正式雇佣的测试团队。一个流行的开源项目通常由一个核心开发团队负责维护,这个团队可能包括测试人员,但与大多数闭源项目一样,他们可能不具备软件开发生命周期需要的专业技能。例如,许多公司已经聘请了专业服务机构来做渗透测试。你可以将捉虫赏金计划看作是一种持续的渗透测试,只在专家发现漏洞时才向他们支付费用。

 

但最重要的是,无论你的项目是怎样的,众包测试总会带来各种不同的方法、思维方式和技能,这是一个人或团队不可能做到的。一个成功的产品或应用程序可能拥有成千上万甚至上百万的用户,他们的使用方式不同,硬件不同,访问路径也不同。如果引导得当,获得更多的技能和见解是一种宝贵的资源。

 

不足的地方主要在于你需要花额外的时间和精力向那些拥有相关技能的人推广你的赏金计划。如果你没有谨慎制定赏金规则,你的公司、基金会或项目可能会为已经发现的漏洞支付赏金。

测试 Web3 生态系统

 

区块链技术(有时也称为 Web3)对测试人员来说是一个非常具有挑战性的领域。原因有很多,我将重点介绍其中比较重要的两个。

 

首先,我们很难在 Staging 环境中复制生产环境的条件。在生产环境中,你可能有数千个验证器和数千个用户,他们可能以你没有想到的方式与系统发生交互。这是不可能复制的。以比特币为例,单从电力方面来看,准确模拟一个实时网络就需要花费数百万美元。

 

其次,Web3 系统被设计成可组合的,也就是说它们可以像乐高积木一样组合在一起。举个简单的例子,为以太坊区块链设计的 ERC20 令牌标准可以转移到任何钱包中,ERC721 NFT 令牌标准也可以。这意味着开发人员可以编写智能合约,在去中心化的交易所创建一个衍生品,然后使用该衍生品在一个完全独立的储蓄协议上产生收入,然后使用产生的收入作为另一个协议的抵押品。这种相互依赖会使风险成倍增加,尤其是当关键组件出错时。

 

事实上,在这些开源协议上投入数千万美元也是一个风险——它就像是一个蜜罐。如果你看一下现有的捉虫赏金计划,有些奖励可能高得离谱,但如果一个成功的赏金猎人能够在漏洞被利用之前找到它,那么成本效益比就变得合理了。

 

例如,Layer2 网络 Polygon 最近向白帽黑客 Gerhard Wagner 支付了 200 万美元,因为他发现了一个漏洞。这似乎是一个令人难以置信的数字,但如果没有发现这个漏洞,8.5 亿美元的资金就会面临风险,当你知道了这个,会不会觉得这个赏金给得非常值(来源:Polygon双重支付问题修复评审——200万美元奖金)。

 

只要看一下赏金平台,如 ImmuneFi,就知道平台目前提供的奖励是什么:例如,Graph 协议中最严重的漏洞可获得 250 万美元,ChainLink 则可获得 500 万美元。

社区主导的测试

 

我强烈认为,测试人员应该参与制定赏金计划,并决定它们应该如何运行。关键在于你要么自己负责这个计划,要么与组织中负责这个计划的人密切合作。你还需要确定由谁来筛选 Bug 以及赏金猎人将如何与你的团队互动。关键是要让测试人员参与定义赏金计划的范围,这样就不会在不重要的问题上浪费赏金,并排除留给测试团队负责的区域。在可能出现边缘情况的领域或需要特定类型专业知识的领域,需要奖励漏洞赏金猎人。

 

例如,之前提到的 Compound 捉虫赏金计划特别提到,该计划针对的是为协议 Comptroller 实现提供的补丁(主要处理风险管理和价格预言)。这涉及专业的金融知识,所以吸引更多的人并从中找到具备这些技能的人是很有意义的。

捉虫赏金计划为测试人员带来的更多好处

 

测试人员还可以参与到他们组织之外的开源软件和捉虫赏金计划中,以此来增强他们的测试技能——甚至可能赚到一些额外的钱。

 

对于测试团队来说,这是一种与社区一起寻找 Bug 和练习 Mob 测试技能的好方法。最著名的平台是 HackerOne 和 BugCrowd,所以请去这些网站上看看有没有一些有趣的东西。走出你的舒适区,去测试一些你之前没有测试过的东西,这总归不是什么坏事。

 

如果你对 Web3 技术感兴趣,那就去 ImmuneFi 看看那里有哪些赏金计划。

彻底的开放性如何改进测试

 

彻底的开放性是一个正在流行的新概念——肯定有适用于测试的场景。2013 年,Anthony D Williams 和 Don Tapscott 在他们合著的“Radical open: Four Unexpected Principles for Success”一书中对这一概念进行了推广,他们认为开放透明为商业环境中的所有利益相关者带来了好处。

 

Andrew Knight 在最近发表的一篇关于开源测试的文章中强调了开源测试的好处:

 

开放透明建立了用户信任。如果用户能够看到测试是如何进行的,他们将对产品质量更有信心。如果他们能看一下活生生的文档,就能更好地使用产品。另一方面,开放透明也会让开发团队保持产品的高质量。

 

他说的不是赏金计划,但原则是一样的。这又回到了群众的智慧上来。参与评审软件及其使用方式的人越多,就越有可能使软件符合预期的目标。

 

作者简介:

 

Rhian Lewis 是一名软件开发者、作家和企业家,自 2013 年以来一直深入参与加密货币和 Web3 社区相关工作。她是 Boson 协议的开发者关系布道者,是由 Kogan Page 出版的《加密货币革命》一书的作者。

 

原文链接

Open-Source Testing: Why Bug Bounty Programs Should Be Embraced, Not Feared

 

2022-07-22 09:153085

评论

发布
暂无评论
发现更多内容

Week 3 总结

黄立

设计模式

架构师训练营第 1 期 - 第三周总结

Todd-Lee

极客大学架构师训练营

架构师训练营 - 作业 - 第三周

Max2012

架构师训练营 - 第 3 周学习总结(1 期)

阿甘

Architecture Phase1 Week3:Design Pattern

phylony-lu

极客大学架构师训练营

spring-boot-route(三)实现多文件上传

Java旅途

Java Spring Boot

观看《寄生兽 生命的准则》有感

徐说科技

自然 生命 生态

好好吃个饭吧,今天想吃什么?你说了算。

叶小鍵

布莱恩·万辛克 减肥、廋身 好好吃饭

硬核测试:Pulsar 与 Kafka 在金融场景下的性能分析

Apache Pulsar

大数据 开源 云原生 Apache Pulsar 消息中间件

【荒于嬉】common pool2 源码阅读纪要

luojiahu

源码阅读 common-pool2

Java语言变量的命名规范

倔强的攻城狮

Java

Week 3 作业1

黄立

架构师训练营第三周作业

Shunyi

极客大学架构师训练营

第三周 代码重构作业

蓝黑

极客大学架构师训练营

架构师训练营 -week03- 作业

大刘

极客大学架构师训练营

极客大学 - 架构师训练营 第三周

9527

第三周作业

华美而火锅

组合模式及单例模式

garlic

极客大学架构师训练营

架构师训练营-week03-总结

大刘

极客大学架构师训练营

Apache Pulsar 9月月报:正在快速成长的下一代分布式消息流平台

Apache Pulsar

大数据 开源 云原生 Apache Pulsar 消息中间件

Architecture Phase1 Week3:HomeWork

phylony-lu

极客大学架构师训练营

架构师训练营 - 第3周课后作业(1 期)

阿甘

第三周-代码重构-学习总结

刘希文

架构一期第三周作业

Airs

训练营 - 第三周 - 作业一

行者

Week 3 命题作业及总结

阿泰

刘华:公有云不仅是自建机房的替代品

刘华Kenneth

架构 DevOps 敏捷 弹性

第三周 代码重构学习总结

蓝黑

极客大学架构师训练营

架构师训练营第 1 期 week3

张建亮

极客大学架构师训练营

架构师训练营第三周学习总结

文智

极客大学架构师训练营

架构师训练营 Week3 - 课后作业

单例模式 组合模式

开源测试:测试人员应该拥抱而不是害怕捉虫赏金计划_软件工程_InfoQ精选文章