Title 标签： 供应链攻击案例：完整指南 (2013–2024) 元描述： 了解什么是供应链攻击，并探索从 SolarWinds 到 XZ Utils 的 9 个主要案例，涵盖攻击机制、财务影响数据及防御策略。

什么是供应冲击，以及它对网络安全意味着什么

创纪录中最昂贵的网络攻击并非始于黑客入侵政府网络。它始于一次软件更新。一款被乌克兰数千家企业使用的会计软件悄悄地植入了恶意代码，在数小时内传播到全球企业网络，最终造成估计100亿美元的损失。那次攻击，NotPetya，是本指南将全面介绍的九大主要供应链攻击示例之一，其中涵盖了每一次攻击的攻击者、机制和已记录的财务影响。

理解这些事件需要从一个经济学概念开始：供应冲击（Supply Shock）。供应冲击是指对某种产品或服务的供应突然发生意想不到的中断，其影响会波及到所有依赖该产品或服务的人。最典型的例子是石油禁运和自然灾害。这些事件虽然源于供应网络中的某个单点，但其造成的损害会级联式地传导给成千上万在初始中断中不承担任何责任的下游消费者。

网络安全供应链攻击的运作方式类似于一种数字供应冲击。攻击者攻破上游的一个受信任软件供应商或硬件组件，所造成的损害会自动蔓延到每个安装该软件、信任该供应商或依赖该组件的组织。受害者并没有做错任何事。他们自身的防御被完全绕过。这种攻击利用的是供应链，而非攻击目标。正如石油禁运可以使从未接触过炼油厂的行业陷入瘫痪，一个被入侵的软件更新也能摧毁那些从未与攻击者有过互动的组织。

本指南全面概述了：什么是供应链攻击、它们的运行机制、2013年至2024年间的每一项重大命名事件及其量化影响数据、谁在进行这些攻击以及其原因，以及组织和开发者可以采取哪些措施来降低风险。

--- ## 什么是供应链攻击？

供应链攻击是一种网络攻击，通过针对组织供应链中受信任的第三方供应商、软件组件或硬件元件，间接地危害该组织。攻击者在链路上游的合法软件或硬件中植入恶意代码或后门，使受害者在通过常规更新或采购流程时，在不知不觉中亲自引入了威胁。由于攻击来自受信任的来源，受害者自身的安全控制措施会被绕过。

软件供应链涵盖了构建和交付软件产品所涉及的每一个组件、库和流程。这包括第三方代码依赖、开源库、构建基础设施、更新服务器以及硬件固件。其中任何一个元素都可能成为一个入口点。

供应链攻击与直接网络攻击的关键区别在于攻击者攻击的切入点。在直接攻击中，攻击者会针对受害者自身的系统、应用程序或用户下手，并且必须克服该组织的各项安全控制措施。而在供应链攻击中，攻击者会攻击受害者已信任的供应商，从而完全绕过这些控制。一旦一个供应商被攻陷，可能会同时暴露数千个下游组织。

数据泄露是一种结果，而不是攻击方式。供应链攻击可能导致数据泄露，但并非所有数据泄露都涉及供应链被攻破。并非所有供应链攻击都会导致数据窃取：NotPetya 造成的是破坏，而非数据外泄。

供应链攻击如何运作

供应链攻击遵循一种固定模式：攻击者会入侵受信任的供应商，而不是直接以受害组织为目标。攻击会通过正常的软件分发渠道、更新机制或硬件采购流程进行投递。

攻击生命周期：分步解析

1. 攻击者识别出目标所使用的受信任供应商或软件组件
2. 攻击者获得对供应商的构建系统、代码库或更新服务器的访问权限
3. 在分发前，将恶意代码插入合法软件或硬件
4. 供应商通过其正常、受信任的渠道分发受损产品
5. 目标组织安装更新或部署组件，从而引入威胁
6. 攻击者利用已建立的立足点进行横向移动、间谍活动或部署破坏性载荷

攻击向量分类

被木马化的软件更新

伪装成更新的木马程序之所以格外危险，是因为它几乎能规避所有标准的安保控制。该更新来自组织已信任的供应商，携带合法的数字代码签名证书，通过了杀毒软件和终端安全扫描，并且用户还乐意将其作为日常维护的一部分进行安装。目标组织中的任何人都未做错任何事。

