四年前，SolarWinds 供应链攻击事件闹得”沸沸扬扬“，将供应链安全问题与危害性摆在”明面上”，如今四年过去了，我们又陆续经历了包括 Apache Log4j2 在内的多个供应链事件，接下来组织与企业该如何应对供应链安全的挑战？
2020 年底，威胁攻击者成功入侵 SolarWinds Orion 软件的开发环境，在其中植入大量恶意代码。此后，包括美国国务院、五角大楼、国土安全部、商务部、财政部、国家核安全委员会等政府部门以及多个财富 500 强在内的 SolarWinds Orion 客户相继遭到网络袭击。
SolarWinds 公司后续披露调查结果显示，早在 2019 年 9 月，威胁攻击者可能已经秘密访问其内部网络系统，对文件 SolarWinds.Orion.Core.BusinessLayer.dll 的源代码进行篡改，并添加了后门代码。几天后，便开始在编译服务器上修改产品发布流程，植入恶意代码并进行测试，这一过程持续近两个月。SolarWinds 供应链事件敲醒了装睡的人，供应链安全问题由此备受重视，此后全球又陆续爆发了包括Apache Log4j2 在内的多个供应链事件。
总的来说，供应链安全事件呈现以下特点：
- 影响范围更大，实际危害性更高：每一次供应链安全事件都对全球成千上万家企业造成了极其严重的威胁；
- 威胁持续时间久，修复难度大：某些供应链组件与企业系统架构深度耦合，想要快速修复往往会引发业务连续性风险，修复难度和时间都存在巨大的成本；
- 企业常规防护无法应对供应链风险：在 Solarwinds 事件和 Apache Log4j2 事件中，无论企业的安全防护效果如何，基本都很难避开供应链安全事件，这更像是“凭运气”，而非靠实力。
2022 年，Gartner 就将“软件供应链”列为了 2022 年的第二大威胁，并预测到 2025 年，全球 45% 组织难免会一次甚至多次成为受害者。
细究背后深层次的原因，主要存在两方面：一是企业对外部组件的依赖越来越高，尤其是开源组件。开源软件在应用开发中占据了主导地位，无论是企业采买的第三方商业软件，还是请第三方开发的外包软件，其代码中都大量使用了开源组件，这给企业埋下了极为严重的供应链安全风险。
二是对于攻击者而言，企业的防护越来越坚固，包括很多传统行业都是采用内网，大幅提升了传统攻击的成本。因此，从供应链入手，一方面很多企业对供应链组件的防护尚且不足，另一方面，通过影响供应链可以波及到成百上千的企业，攻击的 ROI 有了显著提升。
软件供应链攻击已成大麻烦
相较于以往相对简单的网络系统环境，目前越来越多的组织依赖于智能化、云化以及开源的技术手段，整个业务运营的过程涉及到众多参与方，大大增加了供应链的复杂性。再加上越来越多第三方外包企业加入到企业供应链链路上，导致整个供应链链路愈发冗长，一旦其中某环节出现数据泄露、恶意代码注入、服务中断的问题，就会对整个供应链链路上的企业造成严重破坏。
想要彻底搞清楚软件供应链攻击的危害程度以及攻击方式，需要从底层逻辑出发。按照以往供应链攻击事件分析结果来看，供应链安全问题之所以难以解决，主要还是攻击技术复杂多变、供应链上下游人员权限管理难等 2 层面。
1.技术层面
技术层面，威胁攻击者主要通过篡改源代码、更新机制劫持、“冒名顶替”、仓储、物流链路劫持等技术手段，达到攻击目的。
(1) 更新机制劫持：供应链攻击中，更新机制劫持是一种极具破坏性的策略，威胁攻击者利用软件更新过程中的漏洞或不安全的通信渠道，将恶意代码注入到软件的更新包中，然后通过合法渠道将这些恶意更新推送给用户。
这种攻击方法的成功在于用户对软件更新的信任，当用户下载和安装被篡改的更新时，他们会在不知不觉中将恶意代码引入到他们的系统中，一旦恶意代码成功激活，攻击者就可以获取系统权限、窃取敏感信息或者对系统进行破坏。从操作系统到应用程序再到安全工具，都有可能受到更新机制劫持的影响。
(2) 开发工具污染：开发工具污染是一种隐蔽而具有破坏力的策略。威胁攻击者会针对广受信任的开发工具或开发环境进行操纵，以在软件开发过程中植入恶意代码或后门，这种攻击方式利用了开发者对其使用的工具和环境的信任，使得恶意代码可以在软件构建的各个阶段中存在，并最终被编译或执行。
开发工具污染可能会通过多种途径实施，包括篡改开发工具的下载源、植入恶意插件或扩展、篡改开发工具的配置文件等。一旦恶意代码成功植入到开发工具中，就会在开发者无意间使用这些工具时被执行，导致软件项目受到感染或者被操纵，从而威胁整个供应链链路。
(3) 向开源仓库投毒：威胁攻击者通过向主流的软件包管理源投放大量相似的软件包或者镜像，仿冒正规项目，以利用软件开发者对其信任的盲点和相似性，一旦被感染的依赖包被引入到软件项目中并被编译或执行，恶意代码就会被激活，从而导致供应链上下游系统都受到损害。
(4) 篡改源代码：篡改源代码是一种常见且危险的供应链攻击方法，通过对软件或系统的源代码进行恶意修改，来实施攻击并植入后门、恶意代码或漏洞，这种攻击方法往往利用供应链中的弱点，例如第三方软件库、开源组件或外包开发团队，通过篡改其源代码来渗透目标系统。
篡改源代码攻击中，攻击者可能通过多种手段进行操作，威胁攻击者可能利用未经授权的访问权限，直接对源代码文件的编辑、新增或删除，以插入恶意代码或修改关键功能，还可以利用软件开发过程中的漏洞或不安全实践，例如弱密码、未加密传输等，来获取对源代码的非法访问权限。（大部分威胁攻击者都会预留后门，以便长期获取访问权限，自由地修改源代码）
2.权限管理层面
超级账号权限：供应链攻击中，威胁攻击者利用供应商预留的超级权限账号，发起网络攻击的例子屡见不鲜。这些超级账号权限成为了威胁攻击者获取系统控制的理想入口，利用了供应商在开发软件或提供服务时通常会预留的后门或特权账号。
威胁攻击者可能会利用这些预留的远程管控能力，通过网络渠道远程操控受影响的系统，从而执行包括修改系统配置、安装恶意软件、窃取敏感数据等在内的任意恶意操作，超级权限账号则赋予了威胁攻击者对系统的完全控制，使其能够绕过所有安全措施和权限限制，实施更为深度和广泛的攻击。
一旦威胁攻击者成功获取了这些权限，就可以在不被察觉的情况下对下游系统进行长期监控和操控，造成严重的安全风险和数据泄露。因此，如何管理供应链上有组织的权限问题是解决供应链安全问题不可忽视的环节。
如何缓解供应链攻击？
(1) 供应商审查和管理：缓解供应链攻击的关键之一是进行有效的供应商审查和管理，供应商审查和管理是组织保护自身免受供应链攻击影响的重要步骤之一，对于任何组织来说，这是最重要且经常被忽视的一步。
组织应该将供应商的数字资产纳入全面的、基于真实风险的安全评估体系中，通过要求供应商提供安全合规性文件、安全认证和独立审计报告，建立一个包括评估潜在供应商的安全实践、安全标准和数据保护措施的全面供应商审查程序。
对供应商的审查应该是一个持续的过程，而不仅仅是在合作开始时进行一次性的审查。
另外，组织应该加强对供应链的监控和审计，包括监控供应商的网络活动、数据访问和系统行为，以及定期对供应链进行安全审计和检查，应该对供应商的网络安全证书、风险管理计划、以及是否以同样的方式审查供应商进行全面审核，通过实时监控和审计，可以及时发现和应对供应链中的安全风险和漏洞。
(2) 减少第三方和开源组件依赖：组织应该审查和评估其对第三方和开源组件的依赖情况，识别和分析所有使用的第三方库、框架和工具，了解其安全性和稳定性，通过对第三方和开源组件的全面审查，可以识别潜在的安全风险和漏洞，及时采取措施进行修复或替换。
此外，组织还需要建立有效的第三方和开源组件管理机制，建立清晰的政策和流程，规范组织内部对第三方和开源组件的选择、审查和使用。同时，建立一个集中化的组件库和更新机制，确保所有使用的组件都经过审查和更新，以修复已知的安全漏洞。
(3) 数据交换与可见性权限控制：为了最大程度上缓解供应链攻击，组织需要采取有效的措施来管理数据交换和可见性权限，以确保只有合适的人员能够访问和处理敏感信息，采用加密技术保护数据在传输过程中的安全，确保数据在传输过程中不被窃取或篡改。
同时，建立数据交换协议和标准，明确数据交换的方式、流程和安全要求，确保数据交换的合法性和安全性。其次，实施严格的可见性权限控制是必不可少的，包括对系统和数据访问权限进行精确的控制和管理，只授权给合适的人员访问特定的数据和系统功能。通过实施基于角色的访问控制和细粒度的权限管理，可以最大程度上减少未经授权的访问和数据泄露的风险。
(4) 可信、透明与溯源：组织应当建立可信、透明的供应链生态系统，与供应商建立长期合作关系，并确保他们符合一定的安全标准和规范，通过建立信任和透明度，可以降低供应链攻击的风险，因为供应商将更加积极地配合安全措施和审查。
另外，建立有效的溯源机制也是非常重要的，此举能够确保所有产品和组件都能够被准确地追溯到其来源，以便在发生安全事件时迅速确定受影响的范围和采取相应的措施，通过建立溯源机制，可以更加有效地应对供应链攻击，并降低其对组织的损害程度。
(5) 第三方风险管理：公司与第三方之间的联系和相互依赖在供应链生态中不断增长，组织需要扩展供应商风险管理的定义，以涵盖端到端安全。允许公司评估、改善、监控和管理整个关系生命周期的风险，将自己的业务和技术团队与合作伙伴和供应商聚集在一起，在违反法规、系统关闭或数据泄露等方面识别关键资产并对业务运营的潜在损害进行讨论和定义。
除上述供应链上下游企业能够实施的安全措施以外，有效保证供应链安全的策略就是政策层面加大监管，指导各个组织、企业树立起安全供应链风险意识。
开源组件或开源软件的应用已成为互联网行业普遍共识，在企业降本增效、产业创新中起着主导作用，这种情况看似能够大幅提升效率，节约成本，但不可避免的会带来很多不可控的安全风险，倒逼企业必须“面对”供应链安全合规问题。
不仅如此，目前产业链大都是全球性质的，供应链就不再局限于国内，而是跨越国界，涵盖全球范围内的供应商和合作伙伴，意味着安全风险也在不断扩大，不仅受到本地法规的约束，还面临着国际标准和跨境合规的挑战。
因此，为有效应对不同国家和地区的法律法规要求，并确保信息安全标准的一致性和合规性，建立一个覆盖面广、灵活性高的供应链安全政策框架至关重要。
国内目前针对供应链安全问题更多的是在关键行业的部门规章和标准中体现。其中以《网络安全法》、《数据安全法》、《个人信息保护法》和《关键信息基础设施安全保护条例》等为代表的法律法规密集发布和实施，已基本形成了网络与数据安全管理的框架，覆盖了管理制度、产品与服务安全、人员安全、供应链管理活动等方面，对供应链安全提出了明确要求并设置了相应的法律责任。
国外其他国家同样逐渐意识到了开源软件供应链安全的重要性，并采取了相应的措施，一些国家制定了针对软件供应链安全的法律和政策，要求企业采取必要的措施确保软件供应链的安全性。例如，美国“网络安全总统行政 14028 号命令”第四节中，特别关注“增强软件供应链安全”，并对美国国家标准与技术研究所(NIST)、管理和预算办公室(OMB)、网络安全和基础设施安全局(CISA)等提出了要求。
同时，欧盟、北约等国际团体、以及标准制定机构也发布了相关的指南和标准，以引导开发者和企业提升开源软件供应链的安全水平。
结语
距离 SolarWinds 供应链安全事件发生了四年，供应链安全问题能否有效解决？总的来说局势并不是很乐观，供应链安全问题涉及到层面太过复杂，无论是开源组件使用问题，还是上游的管理权限，亦或是自身代码问题，无论其中哪一个环节出现问题，都会给威胁攻击者留下可乘之机，危害整个链路的安全。
