文│奇安信集团代码安全事业部 董国伟

近年来，全球软件供应链安全攻击事件持续高发，且危害越来越大。2020 年底和 2021 年底分别爆发的太阳风网络攻击事件和Log4j 网络攻击事件使得美国更加重视自身的供应链安全防护。2021 年 5 月 12 日，美总统拜登签署了“关于改善国家网络安全（EO 14028）”的行政命令，其中的第 4 节针对“加强软件供应链安全”提出了一系列具体要求，旨在迅速改善美国软件供应链的安全性和完整性，特别是优先解决关键软件的问题。要求中大部分内容涉及标准、指南、措施的制定修订及对美联邦机构遵守和使用它们的限定。本文分析了这些标准指南的主要作用和侧重，并对我国软件供应链安全标准体系的建设提出了建议。

一、五类安全标准覆盖软件供应链主要环节

分析发现，EO 14028 所涉软件供应链安全标准指南主要包括五类，即关键软件的安全使用指南、软件供应链的安全开发指南、针对供应商软件的安全测试标准、包含软件物料清单 (SBOM) 与网络安全标识在内的安全标记标准以及面向组织供应链风险管控的综合安全管理指南，如图 1 所示。

图 软件供应链安全标准分类示意图

表 1 给出了具体指南及完成情况。除《SBOM最低要素》外，其他都由美国国家标准与技术研究院（NIST）主导完成；修订的标准有两项，SP800-161 和 SP 800-218；关键软件相关指南作为需“优先解决的问题”被最早制定完成并发布。

表 1 EO 14028 涉及的软件供应链安全标准指南

根据以上内容可以发现，这些标准考虑了软件开发、测试、使用、流转、管理等方面的安全，即 NIST 等通过梳理归纳已有的（如关键软件安全措施的每项和 SSDF 每项任务后都详细列出了参考标准）和新收集的（如 NIST 在 2021 年 6 月、9 月、12 月多次组织标准草案研讨会，仅 6 月就收集了 150 多份意见）标准、工具和最佳实践，形成了一个覆盖软件供应链主要环节的安全防护标准体系。

二、各类标准对软件供应链安全的规范作用

（一）安全使用指南

《关键软件使用安全措施》聚焦美国联邦机构对关键软件的使用，不考虑开发和获取。安全措施针对关键软件或平台的未授权访问防护、数据保护、软件资产识别、威胁快速检测和响应、人员培训及行为管理等目标，包含“建立并维护大数据清单”“建立并维护软件清单”“快速识别、记录并缓解已知漏洞，持续减少暴露时间”等措施，软件成分分析（SCA）工具可为后两项措施的落地提供自动化辅助能力。所有措施的参考文献都包括《提升关键基础设施网络安全的框架 (CSF)》第 1.1 版和《NIST SP 800-53 信息系统和组织的安全与隐私控制》第 5 版两项。

（二）安全开发指南

NIST 根据 EO 14028 的要求修订了《安全软件开发框架》（SSDF）。SSDF 描述了一组高层级安全软件开发最佳实践，其重点关注实现实践的结果，而没有明确实现它们的具体工具、技术和机制。第 1.1 版中定义了组织准备（PO）、保护软件（PS）、生产安全性良好的软件（PW）、漏洞响应（RV） 等四类 19 项实践，这些实践直接或间接（如保护开发环境）涉及软件本身，即考虑到了软件供应链的主要要素。每项实践又被分解为若干完成它所需的“任务”。