构建系统入侵针对的是将源代码转换为可执行软件的自动编译过程。攻击者获取供应商构建环境的访问权限，并在编译过程中植入恶意代码。由此生成的软件包与合法版本看起来完全相同。在此阶段遭到入侵的 CI/CD（持续集成/持续部署）流水线会将恶意代码传播至后续的每一个软件发布版本中，即使原始源代码保持洁净。这就是为什么即使对源代码仓库进行彻底的代码审计，也无法发现此类攻击的原因。

这样想吧：想象一家药品供应商在发货前，悄悄地将合法药物换成受污染的版本。接收并使用这些药物的医院本身并没有做错任何事。攻击利用的是供应链，而不是医院。

SolarWinds、CCleaner 和 ASUS ShadowHammer 都遵循了这种模式。在此类事件中，攻击者攻破了供应商的构建基础设施，而不是直接针对目标组织。

开源软件包注册表攻击

公共软件包注册表是软件供应链中最活跃的攻击面之一。这包括 JavaScript 的 npm、Python 的 PyPI、Ruby 的 RubyGems、.NET 的 NuGet 以及 Java 的 Maven。仅 npm 注册表就托管了超过两百万个软件包。一个被攻破的流行软件包就可能将恶意代码传播到数百万个应用程序中。

三种不同的攻击模式针对此生态系统。在**错别字劫持（typosquatting）中，攻击者注册一个名称与流行合法软件包几乎相同的软件包（例如，将 lodash 注册为 lodahs），希望能够欺骗粗心的开发者。在依赖项混淆（dependency confusion）中，攻击者在公共注册表中使用的名称与目标组织的私有内部软件包完全相同。构建系统若先检查公共注册表再检查私有注册表，将会自动下载恶意版本。在恶意包注入（malicious package injection）**中，一个合法的软件包在发布后被入侵，这可能是通过窃取维护者凭证，或通过对项目的社会工程学攻击来实现的。

依赖混淆（Dependency confusion）最初由安全研究员 Alex Birsan 在 2021 年公开进行大规模演示，他利用此技术成功在苹果（Apple）、微软（Microsoft）、PayPal 以及其他 35 家大型公司的构建流水线中执行了代码。该攻击之所以成功，并非因为存在漏洞，而是源于包管理器在处理公共与私有仓库之间的命名冲突时的解析机制。

关于 Log4Shell： Log4Shell (CVE-2021-44228) 是 2021 年 12 月在 Apache Log4j Java 日志库中发现的严重漏洞，经常被描述为供应链攻击。但事实并非如此。Log4Shell 是一个无意的软件漏洞，并非由攻击者植入 Log4j 代码库。之所以产生这种混淆，是因为 Log4j 作为成千上万种软件产品的依赖项，导致识别所有受影响系统的过程类似于供应链审计问题。其威胁模型有所不同：供应链攻击涉及攻击者蓄意植入恶意代码，而 Log4Shell 则是一个在后来被攻击者利用的意外缺陷。

MSP 攻陷与横向移动

托管服务提供商 (MSP) 是一间远程管理客户组织 IT 基础设施、安全和系统的公司。缺乏内部 IT 团队的中小型企业通常会使用 MSP。攻陷一个 MSP 可让攻击者同时获得该 MSP 所有客户的管理访问权限，这使 MSP 成为具有不成比例下游影响力的力量倍增攻击向量。CISA 公告 AA22-131A 特别警告 MSP，他们是高优先级目标。

一旦通过木马化更新或受损的依赖项进入任何网络，攻击者通常会使用横向移动技术。这些技术利用合法的凭证和网络访问路径，从最初被攻陷的系统转移到更敏感的目标。在SolarWinds攻击事件中，APT29使用了SUNBURST后门作为初始立足点，然后横向移动到政府机构的电子邮件系统和敏感数据存储库。

主要供应链攻击案例

以下表格总结了 2013 年至 2024 年间最显著的供应链攻击案例，按攻击者、攻击向量和已记录的影响进行组织。

Target 数据泄露事件 (2013)

Target（2013年） — 一个犯罪团伙通过首先攻破 Fazio Mechanical Services 获得了 Target 销售点网络的访问权限，该公司是一家拥有 Target 系统远程访问网络凭据的第三方暖通空调（HVAC）和制冷承包商。

塔吉特（Target）泄露事件是供应链攻击模式中最早被广泛研究的案例。攻击者并非直接突破塔吉特的边界防御。他们从一家小型暖通空调（HVAC）供应商处获取了凭据，利用这些凭据通过合法访问路径进入塔吉特网络，随后在网络内进行横向移动，最终渗透到处理支付卡数据的销售点（POS）系统。

