使用了很多开源软件，但你知道怎么处理对应的漏洞吗？

作者｜Rami Sass

编辑｜姚佳灵

尽管在 2017 年 9 月的 Equifax 遭受黑客攻击后引发了冲击波，但是业界在保护产品方面仍然有很长的路要走。一个需要关注的关键领域是占据现代应用程序整个代码库 60%-80% 的开源组件。让我们来了解一下如何检测易受攻击的开源组件并确保产品的安全性。

去年 9 月，当围绕着信用评级机构 Equifax 被黑客攻击的新闻流传开来时，世界上大部分的人才突然知道开源漏洞这个概念。攻击者利用了 Apache Struts2 开源组件的一个漏洞，窃取了大约 1.479 亿人的身份信息，其中大部分是美国人。

从表面上看，该公司没有意识到其 web 应用程序中正在使用易受攻击的开源组件，并且没有及时打上补丁以避免受到攻击。

尽管像 Heartbleed 这样的黑客攻击在短时间内吸引了大众的注意力，但是在本次攻击中被窃取信息的数量和质量范围引起了公众更多的关注。

这也给组织敲响了一次警钟，他们有更大的责任来保护那些用于保卫其用户数据的代码，即使这些代码不是他们编写的也应如此。这些代码通常以开源组件的形式出现，可以免费试用，并被开发者出于及时向市场交付产品的目而广泛采用。开发人员依赖开源组件提供的有用功能，如果不使用开源组件的话，他们就得自己编写。据报道，开源组件的使用在不断增长，Gartner 预计，在我们知道并喜爱的大多数产品中开源代码占据了 80%。

然而，尽管有这些漏洞，但是开源组件的安全性仍然被太多公司忽视，他们没有意识到这种威胁的规模，甚至没有意识到他们真正使用的开源组件的数量。

缺乏关注的主要原因之一似乎是，这些组织无视开源漏洞是什么、它们是如何被发现的以及他们应该怎样保护自己和客户。

回到最基本的问题：什么是开源漏洞

开源中的漏洞和专有产品中的漏洞类似。这些代码要么是编写出错导致黑客可以加以利用的，要么是允许黑客以开发人员不希望的方式执行有害的操作。

在某些情况下，可以利用开源漏洞发起拒绝服务攻击（denial of service，简称 DoS）并使服务下线，而其他更严重的漏洞则可能允许黑客进行远程访问，让他们拥有进入系统的“钥匙”。

然而，开源代码和专有代码之间的相似之处仅此而已。内部代码是由一组开发人员遵循其组织集中指导编写出来的，而开源代码高度分散于编写、修复和维护项目的社区成员中。

集中控制系统和分布式系统常常被称为大教堂（Cathedral）和集市（Bazaar）。开源代码没有一个独立组织的中心设计来规划其逻辑，并且缺乏标准化的系统来解决新特性的添加和修复事宜，它们遵循的是一个不同的、通常更松散的规则集，使得它们更加难以管理。

对于组织来说，涉足这个混乱的领域是很复杂的且难以掌控的，但是对于黑客们来说，开源代码缺乏集中控制则是个福音。很多时候，开发人员会从像 GitHub 等网站上的众多存储库中获取源代码，而不会去检查组件是否存在任何已知漏洞。更糟糕的是，很少有人会在其代码库或产品中跟踪开源代码的解决方案。

因此，就像我们在 Equifax 的案例中看到的那样，他们并不知道他们正在依赖易受攻击的代码，而且根本不知道这些漏洞的存在，因此也无法为其打补丁。跟很多开发代码的组织一样，Equifax 可能一直在用某个工具测试他们应用程序中的代码，但是，很明显，他们没有一个为分析开源组件而构建的工具。

开源代码的漏洞是怎么找到的？谁在寻找这些漏洞？

静态应用程序安全测试（Static Application Security Testing，简称 SAST）或动态应用程序安全测试（Dynamic Application Security Testing，简称 DAST）这样的安全工具知道如何与专有代码良好协作。它们采用组织内编写代码的逻辑，使用一组像白名单（Whitelist）这样的规则来查找代码中可能被攻击者入侵的潜在缺陷。

然而，由于开源组件是按照不同的方式搭建的，因此这些工具对于查找漏洞来说用处不大。相反，我们要依靠大量的研究人员和社区成员，他们会花费时间在整个代码中查找漏洞。他们沉浸于代码之中，对代码进行细致检查、尝试各种可能会使程序出错的理论、编写攻击代码，目的就是让应用程序失去保护自己的能力。

尽管他们确实会利用一些自动化工具去找出代码中那些容易找到的漏洞，但是，这个测试过程是一项漫长而艰巨的任务。据估计，研究人员可能平均要花 3 个月的时间才能找到一个漏洞。

从本质上讲，开源软件是个活生生的、有生命力的实体，由一群开发人员维护，他们贡献自己的时间以构建更好的项目。为了使项目更加健壮，很多社区成员自己花时间来寻找漏洞，当他们发现可能被对社会不满者、罪犯甚至在有些情况下是国家行为者利用的代码时，会提醒项目管理人员。很多这样的研究人员出于对开源代码的热爱和尊敬，为了帮助代码更安全做出了自己的贡献。

