软件供应链安全

这是我们关于DevSecOps和软件安全的系列文章的第三部分。还想要更多吗？加入我们即将于9月10日与Maya和Nutanix工程技术总监Jonathan Kohler一起进行的安全网络广播。

今天，开源无处不在-几乎在所有专有代码库和社区项目中。对于组织来说，问题不在于您是否使用开放源代码。这是您正在使用的开放源码，以及使用了多少开放源码。如果您不知道您的软件供应链中有什么，您的一个依赖项中的上游漏洞可能会影响您的应用程序，使您容易受到潜在的危害。在这篇文章中，我们将深入探讨“软件供应链安全”这个术语的含义，为什么它很重要，以及您如何帮助确保项目供应链的安全。

传统上，供应链是交付您的产品所需的任何东西-包括您使用的所有组件。对于你在商店买的巧克力棒，它是成分清单，包装，营养成分的信息，也许还有关于有机成分或生产设施的信息。但它还不止于此：它也是任何可以影响你交付该产品的东西。在炎热的气候中旅行时没有冷藏的巧克力棒也会影响消费的最终产品。

从巧克力到代码库的交换，软件供应链是从开发到开发，通过CI/CD管道进入或影响代码的任何东西，直到它部署到生产中为止。它是软件中的任何东西，如代码、二进制文件和其他组件，以及它们来自何处，如存储库或包管理器。您的软件供应链包括：谁写的、什么时候贡献的、如何审查它的安全问题、已知漏洞、支持的版本、许可证信息-任何时候涉及到它的一切！您的供应链还包括除单个应用程序之外的堆栈的其他部分，包括构建和打包脚本或运行应用程序运行基础架构的软件。软件供应链还包括您想要了解的有关您正在运行的软件的任何信息，以帮助您确定运行该软件的任何风险。

为什么软件供应链对安全性很重要？今天，软件依赖是无处不在的。对于您的项目来说，使用数百个开源依赖项(平均每个存储库203个)是很常见的，因为您不是自己编写整个功能的。行业数据显示，99%的代码库包含开源代码，85%到97%的企业代码库来自开源。这意味着您的应用程序的大部分由您没有编写的代码组成。您的第三方或开源依赖项中的漏洞(想必无法像您编写的代码那样严格控制)会产生巨大的潜在安全风险。

如果其中一个依赖项有漏洞，那么很可能您也有漏洞。这里可怕的是，依赖项可能会在您不知情的情况下更改-即使依赖项中现在存在漏洞，但在您的应用程序中无法利用，代码库内部或外部的更改可能会使您将来容易受到影响。能够利用数以千计的开源开发人员的工作意味着数以千计的陌生人可以有效地提交对您的产品代码的访问。因此，一个未打补丁的漏洞、一个无辜的错误或对您供应链中的依赖项的恶意攻击都会对您产生深远的影响。

当恶意代码被故意添加到组件中，利用该组件的供应链将代码分发给其目标时，就会发生软件供应链攻击。供应链攻击是真实存在的。有几种方法可以攻击供应链，从直接插入恶意代码作为新的提交者，到接管提交者帐户以在不被其他人注意到的情况下这样做，或者泄露签名密钥以分发不是正式组件一部分的软件。然而，软件供应链攻击本身很少是最终目标。相反，这是一个插入恶意软件进行加密的机会，或者是插入后门进行僵尸网络访问的机会。

软件供应链攻击仍然很少见，一年只有不到几十次妥协(据我们所知)。它们也往往具有很高的针对性；例如，民族国家攻击能源行业的公司，因此不是一个广泛适用的危险。到目前为止，针对开源安全的广泛攻击仍然不常见。

软件供应链攻击最著名的例子可能是TO-EVENT-STREAM，这是一个可通过NPM获得的广泛使用的Node.js库。2018年秋天，一位新用户自愿接管GitHub上的Event-Stream。作者对额外的帮助表示欢迎，甚至给了新来的人出版权。几周后，新用户向事件流、平面映射流添加了一个新的依赖项。然后在接下来的一周，同一个用户重写了代码以不再需要平面映射流依赖，并试图删除它。这一更改是在代码库中进行的，但不幸的是没有被推向NPM上托管库的位置。10月份，另一名用户在Flat Map-Stream中添加了恶意软件。任何使用Event-Stream并拉入最新版本的Flat Map-Stream的人都会收到此恶意软件。需要强调的是，这里不能责怪库作者--谁没有欢迎额外帮助的开放源码项目呢？