结果导致大约4000万名客户的支付卡数据和大约1.1亿名客户的个人数据被盗。Target此次泄露事件的总成本，包括和解金、法律费用和补救措施，估计超过2亿美元。此次攻击确立了后来攻击所改进的模板：侵入一个能够访问真正目标的受信任供应商，然后利用该访问权限作为切入点。美国特勤局和司法部的调查证实，第三方供应商途径是此次攻击的入口向量。

SolarWinds供应链攻击 (2020)

SolarWinds (2020) — APT29 (Cozy Bear)，据信与俄罗斯对外情报局 (SVR) 有关。该组织入侵了 Orion IT 监控平台的构建过程，并在大约 18,000 名 SolarWinds 客户下载的常规软件更新中植入了 SUNBURST 后门。

SolarWinds 被广泛认为是史上有记载以来最重大的供应链网络攻击。Orion 是一款广泛部署的 IT 监控平台，被美国政府机构和各大企业所使用。攻击者将名为 SUNBURST 的后门植入软件构建流水线中，这意味着恶意代码被直接编译进合法的 Orion 更新包中，并使用有效的 SolarWinds 证书进行签名，最后通过官方更新渠道进行分发。

在下载了被植入木马的更新的约18,000个组织中，攻击者挑选了高价值目标进行后续的二次攻击。这些目标包括美国财政部、商务部、国土安全部和国务院，以及微软、FireEye等主要科技公司。此次入侵行为在FireEye调查自家系统中的异常情况时被发现，此前已潜伏了约九个月。

APT29 使用 SUNBURST 作为初始访问点，随后通过受损网络横向移动，接触到电子邮件系统和敏感通信。此次行动被评定为一次间谍活动，而非破坏性攻击。美国政府通过 CISA Advisory AA20-352A,) 协调应对，发布了影响所有联邦文职机构的紧急指令。

NotPetya (2017)

NotPetya (2017) — Sandworm，被归因于俄罗斯格鲁乌 (GRU) 军事总局（74455 部队），在乌克兰会计应用程序 M.E.Doc 的软件更新中植入了恶意代码。该程序被大量在乌克兰运营的企业使用。

NotPetya 并非勒索软件。它显示了勒索信息，但这只是一个诱饵。该代码覆盖了受感染系统的（主）主引导记录 (MBR)，使其永久无法恢复。它是一个为造成最大破坏而设计的破坏性擦除器 (wiper)，没有实际的支付机制。类似勒索的外观是为了在初步响应期间混淆溯源。

最初的感染途径是 M.E.Doc 更新，但 NotPetya 通过 EternalBlue 漏洞和网络传播迅速蔓延至乌克兰以外地区，并在数小时内演变成一场全球性灾难。全球总损失估计约为 100 亿美元，使其成为史上财务影响最严重的网络攻击。已知的受害者包括航运巨头马士基（约 3 亿美元损失；该公司不得不从头开始重装 45,000 台个人电脑和 4,000 台服务器）、制药商默克（Merck）、FedEx/TNT Express 以及亿滋国际（Mondelez International）。这些组织中的许多都与乌克兰没有直接联系，而是通过全球网络连接而被波及的附带受害者。

此次攻击的详细记录可在 Wired 的回顾性调查 中找到，并被美国、英国及澳大利亚归咎于 Sandworm。Sandworm 与 APT29/Cozy Bear 不同：它们隶属于不同的俄罗斯情报机构（GRU 对比 SVR），且拥有不同的作战任务。

Kaseya VSA 攻击 (2021)

Kaseya VSA (2021) — REvil，一个与国家政府无关的勒索软件即服务（RaaS）网络犯罪集团，利用了 Kaseya VSA 的零日漏洞，同时向其托管服务供应商（MSP）客户推送了恶意更新。

Kaseya VSA 是一款被托管服务提供商（MSP）广泛使用的远程监控和管理平台。REvil 是一个受经济利益驱动的犯罪集团，他们识别出了 MSP 的攻击面并对其进行了大规模利用。通过入侵 VSA 平台，REvil 能够向所有下游客户机构同时推送恶意更新，且这些更新看起来像是源自受信任的 MSP。

结果：约有 60 家管理服务提供商（MSP）遭到入侵，并导致约 1,500 家下游企业受到勒索软件（一种加密受害者数据并索要解密密钥赎金的恶意软件）的影响。REvil 索要了价值 7,000 万美元的比特币以提供通用解密器。这次攻击清晰地展示了针对 MSP 进行攻击的效能乘数逻辑：只需入侵一个平台，即可在一次行动中影响数百个组织。CISA 咨询公告 AA21-200B) 提供了完整的技术分析。

