软件供应链是基于供应关系的网链系统，通过资源和过程将软件产品或服务从供应方传递给需求方。然而，近年来频繁爆发的软件供应链安全事件，如 SolarWinds 后门注入、Apache Log4j2 远程代码执行漏洞，以及最新的“微软蓝屏”事件，因其影响范围广、危害损失大、隐蔽性强、溯源困难，对全球网络空间安全造成严重威胁。为应对软件供应链安全挑战，美国联邦政府自 2021 年 5 月起制定了一系列政策和标准来提升软件供应链的安全性。截至 2024 年 3 月，这些工作已进入实施阶段，对我国软件供应链安全工作的相关实践具有一定的借鉴意义。

一、美国软件供应链安全政策演进

在制定软件供应链安全政策之前，美国已制定了供应链安全相关政策。2018 年 9 月，美国发布《国家网络战略》，要求改进联邦供应链风险管理过程。2021 年 2 月，美国发布了第 14017 号《美国供应链行政令》，要求联邦机构对关键领域和行业的全球供应链进行审查。自 2021 年 5 月起，美国针对软件供应链安全政策采取了一系列措施，这些措施经历了制度建设、制度部署和制度实施三个阶段。

第一阶段：制度建设，围绕第 14028 号行政令要求制定政策标准

此阶段始于 2021 年 5 月发布的第 14028 号行政命令《关于改善国家网络安全》（简称“第 14028 号行政令”），提出了一系列软件供应链安全要求，标志着美国正式启动软件供应链安全相关工作。该阶段美国国家标准与技术研究院（NIST）发布了一系列政策标准，用于执行第 14028 号行政令第四节中提出的软件供应链安全相关任务，包括增强关键软件安全、提高软件透明度以及加强软件抵御攻击能力等。

第二阶段：制度部署，提出针对联邦部门信息系统第三方软件应符合相关文件和标准要求

第一阶段针对软件供应链安全提出了具体要求，但尚未有相关主体落地实施。2022 年 9 月，美国公共与预算管理办公室（OMB）发布《通过安全软件开发实践增强软件供应链安全》备忘录（简称“M-22-18 号备忘录”），联邦部门信息系统使用的第三方软件应进行安全证明，符合《安全软件开发框架（SSDF）》1.1 版和《针对 14028 号行政令 4c 段的软件供应链安全指南》相关内容。之后，在 2023 年 6 月发布《通过安全软件开发实践增强软件供应链安全》备忘录（以下简称“M-23-16 号备忘录”），进一步细化了 M-22-18 号备忘录的相关要求，旨在通过安全软件开发实践来增强软件供应链的安全性。这个阶段由 OMB 主导，美国网络安全和基础设施安全局（CISA）负责执行，以这两个备忘录为标志，基于第一阶段制定的政策标准，明确了监管对象和监管要求，尚未已给出具体的监管措施。

第三阶段：制度实施，为联邦部门提供服务的第三方软件提供商需上报自我安全证明

以第二阶段提出的两个备忘录为基础，正式进入落实和实施软件供应链安全相关制度要求的阶段。该阶段始于 2024 年 3 月，即 CISA 和 OMB 发布了《软件安全开发证明表》，给出了具体的要求内容，要求为联邦部门提供服务的第三方软件提供商，填报《软件安全开发证明表》内容上报自我安全证明。此举标志着美国联邦部门及第三方软件提供商正式实施 M-22-18 号备忘录以及 M-23-16 号备忘录相关内容，启动软件供应链安全监管措施。下图从需求方和供应方两个方面，对美国相关政策标准发展情况进行了梳理。

图 美国软件供应链政策标准发展情况

二、美国软件供应链保护的工作框架和重点工作

2021 年 5 月，美国总统拜登签署了第 14028 号行政令。在该行政令的第四节“增强软件供应链安全”中，指出了软件开发中存在的若干问题，包括软件缺乏透明度、缺乏对软件抵御攻击能力的关注、缺乏防止恶意篡改措施等。行政令要求在一年内完成相关工作，以提升软件供应链，尤其是关键软件的安全性和完整性。

基于第 14028 号行政令的内容框架，美国政府相关部门已经开始部署并实施一系列针对软件供应链安全的措施，包括增强关键软件安全、提高软件透明度以及加强软件抵御攻击能力等工作。在关键软件安全方面，定义了 5 类功能 11 种软件进行重点防护；在提高软件透明度方面，采用软件物料清单进行管理；在提升软件抵御攻击能力方面，发布了一系列标准，对开发者、供应商和用户等主体提供软件供应链安全提供指导。

（一）保护关键软件安全

为响应第 14028 号行政令的相关规定，NIST 于 2021 年 7 月发布了《落实第 14028 号行政命令（EO）“关键软件”要求的安全措施》。该文件针对关键软件和关键软件平台的安全提出了五大目标，包括授权访问、数据保护、软件保护、应急响应、人员管理，并针对每个目标制定了具体措施。

