如何应对软件供应链安全风险？

近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重，其中，开源软件的安全问题尤其值得关注。

据Sonatype的第八次年度软件供应链状况 告显示，截至今年为止，专家们已经发现了88000个恶意开源包，比2019年的同一数字增加了三位数，表明企业的攻击面正在快速增长。该 告是根据公共和专有数据分析编制的，包括1310亿次Maven Central下载和成千上万的开源项目。

另外也了解到，超过90%的软件应用程序使用开源组件，但使用开源软件在提高开发人员的开发效率的同时，也给软件应用程序的安全带来了更多不确定性。而且，在数字化转型加速的当下，在推动创新的过程中，开源的复杂性和开发速度也限制了软件供应链安全控制的有效性。

据研究预测，到2025年，全球45%的组织将会遭受一次或多次软件供应链攻击，82%的CIO认为他们将更容易受到攻击。这些攻击包括通过广泛使用的软件组件（如Log4j）中的漏洞进行的攻击，对构建管道的攻击（例如：SolarWinds、Kaseya和Codecov黑客攻击），或黑客破坏软件包存储库本身。

而正由于软件供应链攻击变得如此普遍，以至于Gartner将其列为2022年的第二大威胁。

什么是软件供应链安全？

企业软件项目越来越趋于依靠第三方和开源组件，该类组件由个人创建和维护，由于其与开发重要软件的组织无雇佣关系，所以第三方不一定使用与软件开发组织相同的安全策略。

这点存在着一定的安全风险，因为个人创建的安全策略与组织创建的安全策略二者之间存在着差异或不一致性，这可能会导致出现易被忽视的脆弱区域，从而给攻击者以可乘之机。

而供应链安全就在于预防、检测和缓解该类风险以及来自于组织以外第三方组件的任何其他风险。此外，软件供应链还应该包括各种人员，如外包公司、顾问和承包商。因此，软件供应链安全也可将风险管理和 络安全原则结合起来。这样做可以检测、减轻和最小化与应用程序中这些第三方组件相关的风险。

软件供应链安全风险来自哪里？

软件供应链风险的存在是因为企业对供应链的信任。例如，没有人觉得微软会发布一个安全补丁，将他们的环境暴露给攻击者。攻击者恰恰利用了这种信任，因为他们知道大多数开发人员不会不遗余力的交叉检查他们正在使用的软件。

而且由于企业对供应链的信任，开源项目也是软件供应链安全风险之一。例如，对开源项目的提交权限通常授予受信任的贡献者，若是攻击者破坏了一个受信任的账户，他们可以将恶意代码插入到存储库中，那么开发人员不知不觉的使用了这些代码，从而无意中打开了对环境的访问权限，让企业陷入危险境地。

再者，软件供应链安全风险还来自于外部攻击。以软件应用程序为例，软件应用程序的生命周期包括设计、生产、交付、部署、使用及运营、停止等阶段，而面向此生命周期所涉及的分工协作、联合攻关、平台环境等就是软件供应链的主要内容，也因此，软件供应链的主要攻击类型也与这些环节密切相关。

例如，在生产阶段（包括软件应用程序的开发、集成、构建等），供应链攻击类型主要包括三类：

第一类是针对软件生产要素的攻击，即攻击者利用安全漏洞、后门等修改编码环境、源码库等开发工具或软件自身，植入恶意代码，并经 络、存储介质等进行传播，用户下载使用后，引入风险；

第二类是开发者对所使用的第三方软件，特别是开源组件未经安全测试而直接使用，不了解其中的安全漏洞和法律风险；

第三类是软件产品构建时，在编译和链接、产品容器化、打包等过程中，使用的工具或产品对象本身被污染或恶意修改而带来的安全风险，如 Codecov事件。

在交付和运营阶段（包括软件应用程序的发布、传输、下载、安装、补丁升级等），互联 或移动传输介质是其重要手段。因而，软件供应链安全风险主要体现在这几方面：

在发布和下载方面，发布渠道或商城如对软件安全性缺乏分析和测试则会存在潜在风险；攻击者可通过捆绑攻击，在常用软件中捆绑额外功能，如果这些功能涉及用户隐私、信息的收集，则后患无穷；针对发布站点的攻击，如域名劫持（DNS）、内容分发系统（CDN）缓存节点篡改等，会使用户下载存在恶意代码或后门的软件。