Codecov 供应链攻击 (2021)

Codecov (2021) — 一名身份不明的攻击者篡改了 Codecov Bash Uploader 脚本，这是一个嵌入到数千家组织 CI/CD 流水线中的代码覆盖率报告工具，并利用该脚本窃取了包括凭据和 API 令牌在内的环境变量。

Codecov 是一款代码覆盖率分析服务，供软件开发团队追踪测试覆盖率。攻击者修改了组织在自动化构建流程中下载和运行的 Bash Uploader 脚本。由于该脚本在 CI/CD 环境中运行，因此可以直接访问包含凭证、令牌和存储库访问密钥的环境变量。

此次入侵行为在 2021 年 4 月 Codecov 发现之前，已持续约两个月未被察觉。受影响的机构包括 Twilio、HashiCorp 和 Confluent，这些公司披露了其凭证已被泄露。这次攻击展示了一个针对 CI/CD 的供应链向量：攻击者并非破坏最终的软件产品，而是针对机构用于构建和测试软件的工具。这次攻击处于构建流水线破坏与凭证窃取的交汇点，代表了与 SolarWinds 和 CCleaner 中所使用的更新分发向量截然不同的模式。

CCleaner 供应链攻击 (2017)

CCleaner (2017) — AXIOM 组织，被指与中国国家支持的黑客攻击有关，入侵了 Piriform（CCleaner 的开发者）的构建环境，并将 Floxif 恶意软件植入到通过官方渠道分发的合法 CCleaner 安装程序中。

CCleaner 是一款备受欢迎的电脑优化工具，拥有数百万消费者和企业用户。此次攻击表明，供应链安全事件并非仅限于企业级软件。在漏洞被发现前，大约有 227 万用户下载了被植入木马的版本。

此次攻击还有第二个阶段：预配置的定向负载仅在属于约 40 家高科技公司的系统上激活，其中包括思科 (Cisco)、英特尔 (Intel)、三星 (Samsung) 和索尼 (Sony)。对于绝大多数受影响的用户，该恶意软件只是被动地收集数据。而对于被针对的技术公司，这代表了对敏感网络的严重入侵。Cisco Talos 的分析) 对 CCleaner 指令与控制基础设施进行了首次完整的攻击技术分析。

华硕 (ASUS) ShadowHammer (2019)

ASUS ShadowHammer (2019) — BARIUM 组织，被指称是中国国家支持的黑客活动，侵入了华硕的 Live Update 工具，并通过华硕官方更新服务器分发了一个带有后门、并使用合法华硕数字证书签名的版本。

这次攻击展示了对数字信任的重大影响：如果签名基础设施本身已遭到破坏，合法的代码签名证书就不能再被视为软件完整性的可靠证明。被植入木马的华硕（ASUS）更新带有有效的华硕证书，并通过官方华硕更新机制分发，通过了每一项标准身份认证检查。大约有 500,000 名华硕用户接收到了包含后门的更新。

攻击者并非对所有 500,000 名用户都感兴趣。恶意载荷被预先配置为仅在具有大约 600 个特定 MAC 地址的系统上激活，这表明攻击者事先已掌握目标情报。该活动于 2019 年被 卡巴斯基研究团队 (Securelist)) 发现并记录。

硬件和固件供应链攻击带来的一个特别担忧是：在固件层面进行的修改，即使重装操作系统后依然会保留，并且无法被基于软件的安全工具发现。

3CX 供应链攻击 (2023)

3CX (2023) — 被归因于朝鲜侦察总局 (RGB) 的 Lazarus Group 执行了首个经公开确认的“供应链针对供应链”攻击，通过此前对 Trading Technologies 软件的供应链渗透，成功进入了 3CX 的构建环境。

一名3CX员工的个人电脑通过一个被植入木马的Trading Technologies X_TRADER安装程序遭到入侵，该程序是一个金融交易平台。该Trading Technologies安装程序本身已在早先的一次行动中遭到Lazarus Group的供应链攻击。被入侵的员工机器使攻击者获得了3CX构建环境的访问权限，他们利用该环境将恶意软件植入到3CX 桌面应用中，这是一个VoIP通信平台，全球有超过60万家公司和1200万日常用户使用。