SSDF 1.1 的实践和任务涵盖了需求、设计、第三方软件集成、编码、构建、源代码和可执行码测试、漏洞修复响应和分析等阶段，考虑了人员、工具链、开发环境、授权访问、完整性、安全配置等软件生产要素；与 1.0 版相比，新版增加和调整的任务主要涉及维护组件和依赖项的来源数据、验证第三方组件、与第三方沟通需求、开发环境安全等；使用自动化工具检测并修复已知和未知漏洞依然是软件供应链安全的核心工作，框架中超 4 成的任务与此有关，可由安全人员在静态应用安全测试（SAST）、交互式应用安全测试（IAST）和SCA等自动化工具的辅助下完成漏洞检测。SSDF 是以软件生产者视角描述的，为了从美联邦机构（购买者）的角度响应行政令要求，《根据 EO 14028 4e 制定的软件供应链安全指导》提供了一系列建议，用来确保它们所购买软件的生产商遵循基于风险的安全软件开发方法。生产商通过向购买机构提供工件及符合性证明，将安全软件开发实践的符合性作为其内部流程的一部分。

（三）安全测试标准

《开发者验证软件的最低标准指南》向软件供应商和开发人员推荐了验证的最低标准，为软件生产者提供了高级别指导方针。之所以叫做“验证”，是由于为了识别和修复安全缺陷，指南引入了许多静态和主动的保障技术、工具、流程。指南扩展了 SSDF 的“生产安全性良好的软件（PW）”类实践，特别是“审查分析可读代码以识别漏洞并验证安全需求的符合性（PW.7）”和“测试可执行代码以识别漏洞并验证安全需求的符合性（PW.8）”两项。

指南共推荐了 11 种安全验证和测试技术，其中的威胁建模、代码扫描、黑盒测试、模糊测试、网络应用扫描等是针对设计方案、源代码、可执行代码、Web 服务软件的传统安全检测技术；“运行内置检查和保护”、“检查所包含的库、包、服务等代码”两项技术考虑到了软件供应链中普遍存在的编译构建和第三方代码的安全问题；“检查硬编码敏感信息”作为一种技术被单独提到，说明了此类问题的严重性和受重视程度。

（四）安全标记标准

EO 14028 中明确的供应链标记主要有两种，SBOM 和网络安全标识。SBOM 是构建软件时所使用各种组件的详细信息和供应链关系的记录，能够为生产者、消费者和软件操作者提供可深入理解供应链的信息；网络安全标识则是消费类软件和 IoT 等产品与安全有关的信息，可以在消费者做出购买决定时提供参考。

1. SBOM 标准

《SBOM 最低要素》将 SBOM 的主要作用确定为软件组件识别、外部数据与软件产品关联 ( 如软件与漏洞数据的映射 ) 等，这些也是 SCA 工具实现的重要基础。基于此，标准确定的最低要素内容如表 2 所示。软件包数据交换（SPDX）已于2021 年 8 月作为国际标准 ISO/IEC 5962:2021 发布；实践和过程中的“深度”、“已知的未知情况”均与依赖相关，前者表示 SBOM 使用者可通过传递依赖步骤数量指定深度，后者指需要清楚区分没有进一步依赖关系的组件和依赖关系未知且不完整的组件等情况。依赖关系的准确与否会直接影响漏洞真实可利用性的判定，这一点在标准中也进行了说明。

表 2 SBOM 最低要素内容

2. 网络安全标识标准

NIST 的标识计划致力于根据最低要求和预期结果确定标识的关键要素，而非建立自己的标识。《消费类软件网络安全标识推荐标准》和《消费类 IoT 产品网络安全标识推荐标准》虽然面向的对象不同，但都重点描述了基线标准、标识内容和符合性评估三个部分。

消费类软件的基线技术标准是一系列关于软件的声明，定义了应向消费者传递的有关安全软件开发实践和其他安全属性的信息，包括描述性声明和安全软件开发声明两类，其中后者共 8 项，如实现安全开发过程、实施负责任的漏洞披露、提供软件完整性和来源信息、无硬编码敏感信息等，有多项与 SSDF 的实践或任务对应；IoT 产品的基线产品标准是 IoT 产品或其开发者预期的网络安全结果，共 10 项，如资产识别、数据保护、网络安全状态识别等，基线还给出了上述各项内容对常见 IoT 漏洞的防护作用。

标识内容包括网络安全相关风险和属性的表示、标识有效性的测试、标识及其意义的公众教育等。对于两类软件，NIST 均建议采用二元标识（Binary Label），并与分层方法结合使用，以便于消费者获取标识项目额外的线上信息和软件的符合性信息声明。