然后，那些赏金猎人（用了最好听的方式来称呼他们）为了那些冷冰冰的现金奖励而寻找漏洞。最近几年，一个迷你行业正在兴起，帮助黑客们改邪归正，允许他们利用自己邪恶的本领来做好事。很多像微软这样的大型组织已经为白帽黑客设立了漏洞赏金计划，以用于报告漏洞并获得报酬。

HackerOne 和 Bugcrowd 是为各家公司甚至美国政府运营这些漏洞赏金计划的两大巨头。为了避免错失其中的乐趣，在开源社区里也有一些 bug 赏金倡议，它们得到了一些主要参与者的支持。

早在 2014 年，Linux 基金会（Linux Foundation）为了应对 Heartbleed 漏洞而建立核心基础架构联盟（Core Infrastructure Initiative）计划。他们成功地引进了微软、英特尔、谷歌、IBM、亚马逊、VMware 和许多其他的行业领导者，募集了 3 百多万美元赏金。另一个众所周知的开源计划是非营利性 bug 悬赏项目（Internet Bug Bounty，简称 IBB）倡议，获得了脸书、福特基金会（Ford Foundation）以及最重要的 GitHub 的支持，每一家都提供了 10 万美元以支付研究人员。

暴露开源漏洞之后的响应

当研究人员最终在项目中发现漏洞时，会通知相关各方以启动一系列操作。

研究人员首先要做的是，把他们的发现发送给受美国政府支持的非营利 MITRE 公司，该公司是维护通用漏洞披露平台（Common Vulnerabilities and Exposures，简称 CVE）漏洞注册的机构。然后，MITRE 的工作人员将分析漏洞以确认，并提供关于漏洞的信息。这通常包括严重性评级，漏洞如何被利用的细节，最好还要有到修补程序的链接以便于修复该漏洞。在这个阶段，漏洞会得到一个 ID。其中包括被报告的年份和唯一的 ID 号码。比如，用于攻击 Equifax 的 Apache Struts2 漏洞被标识为 CVE-2017-5638。

MITRE 维护的 CVE 系统的组织化程度还远远不够，因此，漏洞信息会在国家漏洞数据库（National Vulnerability Database，简称 NVD）上列出，该数据库是一个很好的目录。

与此同时，研究人员还将联络开源组件的项目管理人员，通知他们有问题要处理。在正常情况下，根据公平竞争原则，研究人员在把他们的发现公布于众之前，会给项目管理人员大概 60 到 90 天的时间以找出漏洞的修复方案。幸运的话，项目管理人员会在截止时间前提出解决方案。

在 CVE 公布于众后，所有人都能获得该信息，其成为已知漏洞。这其中包括好人，他们会利用该信息为自己的应用程序打补丁，而那些得到免费信息的坏人，则能利用该信息攻击那些打补丁很慢的公司。

正因为如此，已知漏洞是开源组件的主要威胁。既然大量漏洞的详细信息在 NVD 上免费列出，黑客们为什么还要浪费时间自己去找漏洞呢？

保护你的开源组件

正如我们在这里看到的那样，当涉及开源代码时，安全团队面临的挑战就不是自己在代码里面找出漏洞，而是在已知漏洞变得可用时，他们得做好准备。

要保持这些开源组件的安全，有两件事需要解决。

第一件要解决的事情就是需要掌握在代码库和产品中所使用的开源组件是否包含现有漏洞。如果你的开发人员还没有使用工具去跟踪他们拥有的组件以及那些组件的安全状态，那么他们可能会发现自己跟 Equifax 一样，处于缺乏关键可见性信息的境地。

除此之外，尽管我们可以修复脆弱的“必备”的组件中的问题，开发人员还是应该避免在构建新产品时，使用那些有已知漏洞的组件。这意味着，在把开源组件加入到你的代码库或产品中前，要利用可以检测脆弱组件的解决方案，甚至可以利用自动化策略，如果开发人员试图提交一段有风险的代码时，该策略就让构建失败。

保证产品和产品中内含数据的安全，已经成为客户的期望，因此需要应用正确的工具以在黑客们攻击之前就能找到含有已知漏洞的组件。

由于大量的开源组件在业界广泛使用，开发人员和安全团队需要采用自动化的解决方案来跟踪所有在他们的代码库和产品中用到的开源组件，同时监控像 NVD 这样的漏洞数据库以在研究人员发现新的漏洞时接收到警报。

像 WhiteSource 和 Flexera 这样的软件组件分析（Software Composition Analysis，简称 SCA）工具正是为此目的而设计的，也是应用程序安全策略的重要组成部分，通过这种方式，我们就能赶在黑客的前面，这样的话才能维护客户信任同时保持产品的安全。未能实施 SCA 工具会让组织面临攻击，老实说，没人想成为下一个 Equifax。

---

最后，推荐我们精心打磨的 CI/CD 专栏，希望能帮你的团队快速构建一个高效的持续交付体系。