该攻击不成比例地针对了金融行业的公司。由于 3CX 泄露事件本身是先前供应链攻击的下游后果，这是首次确认发生供应链攻击触发二次供应链攻击的案例。实际影响：组织现在不仅需要考虑其直接供应商是否安全，还需要考虑其供应商的供应商是否已被泄露。Mandiant 的事件分析.) 中记录了完整的技术细分。

XZ Utils 后门 (2024)

XZ Utils (2024) — 在安全研究人员评估认为这是一场基于行为指标的国家级行动（但尚未有公开的明确归因）的情况下，一个未知行为者以虚构身份“贾谈”运作，花费了大约两年时间渗透了XZ Utils开源项目，随后插入了一个针对Linux系统SSH身份验证的后门。

XZ Utils 是一套在数以百万计的 Linux 服务器上运行的隐形基础设施数据压缩库。它并非面向用户的应用程序，而是其他软件在背后默默依赖的基础性软件。一名化名为“Jia Tan”的攻击者于 2022 年开始向 XZ Utils 项目贡献高质量的正规代码，以此建立信誉，并最终通过与项目维护者的持续沟通，获得了提交权限。

2024 年初，“Jia Tan” 在 XZ Utils 5.6.0 和 5.6.1 版本中植入了一个后门。该后门旨在破坏受影响 Linux 发行版上的 SSH 身份验证，从而可能使攻击者能够远程访问任何运行受影响库版本的服务器。SSH 是全球 Linux 服务器主要的远程管理协议，这使得其潜在影响范围非常广泛。

这个后门在广泛部署之前被微软工程师 Andres Freund 拦截。他在日常工作中注意到异常的 CPU 占用和 SSH 性能下降，并追溯到了源头。他在 2024 年 3 月公布的发现，防止了一场可能影响数百万台服务器的供应链攻击。OpenSSF 公告 (CVE-2024-3094) 提供了完整的技术报告。

为什么供应链攻击如此危险

供应链攻击之所以难以检测和阻止，是因为它们利用了机构对软件供应商的信任，而不是机构自身系统中的漏洞。有四个因素加剧了检测方面的挑战。

恶意软件来自一个受信任的来源：一个目标组织已授权其证书、域名和更新基础设施的供应商。被木马化的更新通常携带以合法供应商名义签发的有效数字代码签名证书，因此证书验证会顺利通过。防病毒和端点检测工具可能不会标记由受信任供应商签名并通过官方渠道交付的软件。攻击者还故意延迟活跃操作的启动，以避免触发异常检测。在成功入侵 SolarWinds 网络约九个月后，APT29 才被发现，这段潜伏时间恰恰说明了从入侵到被发现可能存在的漫长间隔。

在过去十年中，供应链攻击的频率和复杂性都有所增加。ENISA 的威胁形势报告记录了持续的上升趋势，供应链攻击已被列为关键基础设施领域的一线威胁类别。这种升级在历史记录中清晰可见：2017 年 CCleaner 被攻破事件影响了 227 万消费者用户；2020 年 SolarWinds 事件导致美国 100 多个政府机构被入侵；2024 年 XZ Utils 险些得逞的攻击目标是全球数百万台服务器使用的核心 Linux 基础设施。每一次攻击的野心都在显著增长。

财务后果与此规模相当。NotPetya 估计造成了 100 亿美元的全球损失，其中马士基 (Maersk) 一家就报告了约 3 亿美元。Kaseya 攻击事件产生了 7000 万美元的勒索要求，涉及 1,500 家受影响的企业。美国政府对 SolarWinds 事件的应对在修复和加强安全投资方面花费了数亿美元。政府和公共部门组织 (SolarWinds)、金融服务公司 (3CX)、科技公司 (CCleaner 的二级目标) 以及 CISA 指定的优先行业中的关键基础设施运营商都成为了攻击目标。任何依赖第三方软件或托管服务的行业都未能幸免。

谁在进行供应链攻击

供应链攻击由两大类威胁行为者实施：国家级高级持续性威胁（APT）组织和以牟利为目的的犯罪组织。

高级持续性威胁 (APT) 是指由资金充足且技术精湛的威胁行为者发起的攻击，通常是国家情报机构或军事网络单位。这些行为者会针对特定战略目标开展长期且有针对性的入侵活动。APT 更倾向于采取供应链攻击，因为单一的上游渗透可以让他们同时接触到成百上千个高价值目标，从而在降低被发现风险的同时，最大化单次行动的情报收益。APT 活动的归因通常是概率性的，主要基于取证指标，包括代码重合、基础设施模式和行动时间，而非直接证据。