符合性评估用来识别软件或产品是否满足基线标准中指定的要求。鉴于软件产品及所涉及风险的范围较广，两个推荐标准中均未指定单一固定的符合性评估方法，但都列举了供应商符合性声明（SDOC）、第三方测试或检查、第三方认证等方法作为参考。

（五）综合安全管理指南

NIST SP 800-161 最初命名为《联邦信息系统和组织供应链风险管理实践》，是为了给美联邦机构组织提供识别、评估、选择、实施信息通信技术（ICT）供应链风险管理流程的指导，帮助它们缓解供应链安全风险而制定的指南。它通过层级式的管理框架、四步骤的管理流程、多类别的缓解活动，将 ICT 供应链风险管理整合到组织的整体风险管理体系中。

SP 800-161 修订版草案被命名为《系统和组织网络安全供应链风险管理实践》，对象不再着重强调“联邦机构”，更多使用“企业”，但目标及总体框架与之前基本一致。草案中明确，指南并非要为网络安全供应链风险管理（C-SCRM）提供一个确定的路线图，企业可基于策略、指导方针、响应方案或其他特定需求对其中的流程和控制进行修改或补充。

草案增加了“C-SCRM 关键实践”章节以指导组织的使用，它分别描述了基本、持续和增强三个组织能力级别的实践内容。此外，作为指南的核心内容之一，草案中“C-SCRM 安全控制”类别的数量从原来的 19 增至 20，增加了“供应链风险管理 (SR)”和“个人识别信息处理和透明度 (PT)”两类，分别针对 C-SCRM的策略方法流程工具、PII 的处理及透明度问题；去掉了“来源 (PV)”类控制，将其作为控制项SR-4( 以 SBOM 的形式 ) 并入 SR 类中；其他类的控制项也有不同程度的增删调整。

草案还增加了附录 E 和 F，其中附录 F 重点介绍了与 EO 14028 4(c) 有关的第三方软件和服务的获取、使用及维护等软件供应链安全实践（C-SCRM 的一个子集），给组织的 IT、C-SCRM、采购等部门提供了遵守行政令的指导。附录 F 给出了“关键软件定义”、《关键软件使用安全措施》和《开发者验证软件的最低标准指南》等对草案其他章节内容，特别是C-SCRM 安全控制项的影响或与它们的对应关系。

此外，附录还对 SBOM、增强的供应商风险评估、开源软件控制、漏洞管理实践等为美联邦机构量身定制的软件供应链新概念，列举了组织在基本、持续、增强三个能力级别上应采取的实践的范例。例如对于“开源软件控制”，三个级别的实践分别包括使用 SCA 工具识别已公开的源代码漏洞、使用二进制 SCA 作为源代码 SCA 的补充以识别构建和运行中可能引入的问题组件、避免使用未内置防护措施来缓解常见漏洞类型的编程语言和框架等。

三、我国软件供应链安全标准体系建设建议

我国已发布《GB/T 36637-2018 ICT 供应链安全风险管理指南》，并且正在制定软件和 IT产品供应链安全要求的国家标准，顶层规范正在不断完善。根据目前状况，本文建议加快构建我国的软件供应链安全标准化体系，为软件供应链相关组织机构、企业和人员提供更多可操作性较强的指导细则。

（一）新标准制定方面

推进软件安全开发、软件供应链安全工具能力评估、开源软件安全使用、软件代码安全测试、SBOM 数据格式、软件安全标识等方向实践指南的研究和编制，明确详细技术要求和流程规范等。

（二）已有标准使用方面

对已发布的安全编程、代码安全审计、漏洞检测、软件安全检测等方面的国家标准进行系统研究，分析它们对软件供应链安全的技术保障作用，从中梳理出具体操作指南，加大宣传力度并推广使用，必要时可考虑进行修订。

（本文刊登于《中国信息安全》杂志2022年第2期）

声明：本文来自中国信息安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。