为明确关键软件的相关对象，NIST 于 2021 年 10 月发布了《第 14028 号行政令的关键软件定义》，将具有或依赖于 5 类功能组件的 11 种软件定义为关键软件。这 5 类功能包括提升或管理权限、对网络或计算资源具有访问权限、数据访问管理、执行关键功能以及具有较高访问权限等与权限管理相关的功能。11 种软件涵盖身份管理、操作系统、浏览器、终端安全、网络控制、网络保护、网络监控和配置、运行监控和分析、远程扫描、远程访问和配置管理、备份恢复和远程存储等重要软件。

（二）提升软件透明度

为了提升软件透明度，美国商务部（DoC）与美国国家信息通信管理局（NTIA）于 2021 年 7 月 12 日联合发布了《软件物料清单（SBOM）的最低要求》。该文件提出了 SBOM 应包含的最少元素，用于提升软件透明度，加强软件安全漏洞管理等工作。

（三）提升软件抵御攻击能力

为了提升软件抵御攻击的能力，NIST、CISA等部门从需求方和供应方两个角度制定了相关标准。

在 NIST 方面，一是于 2022 年 2 月发布了特别出版物 NIST SP800-218《安全软件开发框架（SSDF）》1.1 版和《针对 14028 号行政令 4c 段的软件供应链安全指南》。前者从软件开发者角度提出了组织准备、软件保护、安全开发和漏洞响应 4 类共 19 种实践；后者依据前者，针对 14028 号行政令 4c 段相关要求，从政府采购角度提出对软件供应方的合格评定方法。这两个文件为 M-22-18 号备忘录和 M-22-18 号备忘录的实施提供了重要依据，并为软件供应链安全政策的实施奠定了基础。二是于 2021 年 10 月发布了标题为《开发者验证软件的最低标准指南》的内部报告 NISTIR 8397，为软件供应商和开发者提供了软件安全验证的指导。

在 CISA 方面，为了提升软件安全性，于 2022 年 8 月、9 月和 10 月与美国国家安全局（NSA）和国家情报总监办公室（ODNI）相继联合发布了《面向开发者的软件供应链安全实践指南》《面向供应商的软件供应链安全实践指南》和《面向用户的软件供应链安全实践指南》系列实践指南，针对软件开发者、供应方和使用方提出了安全指导。

（四）以“标准+自证明”模式实施

2022 年 9 月 14 日，OMB 发布了 M-22-18 号备忘录，要求自发布之日起，联邦政府机构信息系统或其他可能影响美国联邦政府机构的信息系统在使用第三方软件时，必须遵循 NIST SP800-218《安全软件开发框架（SSDF）》1.1 版和《针对 14028 号行政令 4e 段的软件供应链安全指南》这两个由 CISA 发布的指南及其后续更新。相关供应商需提供符合这两个指南要求的自我证明材料，以及 SBOM、完整性和安全性检测、参与漏洞披露计划等其他证明材料。对于备忘录发布之前已在美国联邦政府机构信息系统中使用的第三方软件，在重大版本更新时，也需遵循本备忘录的要求。

为了细化 M-22-18 号备忘录中关于实施时间、适用范围和替代材料等的相关内容，OMB 于 2023 年 6 月 9 日发布了 M-23-16 号备忘录。主要内容包括：一是明确了美国联邦政府机构收集证明的时间节点。联邦政府机构应在 CISA 和 OMB 发布通用证明表格后的 3 个月内，收集关键软件的证明信息，并在通用证明表格发布后的 6 个月内收集所有软件的证明信息。二是澄清了适用范围。第三方组件必须提交相关证明材料，而免费软件和联邦政府自行开发的软件则不在适用范围之内。三是提供了替代材料的选择。如果供应商无法提供自我证明，但有相关计划时，可以提交《行动计划与里程碑》作为替代。

为了落实 M-23-16 号备忘录为美国联邦部门提供服务的厂商上报安全自我声明相关要求，2024 年 3 月 18 日，CISA 和 OMB 发布了《软件安全开发证明表》，旨在指导与联邦政府合作的软件生产商提升产品安全性，并要求在 M-22-18 号备忘录和 M-23-16 号备忘录的要求范围内，凡 2022 年 9 月 14 日之后部署的软件，以及 2022 年 9 月 14 日之前部署但有重大版本更新的软件，其供应商必须满足并证明满足最低安全软件开发要求，填报表格并报送相应的软件需求方，以确保软件供应链安全工作的落实。

三、美国供应链安全保护特点

通过综合分析美国软件供应链安全政策和标准，我们可以发现其具有以下三方面的特点。首先，针对美国联邦政府使用的第三方软件，尤其是关键软件，美国提出了围绕需求方和供应方的安全要求。这些要求涵盖技术和管理两个层面，并以重点突出、体系完整、分阶段实施的方式推进软件供应链安全工作。其次，相关工作侧重于提升软件开发安全，聚焦于美国联邦政府机构信息系统的安全，采用“标准+自证明”的模式来落实软件供应链安全工作。最后，美国在软件供应链安全方面投入了将近一年半的时间，制定了大量相关的技术文件，包括软件供应链安全标准和指南，为推进软件供应链安全工作提供了技术指引和支持，并有效促进了软件供应链安全政策的实施。