涉及已记录供应链攻击的国家级组织包括：APT29（Cozy Bear），被归因于俄罗斯对外情报局（SVR），该组织执行了 SolarWinds 操作；Sandworm，被归因于俄罗斯军事情报总局（GRU），该组织通过 M.E.Doc 发动了 NotPetya 攻击；Lazarus Group，被归因于朝鲜侦察总局，该组织发动了 3CX 攻击；BARIUM 组织，被归因于中国国家支持的行动，该组织执行了 ASUS ShadowHammer；以及 AXIOM 组织，同样被归因于中国国家支持的行动，该组织执行了 CCleaner 攻击。尽管 BARIUM 和 AXIOM 都被归因于中国，但它们是不同的组织。

并非所有供应链攻击都是国家级行动。Kaseya VSA 攻击是由 REvil 发起的，这是一个讲俄语的勒索软件即服务（RaaS）网络犯罪组织，并无国家背景。受利益驱动的犯罪团伙已开始采用供应链攻击技术，因为攻破单个管理服务提供商（MSP）即可在一次行动中向数百家客户组织投放勒索软件，与针对单个受害者相比，极大地提高了投资回报率。

如何防范供应链攻击

防御供应链攻击需要将您的安全计划扩展到您自己的系统之外，以涵盖您组织所依赖的供应商、软件组件和基础设施。目标不是建立一个完美的边界，而是要缩小当受信任的供应商受到威胁时的影响范围。

企业和组织防御清单

• 为您的组织采购或构建的所有软件实施软件物料清单 (SBOM) 政策，以便在披露供应链安全事件时能够识别受影响的组件。
• 在采购前以及每年对第三方供应商的安全实践进行审计，使用符合 NIST SP 800-161r1 的标准化问卷。
• 作为您采购和合同流程的一部分，要求供应商提供最新的 SBOM，适用于所有进入您环境的软件产品。
• 应用零信任架构原则：对所有软件和服务强制执行最低权限访问，实施网络微细分以遏制横向移动，并持续进行验证而非依赖网络位置信任。
• 监控来自可信供应商的软件中的异常行为，因为行为偏离已知基线可能表明更新已被泄露，即使签名有效。
• 审查供应商的安全认证（SOC 2 Type II、ISO 27001），并在供应商合同中包含明确的安全要求和泄露通知义务。
• 遵循 CISA 的供应链安全指南)** 并实施 NIST SP 800-161r1 (C-SCRM) 框架，将您的风险管理扩展到第三方供应商。
• 维护一份事件响应计划，其中明确涵盖第三方软件安全事件，包括在您的环境中紧急隔离受影响软件的程序。

什么是软件物料清单 (SBOM)？

软件物料清单 (SBOM) 是一份机器可读的清单，包含软件产品中涉及的所有组件、库和依赖项。在功能上的类比，它就像是软件的营养标签：正如营养标签会列出成分和含量，SBOM 会列出构建应用程序时所使用的每一个开源库、第三方组件和直接依赖项，以及版本号和许可信息。

SBOM 对于供应链安全至关重要，因为它回答了组织在处理安全事件时难以回答的问题：“我们是否受到了影响？”当 SolarWinds 事件被披露时，没有软件资产清单的组织不得不手动审计每个系统，以确定它们是否运行了 Orion。拥有最新 SBOM 的组织则可以直接查询其清单。同样的逻辑也适用于 XZ Utils 这一险情：掌握哪些服务器运行了哪个版本的库，决定了响应时间是短短几小时，还是长达数周的不确定性。

《关于改进国家网络安全的行政命令 14028》 （于 2021 年 5 月签署，直接回应 SolarWinds 攻击）规定向美国联邦政府销售软件的供应商必须提供 SBOM。 CISA 已发布 SBOM 实施指南 供生产者和消费者参考。SPDX、CycloneDX 和 Syft 等工具可以从大多数代码库和容器镜像中自动生成 SBOM。

零信任架构和供应链防御

零信任架构通过对每个访问请求（包括来自看似来自受信任供应商的软件的请求）应用“永不信任，始终验证”的原则，来减少供应链攻击可能造成的损害。供应链攻击成功的关键在于利用隐含的信任。零信任则从等式中消除了这种隐含的信任。

与供应链防御最直接相关的三项控制措施是：最小权限访问（限制受损软件在网络内可触及的范围，使带有后门的更新无法访问其合法范围之外的系统）；网络微隔离（遏制横向移动，使获得初始立足点的攻击者无法自由扩散）；以及持续行为监测（即使初始入侵绕过了基于特征码的检测，也能检测到来自受信任软件的异常活动）。

