现代企业软件通常由一些定制代码和越来越多的第三方组件构成，既有闭源也有开源。这些第三方组件自身也经常有部分功能来自其他第三方组件。提供这些组件（及其依赖项）的所有供应商和存储库就构成了软件供应链的主体。但不仅仅是代码，软件产品的供应链还包括维持软件运行的所有人员、服务和基础设施。总结一下就是：软件供应链通常是一张庞大而复杂的网络，其中聚集了各种代码源、硬件和人员，共同制造、支持和交付更大的软件产品。

采用第三方和开源软件可以帮助组织节省时间和资金，解放内部开发人员的双手，让他们得以去创造新颖的软件而不是重新发明轮子，但这是有代价的。这些组件的创建和维护人员并非组织聘用的员工，可能不会遵循其采用的那套安全策略、实践和质量标准。这就带来了固有的安全风险，因为策略之间的差异和不一致可能会形成被忽略掉的薄弱区域，容易遭到攻击者利用。

攻击者突破软件供应链安全防线的途径有很多，比如：

• 利用第三方组件的漏洞
• 入侵第三方开发环境并注入恶意软件
• 创建恶意虚假组件

软件供应链安全旨在检测、预防和缓解此类威胁及源于组织所用第三方组件的任何其他威胁。作为持续集成与持续交付（CI/CD）系列指南之一，本文将讨论软件供应链攻击和挫败此类攻击的最佳方式。

根据美国国家标准与技术研究院（NIST）的描述，如果攻击者“渗透进软件供应商的网络，并在软件交付给客户之前使用恶意代码损害软件，即视为发生了软件供应链攻击。受损软件后续会危害客户的数据或系统。”换个说法：黑客入侵了你信任的供应商并将恶意代码注入到其产品中，然后这些产品最终会进入到你的系统里，可能会导致黑客能够访问你的敏感数据，或者破坏你的代码从而染指你的客户，让你面临勒索软件攻击或其他恶意活动风险。受损供应商软件可能从一开始就被悄悄篡改了，或者是后来才被攻破，通过补丁或修复程序等更新进行部署。这些攻击可不是什么小事，可能造成严重损失，影响受损软件的所有用户，比如政府、关键基础设施和私营产业软件用户。

攻击者通常会找寻供应链中防护较弱的环节，利用这一环节在供应链中向上或横向移动，直至抵达其真正目标。他们利用信任关系入侵采用初始受害者组件、产品或服务的组织，只需一次成功的漏洞利用即可渗透进大量防护良好的组织。

软件供应链攻击很特别，因为这种攻击将重点从目标组织的内部防御转移到其供应商的内部防御上。防护严密的组织可能不值得花费时间和精力去直接攻击。但如果该组织采用了安全措施薄弱的供应商，攻击者就可以对供应商下手，入侵其网络或开发过程。一旦得手，攻击者就能以此为据点，进而渗透到原本防护良好的组织系统中。

托管服务提供商（MSP）是供应链攻击的常见目标。组织会采用MSP外包技术岗位，包括与网络和系统管理等高度敏感的工作有关的那些岗位。只要入侵MSP，攻击者就能立即获得其所有客户的企业网络的访问权。这些类型的攻击可用于策划勒索软件攻击、销售点入侵和商务电邮入侵（BEC）欺诈。近些年，此类攻击急速增长，多个国家的政府网络安全组织都认为这一趋势还会持续。2021年发布的一份报告估计，对单个MSP或托管安全服务提供商（MSSP）进行网络攻击可导致数百家企业产生高达800亿美元的经济损失。

MSP攻击利用的是特权访问，而其他供应链攻击则入侵软件供应商的系统并植入恶意软件。该恶意软件随后会传播到供应商的客户处。灾难性的SolarWinds攻击就使用了这种方法。这场著名的供应链攻击中，攻击者将恶意软件植入了SolarWinds签名的软件更新中，并将此看似无害的更新包分发给了其客户。思科、SAP、英特尔、德勤、英伟达、富士通和乐天等大型跨国企业都遭遇了攻击。该攻击的影响非常深远，甚至难以计算企业到底花了多少钱用于善后，但据估计高达1000亿美元。