美国的软件供应链安全政策涵盖了软件开发、交付、使用的全生命周期，提供了系统性的防护指导，全面提升了软件供应链的安全性。然而，管理链条过长以及“火力分散”的问题，也可能导致过多的行政资源消耗，实施效果有待考量。在实施重点方面，政策偏重于软件开发过程的安全，这有助于整体提升软件行业的安全性。但通过管理需求方来间接管理供应方，从而管理软件安全性的“隔山打牛”的方式，可能导致“隔靴搔痒”的效果，能否达到预期效果需进一步跟踪评估。在政策执行方面，采取供应商“标准+自证明”模式，这种模式可以有效降低监管成本，迅速对重点领域广泛实施相关政策，但无法确保结果的真实性、权威性和公正性，实施效果也需进一步跟踪评估。

四、对我国的启示

目前，我国在云计算、关键信息基础设施等领域已经制定了相应的政策，并发布了与软件供应链安全要求相关的标准。在政策方面，制定了《云计算服务安全评估办法》《网络安全审查办法》等政策，针对云平台技术、产品和服务供应链安全进行评估，并对关键信息基础设施运营者采购网络产品和服务进行网络安全审查。在标准方面，发布了《网络安全技术 软件供应链安全要求》（GB/T 43698-2024）、《ICT 供应链安全风险管理指南》（GB/T36637-2018）等标准，正在研制《关键信息基础设施信息技术产品供应链安全要求》《软件物料清单数据格式》等标准，以支撑和指导我国软件供应链安全工作的开展。

为有效支撑我国网络安全保障体系和保障能力建设，推动软件供应链安全工作，可以从以下五方面进行改进。

一是加快软件供应链安全相关政策顶层设计。政策对工作的开展具有重要的指导作用。美国的软件供应链相关工作建立在 14028 号行政令基础上，围绕行政令列出的工作依次展开。目前，我国已颁布包括《网络安全法》《数据安全法》《关键信息基础设施安全保护条例》在内的多项网络安全法律法规，但尚未出台专门针对软件供应链安全的政策文件。建议加快软件供应链安全政策的顶层设计，加强对软件供应链安全的监管，特别是针对关键信息基础设施等重点领域，为软件供应链安全相关工作提供指导和依据。

二是聚焦关键信息基础设施等重要领域的软件使用和运维环节，建立软件供应链安全保护工作机制。软件供应链安全涉及需求方、供应方、评估方、安全漏洞发布方等多个主体，涵盖软件开发、交付及使用等多个阶段。此外，还包含软件资产管理、风险评估、代码安全检测、漏洞跟踪与应急响应等多个方面。美国软件供应链安全政策侧重于供应侧，偏重技术性较强的软件开发等软件采购的“事前”环节，有助于降低未知的“0-day”漏洞的出现几率，但未能发挥政府部门的组织优势，效果很可能事倍功半，而对于软件使用和运维等采购的“事后”环节，欠缺对软件供应链安全事件响应的指导。

因此，应体系化、有重点地推进软件供应链安全相关工作。需充分发挥政府部门行政优势，组织协调相关方，聚焦于需求侧，特别是关键信息基础设施领域的软件使用和运维等软件采购“事后”环节，立足降低已公开的“1-day”漏洞的出现几率、影响时间和影响范围，建立一个由监管方、行业主管部门、运营者、软件供应方、安全厂商、漏洞披露方、测评方等共同参与的软件供应链安全工作机制。该机制应具备台账清晰、持续跟踪、动态联动、信息共享、多方协同等特点，以共同推进软件供应链安全工作。

三是加快制定软件供应链安全标准。标准的研制将有助于推动对软件供应链安全的统一认识，优化产业实践，并为软件供应链安全奠定基础。美国在第 14028 号行政令发布后，投入了将近一年半的时间制定了大量的软件供应链安全标准和指南，有力地支撑了美国软件供应链安全政策的实施，为美国软件供应链安全工作推进提供了技术指引。我国应尽快推进软件供应链安全标准的研制，包括体系架构的国家标准和配套的实施指南，特别是关键信息基础设施领域的软件供应链安全标准，以指导软件供应链安全政策的落地和实施。

四是推动构建关键信息基础设施的软件供应链安全评估体系。针对软件供应链安全建设面临的评价工具不足和安全能力提升难以量化的问题，需聚焦于关键信息基础设施，探索开展软件供应链安全能力成熟度评估，推动软件供应链安全在相关行业的实质落地，以提升关键信息基础设施的软件供应链安全水平。

五是组织开展软件供应链安全试点示范工作。邀请主要厂商、用户单位和网络安全领域的专家，遴选一批可推广、可复制的软件供应链安全方案，摸清行业底数，为软件供应链安全工作实施提供参考。