零信任是一种安全理念和架构模型，而非可购买的软件产品。主要的权威参考资料是 CISA 零信任成熟度模型) 和 NIST SP 800-207.)

开发者与 DevOps 防护核查清单

开发者和 DevOps 工程师可以直接控制开源供应链攻击中最常被针对的攻击面。以下行动可以降低您的流水线暴露风险：

• 锁定所有包清单中的依赖版本 (package-lock.json, requirements.txt, Gemfile.lock)，以防止新发布的恶意版本在下次构建时被自动拉取
• 配置您的构建系统优先使用私有注册表而非公共注册表，并在公共注册表中保留所有内部包命名空间，以防止依赖项混淆攻击
• 对每次构建运行自动化依赖扫描，使用 Dependabot、OWASP Dependency-Check 或 Snyk 等工具，以在已知存在漏洞或可疑的软件包进入生产环境前将其标记出来
• 为每次发布生成 SBOM（软件物料清单），使用 CycloneDX 或 Syft，并将其与构建工件一起存储，以便为每个已部署的版本提供可审计的组件清单
• 要求签名提交，并对主构建管道强制执行分支保护规则，以防止未经授权的代码进入构建过程
• 在添加第三方包之前进行审计：检查维护者的发布历史、下载量、存储库活动以及该包最近是否已转移给新所有者

供应链安全：监管与合规要求

目前，多个主要监管框架已明确要求组织在其网络安全义务中解决供应链安全风险。这些要求很大程度上是由于 SolarWinds 攻击事件，从指导性转变为强制性规定。

美国监管框架

在美国，主要的监管触发点是拜登总统于 2021 年 5 月 12 日签署的《关于改善国家网络安全的第 14028 号行政命令》(EO 14028)，该命令是直接针对 SolarWinds 攻击和 Kaseya VSA 事件而颁布的。EO 14028 规定，向美国联邦政府销售软件的供应商必须为其产品提供软件物料清单 (SBOM)。它指示美国国家标准与技术研究院 (NIST) 制定供应链安全指南，并指示美国网络安全和基础设施安全局 (CISA) 实施 SBOM 标准。该指令适用于向联邦政府供货的供应商。它并未直接要求所有私营部门组织提供 SBOM，但其产生的标准已在企业环境中被广泛采纳为采购要求。

主要的技​​术标准参考是 NIST SP 800-161r1（“系统和组织的网络安全供应链风险管理实践”），该标准将标准的网络安全风险管理框架扩展至明确涵盖第三方供应商、服务商和软件组件。NIST SP 800-161r1 下的网络供应链风险管理（C-SCRM）要求组织进行供应商风险评估、验证软件来源、在采购中强制要求 SBOMs，并维护能够应对第三方泄露事件的应急响应计划。CISA 的出版物“防御软件供应链攻击”提供了与 EO 14028 要求相符的切实可行的实施指南。

欧盟监管框架

欧洲组织在两个框架下面临着平行的要求。NIS2 指令（网络和信息安全指令 2）要求能源、交通、医疗和数字基础设施等关键部门的组织，必须将供应链安全风险作为其强制性网络安全风险管理义务的一部分。DORA（数字运营韧性法案）适用于欧盟的金融部门实体，其中包含了管理 ICT 第三方服务提供商风险的详细要求，直接针对供应链攻击向量。ENISA（欧盟网络安全局）是欧盟组织的主要权威机构，其角色相当于美国的 CISA。

监管参考摘要

有关供应链攻击的常见问题

什么是供应链攻击？

供应链攻击通过损害受信任的第三方供应商、软件组件或硬件元素来间接攻击一个组织。攻击者在上游植入恶意代码，以便受害者在不知情的情况下通过例行的软件更新或硬件采购引入威胁。受害者自身的系统无需存在漏洞。该攻击之所以能够成功，是因为它通过受害者已经授权的渠道进入。

供应链攻击的例子有哪些？

2013年至2024年最显著的供应链攻击示例：