在软件更新和升级方面，攻击者可能通过中间人攻击替换升级软件或补丁包，或诱导用户从非官方发布渠道下载，以达到攻击的目的，也可能使用捆绑攻击在升级包中增加额外软件功能。例如，许多公司每个月都会发布新的安全补丁，这些补丁会被成千上万的开发人员下载，已部署到他们的项目和CI（持续集成）/CD（持续交付）管道中。如果攻击者可以操纵一个更新，那么他们就可以轻松的访问部署该更新的所有系统。

另外，第三方开发人员也是软件供应链安全风险之一。例如，许多公司现在雇用承包商或自由职业者进行应用程序开发，如果没有进行适当的背景调查，恶意的外部组织可以轻松的窃取数据或IP，以获取经济利益或从事工业间谍活动。

而上述仅是软件供应链安全的部分风险，此外还包括证书被盗、软件开发工具被破坏、设备预先安装了恶意软件等等安全风险。

如何应对软件供应链安全风险？

为了确保软件供应链的安全性，需要对应用程序的每个部分都有一个清晰的视图和控制，可以从以下几点着手：

一，推广使用软件物料清单（SBOM）：软件物料清单（SBOM）是一种正式的、结构化的记录。它不仅对软件产品的组件构成进行了详细的说明，同时还描述了这些组件之间的供应链关系。SBOM概述了应用程序中引入的包和库，以及这些包、库与其他上游项目之间的关系。这在重用代码与引入开源代码的时候非常有用。

软件物料清单（SBOM）可以帮助开发人员和用户了解他们开发和使用的软件所包含的内容，帮助组织了解依赖关系 络及其软件开发过程的攻击面。因而，一个合适的SBOM，可以帮助组织对自己所部署的包以及这些包的版本有一个确切的了解，从而便于组织根据自己的需要来进行更新，以维护安全。

但需要注意的是，SBOM对于已经拥有软件组件和API资产管理的组织最为有用；静态格式的SBOM只能提供软件当时的情况相关信息，而无法时刻更新即时的相关内容；为了使数据更加有意义，SBOM必须具有连续交付和访问的能力。

此外，虽然一些供应链攻击方法利用了未知（零日）漏洞，但还是有很多攻击利用了已知漏洞。基于此点，企业还可以利用软件材料清单（SBOM），识别存在已知漏洞的组件，并应用相关更新或补丁。快速识别和修复第三方组件中的漏洞是预防供应链攻击的主要策略。

三，评估软件供应链：为了让应用程序的依赖关系具有完全的可见性，需要对一些问题进行评估，例如：开发生命周期的每个步骤涉及到什么；是否有承包商具有代码访问权限；谁安装软件更新，如何安装，等等。

企业还需要了解其软件组合中使用的组件，并且充分认识和了解组件、系统和源代码之间的关系。当发现漏洞时，开发人员需要知道易受攻击的组件在多个软件项目中的使用位置，以便能够进行快速修复或删除。另外，一旦发现问题组件，就应该对之进行标记，从而确保所有开发团队都清楚该问题组件。

在评估软件供应链时，还要评估任何潜在合作伙伴的可信度、服务历史、过去的项目和市场声誉。对于个人来说，要经常进行严格的背景审查，以确定诸如犯罪记录或破产申请之类的危险行为；对供应商和服务提供商进行类似的尽职调查，事实上，一些法规要求某些供应商必须具备ISO 27001这样的资质。

四，持续监控第三方，持续监控组件：持续监控第三方有助于减轻供应商泄露或攻击的影响，例如在暗 中暴露出来的证书或者任何过去数据泄露的历史，企业可以要求并检查任何供应商的安全文档，以确保其政策和程序符合行业最佳实践和相应安全标准。

持续监控组件，即使一个组件已经被确定为安全组件，也不意味着它会保持安全。新的漏洞会不断出现，组件使用寿命也可能已快要耗尽，或者其开源贡献者可能会放弃组件并对其停止支持。在所有这些情况下，企业必须能够检测到组件风险状态的变化，确定风险严重程度的优先级，并在必要时关闭组件。

最后，值得一提的是，企业需要建立一个事故响应计划，一个有效的灾难恢复计划应该包括传统的备份或故障转移站点，同时经过测试的恢复机制可以防止系统受到勒索软件的攻击。