为什么你应该接受错误赏金计划

nehakakkar

2013年8月1日，骑士资本集团开通交易业务。Knight 拥有 1,400 多名员工，是美国最大的股票交易商，在纽约证券交易所和纳斯达克市场的市场份额分别为 17.3% 和 16.9%。对于任何经纪人来说，在骑士资本这样的地方工作都是一个梦想。 但今天与其他任何一天都不一样。上午 9:00，纽约证券交易所开市时，当天第一位散户投资者下达了入市指令。仅仅 45 分钟后，Knight Capital 的软件就执行了超过 400 万笔交易，使公司损失了 4.6 亿美元，并处于破产边缘。 发生了什么？与大多数灾难一样，这是一系列不幸的事件，与计算机代码有关。前一天，开发团队推送了生产环境的更新。从表面上看，没什么大不了的，但意外部署的错误是一颗定时炸弹。 错误的范围可以从轻微的烦人到彻底的破坏性。有时它们被视为一项技术的怪癖，就像 JavaScript 社区接受其对浮点数的复杂理解是其魅力的一部分一样。 有时，错误可能是毁灭性的，影响全球数百万用户。一个典型的例子是Log4j 的崩溃，它让技术社区连续数周陷入了激烈的争斗。 对于那些不知道的人来说，Log4j 是市场上最流行的基于 Java 的日志实用程序之一。发现了一个漏洞，允许第三方在目标计算机上远程执行代码，从而窃取数据或安装恶意软件。


这个问题有多大？Akamai Technologies报告称，仅在美国，每小时就有超过 1000 万次利用该漏洞的尝试，考虑到 Apple、Amazon 和 Twitter 等公司都依赖 Log4j，您可以开始了解该漏洞的敏感程度。 但什么是错误？ 软件错误是计算机软件中的错误或缺陷，导致其产生不正确或意外的结果，或者以意想不到的方式运行。与普遍的看法相反，错误不一定是由编写糟糕的代码引起的（尽管我们不能不同意这是主要原因之一）。 以美国宇航局的气候轨 厄瓜多尔手机号码列表 道飞行器为例，该项目耗资 1.25 亿美元，但在火星表面坠毁并燃烧。原因？该软件的一个部分计算了推进器需要施加的力（以磅为单位）。而另一个人则假设数据采用公制单位来读取数据。 孤立地看，每段代码都在执行其预期的操作。问题是沟通不畅，科罗拉多州洛克希德·马丁宇航公司的工程顾问运行了这些数字，但忘记将它们转换为公制。另一方面，美国宇航局假设计算单位是牛顿每平方米，因为它是标准。 另一个例子，Knight Capital的错误是由于一些遗留代码从未从他们的系统中删除，更新附带的标志之一触发了旧代码，并使软件处于测试环境中，因此它尝试处理尽可能多的操作。 通过对事件的审查，调查发现 Knight Capital 没有正式的代码审查或 QA 部门。




换句话说，没有人被指派去检查可能存在的错误。他们没有足够的保障措施。 不幸的是，QA 部门、DevOps 工程、软件测试和代码审查不足以防止错误。有时我们充其量只能在生产中发现错误并尝试尽快修复它们。 外部视角 软件是在非常特定的环境中开发的，在必须遵守用户要求、在截止日期前工作、与其他开发人员协调工作流程以及必须响应最后一刻的更改之间，错误可能会被忽视。 俗话说，事后诸葛亮是 20/20，事后审查代码与在压力下审查代码是完全不同的事情。每个软件开发人员都审查过他们过去所做的代码，并意识到他们可以做得更好。如果不是凌晨 4 点，而且距离投入生产还有 10 个小时，那么说起来很容易。 另一方面，用户在不同的环境中使用我们的产品。他们可以在闲暇时在自己的平台上使用它。因此，用户遇到错误的情况并不少见。 对于用户来说，错误可能会很奇怪，也可能会令人彻底沮丧，但如果有一种方法可以让错误使用户、编码社区和我们自己受益呢？ 进入错误赏金计划 错误赏金计划是许多网站、组织和软件开发商提供的一项交易，通过该计划，个人可以因报告错误（尤其是与安全漏洞相关的错误）而获得认可和补偿。 Bug Bounty 非常受欢迎，一些业内最大的科技公司（包括 Twitter 和 Google）都在使用它。