• SolarWinds (2020): SUNBURST 后门被植入 Orion 平台更新中；波及约 18,000 名客户，包括 100 多个美国政府机构
• NotPetya (2017): 通过 M.E.Doc 会计软件更新分发的破坏性雨刷攻击 (wiper)；估计造成全球 100 亿美元的损失
• Kaseya VSA (2021): REvil 利用 VSA 零日漏洞，通过受损的托管服务提供商 (MSP) 向 1,500 多家企业分发勒索软件
• XZ Utils (2024): 为期两年的社会工程攻击活动，险些在全球 Linux 基础设施中植入 SSH 后门
• CCleaner (2017): Floxif 恶意软件波及 227 万用户；第二阶段针对 40 家大型科技公司
• ASUS ShadowHammer (2019): 带有华硕 (ASUS) 有效证书签名的后门固件更新波及 50 万用户
• 3CX (2023): 首个经确认的“供应链针对供应链”攻击；通过 Lazarus Group 波及 60 多万家公司

供应链攻击是如何运作的？

供应链攻击遵循一套可重复的模式：

1. 攻击者选择目标所依赖的可信供应商或软件依赖项
2. 攻击者获取该供应商构建环境、代码库或更新基础设施的访问权限
3. 在合法软件分发之前，将恶意代码植入其中
4. 供应商通过其正常的、可信的渠道发布被篡改的产品
5. 目标安装更新，从而将威胁带入其自身边界内
6. 攻击者激活立足点，进行间谍活动、数据窃取或破坏性载荷攻击

最著名的供应链攻击是什么？

SolarWinds 攻击（2020 年）被广泛认为是历史上最重大的供应链网络攻击。据信源自俄罗斯对外情报局 (SVR) 的 APT29 将 SUNBURST 后门植入 SolarWinds Orion 更新中，波及约 18,000 名客户，其中包括 100 多个美国政府机构。此次入侵在长达约九个月的时间内未被察觉，并直接促成了关于“改善国家网络安全”的第 14028 号行政命令。

为什么供应链攻击如此危险？

供应链攻击具有复合风险，原因有四。恶意软件来自组织已经信任的供应商，绕过边界防御，而无需利用目标自身系统的任何缺陷。被木马化的更新带有有效的数字签名，能够通过证书检查。防病毒工具可能不会标记经过签名的、供应商交付的软件。复杂的攻击者在获得初始访问权限后保持休眠状态，以避免触发行为异常检测。SolarWinds 行动持续了九个月未被发现。一个受损害的供应商可以波及数千家下游组织，使单次入侵的影响规模远超直接攻击通常所能达到的程度。

供应链攻击是否正在增加？

在过去十年中，供应链攻击的频率和复杂程度都有所增加。ENISA 的年度《威胁态势》报告将供应链攻击记录为一种持续且不断增长的威胁类别，其攻击量逐年上升。这种发展轨迹在各具体事件中清晰可见：从 2013 年由于一家小型暖通空调（HVAC）承包商引发的 Target 数据泄露事件，到 2020 年影响美国政府的 SolarWinds 间谍活动，再到 2024 年针对 Linux 核心基础设施的 XZ Utils 险些得手的攻击。受利益驱动的犯罪组织也开始采用供应链攻击手段，正如 Kaseya 攻击事件所示：单一被入侵的 MSP 平台在几小时内就波及了数百家客户机构。

机构应如何防范供应链攻击？

组织可以通过以下措施降低供应链攻击风险：

["实施软件物料清单 (SBOM) 政策，以维护软件组件的完整库存，并在披露安全漏洞时识别受影响的系统。","要求供应商提供 SBOM，并将其最新的安全认证（SOC 2、ISO 27001）作为采购条件。","应用零信任架构原则：最小权限访问、网络微隔离以及持续的行为监控。","监控来自可信供应商的软件，以检测行为异常，而不仅仅是基于签名的指标。","遵循 CISA 的供应链安全指南，并使供应商风险评估流程与 NIST SP 800-161r1 (C-SCRM) 对齐。","维护一份事件响应计划，该计划明确涵盖第三方软件的妥协。"]

发布说明： (1) 在常见问题解答部分实施 FAQPage 结构化数据模式，并在完整页面上应用 Article 模式，以最大程度地提高获得“人们还问了”功能和富媒体搜索结果的资格。 (2) 本文中的外部引用链接至 CISA、NIST、Mandiant、Kaspersky/Securelist、Wired、OpenSSF 和 Cisco Talos 作为权威来源。 (3) 指向本站相关网络安全内容的内部链接（勒索软件攻击指南、零信任架构说明、SBOM 实施资源、供应商风险管理指南、APT 威胁行为者概述）应由发布团队在部署前添加。在撰写本文时，网站索引不包含已索引的网络安全文章，因此内部链接的放置需要编辑团队手动审核。