供应链攻击会用到的另一个恶意软件来源是npm和rubygems等包注册表的恶意软件包，这倒不是什么新鲜招数，但最近突然颇为流行。攻击者依靠品牌劫持、误植域名、依赖项劫持和依赖项混淆来诱骗疲惫或漫不经心的开发人员，使其下载伪装成可信开源软件的恶意软件。下载后，攻击者就可以利用恶意包中的恶意软件盗取用户名和密码等私密信息，用以在组织的基础设施中横向移动，并向外突破，染指组织的客户和合作伙伴。

通常，初始供应链攻击不过是攻击者计划的第一步。在初始入侵之后，攻击者往往会尝试横向移动和提权，从而加深其对网络的控制，获得更多敏感系统的访问权。随后，或者与此同时，攻击者可能会盗取敏感数据、破坏运营系统，或者像勒索软件攻击一样敲诈受害组织。

供应链攻击可能需要几个月才能成功，但往往很长一段时间内都不会被发现。类似于高级持续性威胁（APT）攻击，供应链攻击通常既具有针对性又高度复杂。

即便采用了卓越的传统网络安全防御措施，组织在面对供应链攻击的时候仍然可能十分脆弱。事实上，供应链攻击可能正在增多，因为很多组织都加强了自身传统安全措施，攻击者已经摘不到多少唾手可得的果实了。然而，尽管软件成分分析（SCA）等一些安全解决方案会评估第三方软件的风险，大多数传统网络安全方法的隐式信任已经包含在产品或服务中的元素。组织可能在采用先进的防火墙和端点安全技术，但这些技术，或者该组织基础设施中的其他部分，仍有可能被供应链攻击突破。

欧盟网络安全局（ENISA）的一份报告显示，上报的供应链攻击中大约66%使用了供应商代码来入侵供应商的客户。考虑到开源包注册表中恶意软件包的上升趋势，开源软件是另一个风险甚大的领域。组织应将重点放在所有要用的第三方软件都未遭篡改上。

ENISA的另一重要发现是，所分析的供应链攻击中，超过半数供应商要么不知道攻击已经发生，要么隐瞒了攻击已发生的事实。但是，89%的受访客户组织确实知道其基础设施遭到的攻击是怎么发生的。这表明供应商与其企业客户之间在安全事件报告的成熟度方面存在差距。

下列最佳实践可帮助组织应对下一场供应链攻击。

1快速响应漏洞

快速识别并修复第三方组件中的漏洞应成为防止供应链攻击的首要策略。虽然有些供应链攻击利用的是未知（零日）漏洞，但很多此类攻击利用已知漏洞。组织应当生成软件物料清单（SBOM）盘点其第三方软件，识别存在已知漏洞的组件，并尽快应用相关更新和补丁。

2维持供应链深度可见

如果找不出来，那就算知道自己有啥东西也没用。组织需要了解自家软件产品组合在哪些地方用了组件，这些组件都是怎么接入系统和源代码的。如果发现漏洞，开发人员需要知道多个软件项目中用到该脆弱组件的确切位置，这样才能有效修复或清除漏洞。

3标记潜在脆弱组件

由于急着赶在截止日期前完成项目，开发人员会不断找来可能含有漏洞的新软件组件。组织最好左移供应链安全，确保开发人员拥有所需的知识、支持和工具，避免在软件开发生命周期早期选择了脆弱或不安全的组件。

一旦发现潜在脆弱组件，应当标记该组件，从而确保所有开发团队都注意到。只要使用正确的工具，就可以设置被标记的组件或那些失败的漏洞扫描，使之“中断构建过程”，自动阻止这些组件被部署到产品中——持续集成/持续交付管道必备。

4持续监测组件

现在安全的组件未来不一定仍然安全。新漏洞层出不穷，组件会迎来生命周期终止之时，开源贡献者也可能会抛弃项目，终结支持。以上任何一种情况下，你都必须能够检测组件风险状况的变化，确定风险严重性的轻重缓急，并在必要时移除特定组件。

此外，还有一个重要因素需考虑：别忘了审查供应商

在第三方软件的问题上，跟产品经理聊聊的机会可不常有，但如果要为公司进行大笔采购，那就绝对应该问问供应商的安全实践是怎样的了。他们是如何维持产品安全且不遭篡改的？使用了哪些工具？怎么保持对自身供应链的可见性？

— 【 THE END 】—