尽管像Event-Stream这样的直接供应链攻击很少见，但未打补丁的软件并不少见。如今，开源在企业中的使用意义重大，预计不会减慢--开源已经赢了。鉴于我们不会停止使用开源软件(我们也不应该！)，今天对供应链安全的威胁是未打补丁的软件。了解了这一点，您如何解决项目依赖项有漏洞的风险呢？

幸运的是，据估计，开放源码中85%的漏洞都是在已有补丁的情况下披露的，因此您所要做的就是应用补丁来保持安全。但是，在解决软件供应链威胁方面要积极主动并取得成功，而不仅仅是打补丁。遵循DevSecOps意味着您需要将安全性作为软件开发的持续部分来处理，这也意味着您需要定期了解您使用的依赖项，了解这些依赖项中的漏洞，对其进行修补-然后重新开始工作！作为一名开发人员，这意味着要具备以下能力：

了解您的环境中有什么。这需要发现您的依赖关系，包括可传递的依赖关系；并了解这些依赖关系的风险，例如漏洞和许可限制。

管理您的依赖项。当发现新的安全漏洞时，首先确定您是否受到影响，如果受到影响，请更新以获取最新的功能和安全补丁。并通过检查引入新依赖项的更改并定期修剪以删除不必要的依赖项来保持对依赖项的控制。

监控您的供应链。审核您为管理依赖项而实施的控制措施，最终，从审核转向强制执行，以防止供应链中的漂移。

我们在保护软件供应链的道路上只有几步之遥，但除了修补依赖关系之外，还有更多值得兴奋的事情。该行业正在努力实现几个理想，以增加对供应链的信任，包括确保完整性和核实来源。供应链的完整性是确保组件如其所说的那样-您可以信任巧克力包装纸上列出的配料。例如，这可以使用可复制的构建来实现。起源是关于了解特定组件的来源，以便您可以信任该组件的提供者或该组件上的元数据；例如，使用签名的构建或透明度日志。这些与软件物料清单(SBOM)的概念密切相关，它将为您提供软件中组件的列表，就像巧克力制造商提供的经过验证的配料列表一样。

我们的目标是让GitHub领导和支持开发人员、维护员、企业和研究人员保护世界上的软件。为了做到这一点，我们正在进行投资，以确保开源社区拥有他们需要的工具来保护他们的软件，并使开发人员和企业能够轻松地管理他们使用的依赖项。

作为开发人员，理解和维护依赖项是第一步。这通常是通过软件组合分析(SCA)来实现的，SCA是一组工具，可以帮助您确定使用哪些依赖项、发现这些依赖项中的漏洞并对其进行修补-这正是我们一直在谈论的内容。在GitHub上，SCA功能由以下几个功能提供：

依赖关系图标识存储库或包的所有上游依赖项和公共下游依赖项。您可以在依赖关系图中看到他们项目的依赖关系，以及任何检测到的漏洞。

Dependabot警报根据依存关系图和GitHub咨询数据库，提醒您受新发现的漏洞影响的资料库。

Dependabot安全更新是从Dependabot发送给您的请求，目的是将依赖项更新为解决已知漏洞的最低版本。Dependabot版本更新还会根据您设置的计划检查依赖项的新版本，并建议更新。

简单地说，软件供应链就是进入或影响您的代码的任何东西。尽管供应链妥协是真实的，并且越来越受欢迎，但它们仍然极其罕见-因此，保护供应链最重要的事情就是修补您的漏洞。然后，要成功保护您的软件供应链，您需要了解环境中的依赖项，了解这些依赖项中的漏洞，并快速修补它们。启用GitHub原生SCA功能：依赖关系图、Dependabot警报以及Dependabot安全和版本更新，以自动执行依赖项管理和修补的艰苦工作。

想看看供应链安全在实践中是什么样子吗？与我和Nutanix工程技术总监Jonathan Kohler一起参加我们9月10日的下一次GitHub网络广播。我们将深入了解您的供应链、您的依赖关系，以及Nutanix如何与GitHub构建安全的供应链。