概要
- Orion 行动之所以成功，是因为攻击者入侵了软件生产过程，在自动化构建期间插入 SUNBURST，并借助 SolarWinds 正常的签名与分发机制交付了经过修改的组件。有效的签名验证的是已遭入侵的发布流程，并未独立确认最终代码与批准的源状态相符。
- 可能只有不到 18,000 家客户获取了受影响的版本，但这一数字并非后续行动中遭渗透的组织数量。后来公开估计显示，经确认或评估的后续入侵涉及 9 个美国联邦机构及不到 100 个非政府组织，而 SolarWinds 另估计只有不到 100 家客户通过 SUNBURST 被黑客攻击。
- 俄罗斯对外情报局对该间谍行动负有责任。但 SolarWinds 仍控制着构建环境、发布来源、签名路径及产品架构，正是这些要素将一次内部入侵转化为客户站点上的可信代码。客户及政府部门控制了分段、日志记录、身份强化、采购与恢复。问责归属应基于每一方实际能够操作的安全措施。
- 法律记录比运作记录更为狭窄。SEC 于 2023 年起诉 SolarWinds 及其首席信息安全官，联邦法院于 2024 年驳回了大部分指控，SEC 又于 2025 年 11 月以不得再诉为由驳回了余下诉讼。这段历史既未证明 SEC 最初的主张成立，也未确立每一项构建安全决策均属充分；它表明了为何技术可预防性、披露法律及最终法律责任必须分开分析。
该更新完全遵循了信任基础设施的指令
SolarWinds 事件常被描述为一次被投毒的软件更新。这一说法点明了交付方式，却可能使该失败听上去像是隐藏在安装程序中的普通恶意软件。更为关键的事实是，受影响的更新正是通过供应商合法的发布机制生成并交付的。管理员无需禁用签名验证、访问假冒下载站点或接受未签名的可执行文件。恶意组件被包含在 SolarWinds Orion 软件包中，并进行了数字签名。
这一区别改变了问责分析。软件签名通常被理解为一种对来源及传输过程中完整性的控制。若软件包在签名后发生更改，签名验证应当失败。但签名本身并不能证明选用于编译的源代码已获授权、编译器在干净的环境中运行、构建工作组件未被修改，或产出物与代码审查人员批准的代码相符。当攻击者在签名施加前行动时，签名可以忠实地为已然受感染的输出作保。
Mandiant 最初关于 SUNBURST 的技术披露记录了一个经 SolarWinds 签名的 Orion 插件，其中包含后门。该组件可等待最多约两周，对其环境进行侧写，通过伪装成合法 Orion 流量的 DNS 和 HTTP 模式进行通信，并仅在攻击者选定受害者后检索命令。最初的植入体被设计得安静、挑剔且与宿主产品兼容。其目的并非一举摧毁所有安装。其目的在于将可信的访问选项置于众多网络之中，并仅对其中一小部分加以利用。
这便是该事件应被纳入云依赖与公共连续性记录的原因所在，即便 Orion 通常安装在客户本地。Orion 可监控并管理本地、云及混合环境中的基础设施。后续活动能够触及联邦身份和 Microsoft 365 资源。这种信任关系恰似服务依赖：客户依赖一款持续维护的供应商产品，接受供应商生成的更新，并将软件放置在可观测或管理重要系统的位置。可执行文件的存储位置并未消除其对产出该文件的远程软件工厂的依赖。
主要的公共危害也并非传统意义上的服务中断。联邦电子邮件与运作系统并未在某一个明显的日子全部停摆。入侵行为反而损害了机密性、身份保障、证据可信度以及获知哪些通信或决策已被观察的能力。公共部门的连续性包含一种能力：即通过可捍卫其信任度的系统来开展政府业务。一个网络可在保持可用的同时，使其支撑的公共职能遭受战略性的暴露。
公开记录所确立的事实
最翔实的描述来自具有不同机构利益的多个信源：SolarWinds 的事件披露与证券文件；CrowdStrike 和 Mandiant 的技术分析；CISA、NSA、FBI 及受影响机构的记录；GAO 对联邦响应的审查；国会证词；以及后来的法庭记录。它们虽未能回答所有问题，却确立了若干核心事实。
首先，一名高水平的攻击者对 SolarWinds 的环境维持了足够长时间的访问，以研究 Orion 的生产流程。SolarWinds 在 2021 年 5 月的调查更新中表示，公司无法确切判定初始入侵是何时以何种方式发生的。该公司报告称，有证据表明凭证遭入侵，攻击者对其软件开发环境及包括 Microsoft 365 在内的内部系统进行了长期访问，至少持续了 9 个月，早于 2019 年 10 月的测试运行。SolarWinds 将可能的初始入侵路径缩小至第三方零日漏洞、暴力破解（如密码喷洒）或社会工程学，但并未声称已证实其中任何一种。
其次，恶意更改发生在自动化构建环境中，而非作为对 Orion 源代码仓库的持久修改提交。这一点并非推卸责任的技术性细节。它恰恰指出了失效的信任边界。在构建前后审查仓库的审查者可能会看到干净的源代码，而构建工作组件在编译期间临时替换了一个恶意文件。因此，仅以源代码审查为中心的控制措施将无法发现产出物与其存在差异。
第三，攻击者在部署可操作的后门之前，先测试了其修改构建的能力。SolarWinds 在 2021 年 1 月的初步构建系统调查结果中，将当时已知最早的内部可疑活动追溯至 2019 年 9 月，此后依次为：2019 年 10 月的一次 Orion 版本测试性修改、2020 年 2 月 20 日开始的 SUNBURST 注入，以及 2020 年 6 月从环境中移除恶意代码。后来公司报告将访问证据追溯得更早，同时保留了 10 月的测试和 3 月至 6 月的分发窗口期。
第四，受影响的 Orion 版本通过正常渠道分发。SolarWinds 于 2020 年 12 月 14 日提交的8-K 表指出，在相关期间内下载、实施或更新的产品包含该漏洞，并估计只有不到 18,000 家客户可能安装了受影响的版本。其 2020 年10-K 表随后将 SUNBURST 描述为注入 2020 年 3 月至 6 月发布的构建版本中，称受影响的软件安装在客户本地，并强调实际被利用的数量远小于可能安装了受影响版本的客户数量。
第五，FireEye 在 2020 年 12 月调查自身入侵时发现了这场更广泛的行动。公开记录并未显示 SolarWinds 的发布保证机制或某个联邦边界项目在客户收到更新前便检测到了受感染的构建。这一检测空白独立于 SolarWinds 在收到通知后响应是否得力的问题。某种控制措施在危机响应中表现良好，却未能在生产过程中暴露危险状况，这是可能且发生了的。
第六，美国政府随后正式将该行动归因于俄罗斯对外情报局（SVR）。CISA 于 2021 年 4 月发布的联合公告记录了美国的归因及相应的 NSA-CISA-FBI 指南；英国也公开将 SVR 与该行动关联起来。归因确定了敌对行为者的责任和地缘政治背景。但它并未回答供应商或客户的安全措施是否与可预见的供应链攻击类别相称。
有三件重要事项仍然受到限定。入侵 SolarWinds 的最初路径在引用的公司最终更新中并未得到证实。公开记录并未揭示每一个被选定进行后续访问的组织，也未显示从这些网络中窃取的每一项具体内容。并且，安装了受影响的更新并不证明某个组织遭受了交互式的利用。这些空白要求我们在表述时措辞严谨，而非分析上的瘫痪。
从侦察到签名后门
这场行动之所以耐心，是因为其目标并非仅仅一台服务器，而是一个可重复的工业流程。
攻击者首先需要获得访问权限并加以理解。构建环境包含编译器、依赖项仓库、凭据、编排工具、签名接口、发布脚本以及大量中间文件。其复杂性创造了机会，但随意的篡改会产生噪声。编译失败、可复现性不匹配、意外的源文件差异或格式错误的软件包都可能惊动工程师。因此，攻击者必须了解 Orion 构建运行的时间、哪个源文件可承载植入体、该文件如何抵达最终插件，以及如何避免破坏产品的稳定性。
2019 年 10 月的测试如今回顾起来是一个关键的预警信号。它表明攻击者在投递作战载荷之前，正在验证注入路径。在一个安全的生产设计中，仅在构建期间存在的测试性修改仍应通过产物比对、隔离的构建器监控、来源检查或确定性发布控制而被发现。测试代码竟得以进入发布版本而未暴露入侵者这一事实，证明了构建输出可能偏离预期源状态并仍能继续推进。
CrowdStrike 关于SUNSPOT 的分析解释了其机制。SUNSPOT 监视MsBuild.exe，检查命令行信息以识别 Orion 解决方案，并在产品构建期间将InventoryManager.cs替换为恶意变体。它保留原始文件以便事后恢复。其包含旨在避免构建失败的安全措施，以及意在让入侵者干净利落停止而非留下明显编译错误的行为设计。该设计将开发人员的怀疑视作主要风险。
由此产生的恶意代码成为位于SolarWinds.Orion.Core.BusinessLayer.dll内的 SUNBURST。由于替换发生在构建期间，最终软件包可如同普通产品输出一般通过后续打包与签名步骤。签名是真实的。其背后的来源声明则是不完整的。
安装后，SUNBURST 会延迟执行并检查可能表明分析的环境条件。它生成特定于受害者的 DNS 查询，并允许操作者决定哪些信标将进入更活跃的命令与控制阶段。Mandiant 的补充技术分析描述了反分析检查、域名生成行为、命令模式以及将状态混入合法 Orion 配置的努力。这种选择性降低了 18,000 个可能的安装点产生 18,000 起可见事件的风险。
对于选定的受害者，后门可成为投递其他载荷、凭证窃取、横向移动和云访问的入口。这种分布式植入体与被利用组织之间的区别至关重要。下载了受感染软件包的组织、将其安装于隔离服务器的组织、其服务器发出信标的组织以及其身份被用于后续访问的组织，分属不同的影响类别。将它们合并为单一数字会制造惊人的数字，但描绘的是糟糕的事件模型。
攻击者在 2020 年 6 月即发现前数月便已将 SUNBURST 从 SolarWinds 的构建环境中移除。这一行为限制了未来的分发，并从生产系统中清除了明显的现场证据。已安装受影响版本的客户仍保留着植入体。因此，该行动的持续时间超出了攻击者在软件工厂中的驻留期：一次生产入侵被转化为数千个独立部署的产物，各自遵循着客户的维护和保留计划。
为何源代码审查和代码签名并不足够
Orion 事件暴露了常被视作可互换的软件完整性控制措施之间的鸿沟。
源代码审查关心的是为发布所提交的代码是否可接受。构建完整性则关心编译后的产物是否确实产自于已批准的源代码、依赖项、工具和指令，且处于未受感染的环境之中。签名关心的是是否由特定的密钥授权了该产物。分发完整性关心的是客户是否收到了经签名的产物。运行时控制关心的是该产物在安装后被允许执行哪些操作。上述每项控制都可能成功，而另一项却失败。
在 Orion 案例中，公开证据表明持久化的源代码仓库并未包含 SUNBURST 修改。因此代码审查无法证明产物干净。构建系统临时代入了未经授权的源文件。签名随即将组织权威附加于输出之上。分发则将未经第三方修改的该输出交付出去。这些下游控制措施完成了各自狭隘的任务，但发布决策却建立在已然破裂的上游事实之上。
这便是构建在虚假前提之上的真实陈述在供应链场景下的翻版。软件包由 SolarWinds 真实地签了名。客户所做的推论更为宽泛：该软件包代表了 SolarWinds 意图发布的那个产品。此次事件打破了这一推论。
答案并非放弃签名。没有签名，客户同样会面临镜像入侵、网络拦截和伪造软件包的风险。答案在于强化附着于签名之上的证据。高保证的发布过程应当能够展示，哪个源代码版本、依赖集、工具链、构建器身份、构建策略、测试及审批产生了该制品；应当能检测到构建工作组件替换了存在于批准的源状态之外的文件；应当防止同一身份在未经独立检查的情况下更改源、构建策略、制品和签名决策。
可复现或独立复制的构建能够提供帮助，但它们并非魔法。如果所谓独立的构建器共享凭据、编排、依赖项或已入侵的控制平面，它们可能复现出相同的恶意输出。只有当信任路径真正分离时，比对才有意义。同样，软件物料清单可以识别组件，却无法显示构建工作组件插入了额外的第一方代码。清单有用，但并不等同于来源。
SolarWinds 后来的补救方案认识到了这一问题。其 2021 年 5 月的更新描述了三个分离的构建环境、替换构建系统、独立凭据以及跨输出产物的完整性比对。在国会证词中，CEO Sudhakar Ramakrishna 将该设计表述为一种迫使攻击者入侵多个异构环境的做法。该公司向参议院提交的书面证词，是当时所声称的响应举措及架构的证据。它本身并非对每个版本自那时起均满足该设计的独立认证。
分母问题：18,000 是暴露量，而非确认的利用量
此次事件中被重复次数最多的数字之一莫过于 18,000。只有说明其分母，该数字才有用。
SolarWinds 最初通知了约 33,000 家在受影响期间及之后保持维护的 Orion 活跃客户。该公司估计只有不到 18,000 家客户可能拥有受影响的安装。有些客户下载了更新但未安装。有些安装在了无法抵达命令与控制基础设施的系统上。有些执行了植入体但未被选定进行后续活动。数量小得多的群体与后期基础设施进行了通信，而数量更小的群体则在初始后门之外遭到了主动入侵。
2021 年 5 月，SolarWinds 估计只有不到 100 家客户通过 SUNBURST 被黑。2021 年 3 月，FBI 的证词描述了超过 16,000 家受影响的公共及私营客户，9 个联邦机构遭受了后续入侵，而该类别中的非政府实体则不足 100 个。只要将“受影响”、“已安装”、“已发信标”、“被瞄准”和“遭入侵”区分开来，这些数字就是一致的。
这种区分并不会让事件变小。一个部署给数千家组织的潜伏性管理落脚点，即便国家行为体只是有选择地利用它，也是一起严重的系统性事件。攻击者获得了一份潜在访问菜单，并可根据情报价值选择目标。风险既在于已造成的伤害，也在于可信机会的规模。
这对客户通知也很重要。供应商不应向每种暴露类别发送相同的消息。客户需要知道他们是仅仅下载了制品，还是安装了它，执行了它，生成了已知信标，收到了命令与控制响应，或者显示出后续身份滥用的证据。每种状态都会改变保存、凭证重置、重建、通知和连续性决策。若供应商侧遥测无法确定状态，那么不确定性本身也应当被传达。
公开记录也表明了为何影响不能仅凭供应商遥测推断。Orion 运行在客户网络内部，因此 SolarWinds 无法直接检查每一处安装。客户和云服务商掌握着部分证据。某些后续活动放弃了 SUNBURST 转而使用合法凭证或伪造的身份断言，这使得一台干净的 Orion 服务器并不足以证明整个环境是干净的。事件核算不得不结合供应商的下载记录、DNS 观察、主机取证、身份日志以及受影响组织的调查。
发现及滞后可见性所付出的代价
FireEye 的发现常被赞誉为一次检测成功，事实也确是如此。但它同样证明了此前安全体系的失败。
数月以来，受影响的版本通过可信的维护渠道流动。攻击者设计的植入体会休眠、避开分析环境、使用熟悉的进程上下文以及模仿合法的网络行为。传统的反病毒和边界规则难以识别一个经供应商签名、其行为类似产品自身遥测的组件。网络管理产品天然具备宽广的行为边界：它可以清点系统、跨网段通信、持有有用的凭据，并可合法地联系供应商基础设施。恶意行为可躲藏在产品所要求的权限之中。
CISA 首次公开响应便反映了这种模糊性的严重程度。其 2020 年 12 月 13 日的警报确定了受影响版本，而《紧急指令 21-01》则命令联邦民事机构断开受影响的 Orion 产品。该命令并非简单的“安装补丁”。一台已遭入侵的管理服务器可能包含证据、凭据或超出最初 DLL 范围的持久化机制。若将其作为普通漏洞处理，便可能冒险在替换初始文件后仍保留攻击者。
CISA 随后的逐出指南处理了攻击者可能已侵入 Active Directory 和 Microsoft 365 的网络。逐出可能需要协调身份恢复、令牌和凭证失效、云审查、主机重建及监控。这些步骤即使在公共服务保持在线时也会中断运作并消耗稀缺的人力资源。一次机密性入侵的连续性成本，部分即体现于恢复正当信任所需的工作量。
英国的NCSC 指南同样区分了受影响的二进制文件与严重的后续影响。它建议隔离、哈希和 DNS 检查、凭证重置、调查与 Orion 服务器关联的账户，以及考虑全面重建。此类建议在全球范围内的一致性表明，信任失效并不仅限于某国政府的采购环境。
检测责任是分散的。SolarWinds 处于最佳位置以监控构建工作组件、将制品与批准的源相比对、监督签名并识别异常的发布来源。客户则处于最佳位置以限制 Orion 的权限、隔离其主机、保留 DNS 和身份日志，并注意到偏离其自身环境的行为。云身份提供商能够跨租户检测异常的令牌和账户使用情况。政府协调机构可汇总报告并发布强制行动。任何单一观察者都不掌握全貌，这使得及时的信息共享成为一项功能性控制，而非仅出于礼貌。
响应过程也展示了一项关于指标的残酷事实。哈希和域名在分类鉴别时很有价值，但有耐心的攻击者可以轮换基础设施并转向有效账户。一旦入侵已越入身份系统，已知指标的缺失便不再是未受感染的有效证明。持久的响应必须重建攻击路径，并从已知干净的状态重新建立信任。
无可见中断的公共部门连续性
GAO 将此次行动描述为针对联邦政府及私营部门发起的最为广泛和复杂的黑客行动之一。其2022 年联邦响应审查认为，各机构成立了一个网络统一协调小组，提供了技术指南和工具，共享了信息，并总结了关于协调、信息获取和事件响应的经验教训。响应之所以如此规模庞大，是因为此次入侵触及了政府用以了解并管理自身系统的机制本身。
九个联邦机构被公开指认为遭受了后续入侵。司法部表示，恶意活动触及了其 Microsoft 365 邮件环境，约 3% 的邮箱可能被访问，同时并无迹象表明涉密系统受到影响。司法部2021 年 1 月的声明恰当地界定了已知的影响。它并未将非涉密邮件的暴露视为无害，也未声称其缺乏证据的系统遭到了入侵。
在此背景下，连续性存在若干层面。
第一层面是运营可用性。各机构必须在隔离管理服务器、重建主机、轮换凭证及调查云账户的同时，继续提供公共服务。一份紧急指令可能技术必要而运营上却具有破坏性。
第二层面是机密性的连续性。官员们需要了解政策草案、采购信息、法律策略、日程安排或联系网络是否被观察。间谍行动可在不改动或销毁文件的情况下，从中提取持久的优势。
第三层面是行政完整性。Orion 在监控和管理网络方面的角色意味着，客户不得不质疑本应支撑信任的工具所提供的信息。一个遭入侵的管理平面可隐藏活动、暴露凭据，或使操作者对用于调查的系统本身产生不确定感。
第四层面是身份连续性。NSA 于 2020 年 12 月发布的身份验证机制公告解释了，本地特权访问如何导致伪造的联合身份验证和云访问。一旦本地身份信任被操纵，仅清理最初的 Orion 主机并不能恢复派生自它的每个会话或令牌的有效性。
第五层面是证据连续性。各机构需要保留的 DNS、终端、身份、云和管理日志，以确定所下载的更新是否变成了信标或全面入侵。若这些记录已超出保存期限，领导者就必须在更大的不确定性下运作，并可能需要进行更广泛的修复。
第六层面是机构信任。政府买家要求雇员使用共享的商业技术来完成敏感的公共工作。这一模式依赖于供应商准确地陈述安全实践、以适当的精确度披露事件，并提供足够的证据以支持响应。一个携带后门的签名更新，削弱了补丁管理程序所依赖的社会和行政假定。
此次行动并未表明自动更新本身是不安全的。延迟安装真实的安全补丁可能危险得多。它表明的是，更新保证必须涵盖生产者的开发和构建环境。一边要求客户快速修补，一边将软件工厂视作普通的公司网络，会造成一种矛盾：客户在接受更新方面越安全，遭入侵的生产者所获得的杠杆作用就越大。
SolarWinds 的责任：对工厂的控制
SolarWinds 是一起蓄意国家行动的受害者。但该公司也占据着使分发机制成为可能的控制位置。
公司控制了对其软件开发系统、构建工作组件、发布编排、制品验证、签名路径以及客户更新渠道的访问。客户无法在 SolarWinds 的构建器内部署终端监控。他们无法将签名前的制品与公司批准的源进行比对，无法要求进行第二次内部构建，也无法阻止供应商的签名密钥为受感染的输出授权。这些都是生产者的控制措施。
运营问责即随此控制而来。相关的问题并非是否有任何一家合理的公司能够保证免受 SVR 的侵害。没有生产者能够承诺这一点。问题在于，发布流程是否包含了足以防止单个遭入侵的环境静默地更改已签名产品，或足以在大规模分发前检测到该更改的独立控制措施。
2019 年 10 月的测试以及后来的 SUNSPOT 行动表明，攻击者发现了修改构建而不会造成中止发布级的差异的空间。长时间的内部访问以及未能检测到生产操纵，都是控制评估中的不利事实。攻击者的技术水平与所需的抵御水平相关，但这并非豁免。一家产品在政府和大型企业中占据特权位置的供应商，应当预料到自身会成为高水平行为者的攻击目标，并据此设计工厂。
责任还包括事件沟通。SolarWinds 通知了客户，与调查人员合作，发布了关于 SUNSPOT 的技术信息，提供了补救措施，并资助了部分客户支持。这些行动减少了危害，并提供了异常有用的行业证据。它们应被记入记录。问责并非在寻找一个永久性的可指摘标签；它既包括失效的控制措施，也包括响应的质量。
公司在几项重要问题上的披露是谨慎的。SolarWinds 在政府归因之前没有自行归因攻击者。它区分了潜在安装与经确认的后续利用。它承认初始访问途径仍未确定。其文件认识到诉讼、调查、成本、客户和声誉风险。这些都是有意义的优点，尽管后来的执法诉讼对该公司此前公开安全声明的某些方面提出了争议。
生产者的职责并不止于交付修正后的二进制文件。SolarWinds 需要证明，构建路径本身已发生变化，签名权威无法为无法解释的制品背书，凭据和第三方访问已受限制，并且证据将存留足够长的时间以调查一场耐心的入侵。其所声称的三构建架构响应了入侵机制。持久的保证要求独立测试，该分离在真实的运营压力下能否存续。
客户的责任：约束可信产品
客户并未控制 SolarWinds 的构建系统，但他们控制着 Orion 安装于其中的环境。其责任始于产品进入该环境之时。
网络管理软件不应仅因其便捷而获得无限的信任。客户可以隔离管理服务器、限制出站互联网访问、分离服务账户、最小化常设权限、保护管理凭据、监控产品的网络行为，并将日志保留在受监控的系统之外。NCSC 指出，一个无法解析或触达外部基础设施的受影响服务器，可阻止初始后门的发展。这正是客户侧防御限制供应商源头失败的一个具体例子。
客户同样控制着云和本地身份信任是否允许一个遭入侵的管理主机变为更广泛的凭据权威。分离的管理工作站、分层身份、防钓鱼的多因素认证、受限的联邦、令牌监控以及恢复计划，均可降低后续活动的延伸范围。这些控制无法使交付的 DLL 变为良性，但它们能够改变执行该 DLL 的后果。
采购和架构团队还有另一项职责：将 Orion 归类为高后果依赖项。一个可查看网络拓扑、处理管理凭据或监控关键资产的工具，应与普通桌面工具区别对待。买方应当了解哪些产品可以进行自我更新、它们信任哪些签名根、发布制品的来源是哪里、以及在不丢失运营可见性的情况下，他们能以多快的速度隔离或替换该产品。
客户的责任仍须受到可行性的约束。在 2020 年，客户无法从一个已签名的安装程序中重建 SolarWinds 的私有构建来源。大多数买方缺乏合同权利或技术手段来审计生产流水线。即便是出色的网络分段，也无法告知他们一个签名的组件是否与批准的内部源状态相符。当共享责任制将客户无法行使的控制措施分配给他们时，它便成为推诿。
因此，正确的结论并非客户是无助的，也非他们因信任更新而造成了入侵。应用签名的供应商更新通常是预期的安全行为。客户有责任限制可信组件的波及范围，并保持独立的检测。SolarWinds 则有责任确保其授权和分发的产品的完整性。这些责任在降低风险方面相互重叠，但并不因此变得可以互换。
政府的责任：作为买家、协调者及连续性的所有者
联邦政府不仅是受害者。它还是主要买家、监管者与标准制定者、情报持有者，以及最终对公共使命负责的运营者。
在 SolarWinds 事件之前，联邦供应链风险管理本已不完善。GAO 在 2021 年 5 月的证词中指出，经审查的 23 个民事机构中，没有一个完全实施了选定的基础信息与通信技术供应链实践。这一时机很重要：政府不能将全部负担推给供应商，而自身却在盘点、评估和持续管理机构所依赖的关键软件方面存在不足。
各机构控制着产品部署位置、服务账户权限、网络出口、身份架构、日志记录、采购需求及恢复能力。CISA 的紧急指令之所以必要，部分原因在于受影响的机构必须一致且迅速地行动。一份成熟的连续性计划本应已知道 Orion 安装在哪里、它可以触达何处、它使用哪些凭据、断开连接时会失去哪些运营可视性，以及如何暂时替换该功能。
政府还拥有单个客户无法获得的总和优势。CISA、FBI、NSA、ODNI 及行业伙伴可结合保密与非保密信息、关联报告、发布指标并协调逐出。GAO 发现，网络统一协调小组帮助组织了响应，同时也指出了涉及信息共享和私营部门访问方面的挑战。当每个受影响组织都在单独试图确定同一个已签名文件是否危险时，协调延迟是有公共代价的。
采购是政府最有力的预防性杠杆之一。买方可以要求提供安全开发证明、事件通知条款、制品来源、漏洞披露、证据保留、响应期间的配合，以及获取独立保证的权利。他们同样可以避免那种只询问供应商是否具备安全开发生命周期，却不测试构建是否会偏离经审查源头的打勾式合规。
事件之后的政策记录正朝着这个方向迈进。NIST 的安全软件开发框架包含保护开发环境、保存来源、验证发布、响应漏洞以及防止再次发生的实践。NIST 的网络安全供应链指南将供应商风险纳入企业治理，而非将其留给采购问卷。OMB 的M-22-18 备忘录要求联邦机构针对覆盖软件获取与 NIST 安全开发实践相关联的软件生产者证明。
证明只有在真实、范围明确且可测试时才是有用的。如果底层的生产证据无法获得，一份签署的声明无法解决与签名二进制文件相同的认识论问题。高后果买家需要能够要求提供制品、例外情况、独立评估和纠正计划。虚假的保证可能通过鼓励快速信任却不提供验证声称的途径，而增加风险。
法律记录并未提供一个简单的裁决
事件发生后，运营问责与法律责任截然分道扬镳。
2023 年 10 月，SEC 指控 SolarWinds 公司及首席信息安全官 Timothy Brown 存在欺诈和内部控制违规。SEC 的诉讼公告称，公开声明夸大了安全实践，并淡化了 SUNBURST 爆发前的已知风险。这些指控意义重大，但起诉书是控方的诉状，而非事实认定。
2024 年 7 月，美国纽约南区联邦地区法院驳回了 SEC 的大部分诉讼请求。法院允许基于该公司在 SUNBURST 事件前网站安全声明的证券欺诈索赔继续推进，认为修改后的起诉书充分提出了关于访问控制和密码实践的误导性声明。法院驳回了基于风险披露、2020 年 12 月提交的 8-K 表、事件后声明、内部会计控制及披露控制提出的索赔。该裁决适用了诉状标准和证券法标准。它并未就 SUNBURST 的技术成因进行审理，也未宣布构建过程是安全的。
2025 年 11 月 20 日，SEC 与被告共同约定不得再诉地驳回此案。该机构的最终诉讼公告表示，该决定系行使裁量权，并不必然反映其在另一案件中的立场。不得再诉的驳回结束了该项执法行动。这意味着存留下来的指控并未成为最终的赔偿责任判决。
这一过程支持四项严谨的结论。
第一，不应将 SEC 最初的理论作为既定事实加以重复。许多索赔被驳回，且无一进入审判裁决。
第二，执法案件的驳回不应被描述为技术证明 SolarWinds 在 2019 和 2020 年的构建控制达到了充分的标准。该案涉及特定的声明、要件、法规和诉状规则。法院可以在拒绝证券索赔的同时，工程控制失效仍是被记录在案的。
第三，在驳回之前幸存的网站声明索赔表明，当自愿的安全声明宽泛且难以与内部状况相符时，它们可能产生问责风险。供应商应精确地描述成果、范围、例外和保证证据，而非承诺一种泛化的安全态势。
第四，法律上的不确定性并不妨碍控制能力分析。SolarWinds 控制了工厂；客户控制了部署边界；政府控制了公共采购与协调；SVR 控制了敌对行动。合同、损害赔偿、因果关系、管辖权和法定义务决定了该运营地图是否转变为法律救济。本文所引用的任何信源均不支持在各方之间分配法律责任百分比。
此事件还揭示了一种政策张力。当公司淡化已知事件时，激进的执法可能改善坦诚度。但也可能遏制内部记录或自愿威胁共享，倘若安全人员认为每一项初步关切日后都会被诉为欺诈的话。更好的问责制度奖励及时、带有置信度标签的披露，同时惩罚在适当标准下被证明为重大失实的声明。它不应要求以防无可防的完美作为被视为受害者的代价。
修复必须改变的是证据，而不仅仅是架构图
SolarWinds 报告了发现后的广泛变化：更广泛的多因素认证、更严格的最小权限原则、对第三方应用的更严格审查、增强的监控、重新设计的构建流程、多个隔离的构建器、分离的凭据、输出比对、静态分析、开源分析、渗透测试以及资产追踪。其公开分享 SUNSPOT 细节的做法为其他生产者提供了一个具体的威胁模型。这些都是相关且针对机制的响应。
最有力的修复声明并非“我们现在在三个地方构建”。而是一整套证据，表明未经授权的临时源更改无法在不产生可检测差异的情况下抵达签名的发布版本。该证据应能经受人事变动、期限压力、紧急补丁和构建器替换的考验。
一份可信的保证包至少应回答以下问题：
- 是否每个已发布的二进制文件都能追溯到一个不可变的、经批准的源代码修订版本、依赖集、编译器和构建策略？
- 构建工作组件是否为临时性或从已验证状态恢复，它们的控制平面是否与普通公司身份相隔离？
- 单一凭据能否更改构建、压制遥测并请求生产签名？
- 分离的构建是否真正独立，还是共用了可能导致相同入侵结果的隐藏依赖项？
- 签名服务是否验证来源和策略，还是会为由授权账户提交的任何制品签名？
- 构建和签名日志是否被写入一个独立管理、防篡改的存储中，并针对国家行为体预期的驻留时间进行保留？
- 是否使用测试金丝雀或受控故障注入来证明，未经授权的构建变更会中止发布？
- 供应商能否撤销一个版本，按暴露类别通知客户，并在不破坏法庭证据的情况下提供干净的恢复制品？
- 客户收到的是可验证的来源还是一份签名和营销保证？
- 领导层和那些风险因此发生变化的客户，是否能看到例外情况？
这些并非要求向每个买方披露源代码或敏感的生产秘密。独立审计人员、政府评估人员和受控的透明度机制可以在不公布攻击地图的情况下验证结果。目标是与产品的特权级别和系统性影响相称的证据。
客户需要补充性证明。他们应能表明 Orion 或同等的管理平台无法自由抵达每一个管理层级；服务账户的范围是受限的；在实际可行的情况下，出站流量采取了许可名单制；身份和 DNS 日志离开了受管理环境；一台遭入侵的管理服务器可在不丧失所有运营感知能力的情况下隔离；并且云联合体可从已知的干净权威重建。
政府买家应测试连续性，而非仅仅接收文书。一场桌面推演可以要求某机构在数小时内断开其网络管理平台，枚举相关联的凭据，保存证据，借助替代工具恢复可视性，并协调身份重置。在该演练中的失败，可在真正指令到来之前识别出公共风险。
问责的实际分配
当根据控制能力而非与头条新闻的接近程度来分配责任时，该事件会变得更加清晰。
根据美国及其盟友的归因，俄罗斯 SVR 策划并实施了这场间谍行动。它选择入侵一家供应商，设计了 SUNSPOT 和 SUNBURST，挑选了下游目标，并利用了窃取的访问权限。其罪责是首位的且为蓄意的。
SolarWinds 控制着其内部访问架构是否限制了攻击者，构建输出是否必须与经批准的源相符，构建器和签名是否受到独立监督，异常的发布行为是否会产生警报，以及客户是否收到了准确且及时的证据。该公司还控制着修复和披露的重要部分。其受害者身份并不能免除这些责任；它后来的透明度不会抹去最初的失败，但可以减少未来的伤害。
客户控制着产品部署位置、权限、网络路径、日志保留、事件升级和身份恢复。一个赋予 Orion 无限制管理权限且外部监控薄弱的组织，比之将平台隔离的组织，承受了更严重的后果。这种差异影响着可预防性和损害，尽管客户双方均未造成恶意发布。
云和身份提供商控制着跨租户遥测，以及检测或作废伪造或滥用身份验证的机制。后续云访问将一起软件供应链事件变为了一起更广泛的身份事件。因此，提供商的合作与日志成为恢复信任的一部分。
联邦机构领导人控制着使命连续性、资产清单、采购条件以及政府范围内供应链实践的落实情况。CISA 和合作机构控制着协调后的警报、指令、工具和共享的事件理解。国会和监管机构控制着监督和激励，受限于其法定权限。
软件生产者的高管和董事会控制着决定构建安全究竟是一项产品需求还是一个尽力而为的内部项目的资源和激励。一个具有管理权限的软件的构建流水线，是产品安全边界的一部分。关于它的投资决策，应像关于已交付代码的决策一样来治理。
没有任何一方的责任能够抵消另一方的。“客户本应对 Orion 进行分段”并不能回答为何未经授权的制品被签名。“SolarWinds 本应保护构建环境”并不能回答为何一台管理服务器能够触达客户价值最高的身份。“SVR 技术精湛”并不能回答是否存在独立的构建验证。一个成熟的描述允许这三种陈述同时为真，却依然追问每一方现在必须证明什么。
持久的教训：签名需要一条生产真相链
SolarWinds 入侵事件改变了软件供应链政策，因为它利用了一种在其他方面本应可取的习惯：从供应商处获取更新，验证签名，并迅速加以应用。该事件并未使这一习惯变得不理性。它表明的是，客户信任已经超出了生产过程所暴露的证据。
纠正模式是一条生产真相链。已批准的源应导向一个指定的构建请求。该请求应在加固的、可观测的环境中运行。依赖项和工具应被锁定和记录。生成的制品应与独立的预期进行比对。签名只应在策略和来源检查之后发生。分发应保护制品。客户应能验证比持有签名密钥更多的东西。日志应使每条链接在长时间的驻留后都是可调查的。
该模式同样改进了公共连续性。当一个发布版本受到质疑时，各机构可以确定他们运行了哪个制品、哪个源和构建器产生了它、它拥有何种权限、它联系了什么，以及哪些身份必须被恢复。不确定性收窄。响应变得有针对性而非不分青红皂白。关键服务花更少时间在重建可被证明干净的系统上，而将更多时间花在那些无法证明的系统上。
SolarWinds 不应仅仅被记住是一家被黑的公司，或是被用来要求无限供应商责任的象征。更有用的教训是制度性的。一家软件生产者即使在销售本地产品时，也可能成为其客户的基础设施。它的构建系统即使在客户从未见过的情况下，也可能成为公共信任边界。而一个加密签名可以完全有效，而人们附加其上的组织声明却是虚假的。
问责标准应追随这一现实。攻击者对入侵负责。供应商对使发布路径具有抵御力、可观测且如实描述负责。客户对遏制产品并保存独立证据负责。政府负责在着眼于这些依赖的情况下进行采购，并在信任崩溃时维持公共使命。2020 年的 Orion 行动跨越了所有四个领域。持久的修复也必须如此。