从美行政令看软件供应链安全标准体系的构建

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

观点

从美行政令看软件供应链安全标准体系的构建

2022-05-27 17:44:33

所属地北京

专栏 · 供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

近年来，全球软件供应链安全攻击事件持续高发，且危害越来越大，2020年底和2021年底分别爆发的SolarWinds攻击和Log4j攻击是其中的典型事件。这些使得美国更加重视自身的供应链安全防护，2021年5月12日，美总统拜登签署了“关于改善国家网络安全(EO 14028)”的行政命令，其中的第4节针对“加强软件供应链安全”提出了一系列具体要求，旨在迅速改善美国软件供应链的安全性和完整性，特别是优先解决关键软件的问题。

要求中大部分内容涉及标准、指南、措施的制定修订及对美联邦机构遵守和使用它们的限定。本文分析了这些标准指南的主要作用和侧重，并对我国软件供应链安全标准体系的建设提出了建议。

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

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

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

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

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

EO 14028要求	对应标准指南(截止2022.2.11)
2021.6.26前，发布关键软件定义(4g)	2021.6.24发布“关键软件定义及产品列表”，确定了11类关键软件；2021.7.8发布《关键软件使用安全措施》，针对五大目标制定了20条安全措施
4(g)发布30天内，发布关键软件产品类别列表(4h)
2021.7.11前，发布关键软件安全措施指南(4i)
2021.7.11前，发布建议供应商测试软件源代码的最低标准(4r)	2021.7.9发布《开发者验证软件的最低标准指南》，归纳了11类验证测试技术
2021.7.11前，美国国家电信与信息管理局(NTIA)应发布SBOM的最低要求(4f)	2021.7.12发布《SBOM最低要素》，包括数据字段、自动化支持、实践和过程等
2021.11.8前，发布加强软件供应链安全初步指南(4c)	初步指南包括关键软件定义及安全措施、已有行业标准及工具、《NIST SP 800-161 系统和组织网络安全供应链风险管理实践》第二次修订版草案中的最佳实践等。10.28发布草案并征求意见至12.10，最终版尚未发布
4(c)发布90天内，发布加强软件供应链安全的实践指南(4e)	2022.2.4发布《NIST SP 800-218 安全软件开发框架(SSDF)》第1.1版和《根据EO 14028 4e制定的软件供应链安全指导》
2022.2.6前，启动标识试点计划(4s)	2022.2.4发布《消费类软件网络安全标识推荐标准》和《消费类IoT产品网络安全标识推荐标准》
2022.2.6前，确定标识计划的物联网(IoT)安全标准(4t)
2022.2.6前，确定安全软件开发实践或软件标识计划标准(4u)
2022.5.8前，发布补充指南(4d)	未开展

不难看出，这些标准考虑了软件开发、测试、使用、流转、管理等方面的安全，也就是说，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最低要素内容

要素类别	要素内容
数据字段	每个组件的文档基线信息：供应者、组件名称、组件版本、其他唯一标识符、依赖关系、SBOM数据的作者、时间戳
自动化支持	支持自动化，以通过自动生成和机器可读性支持跨软件生态系统的扩展
自动化支持	生成和使用SBOM的数据格式，如SPDX、CycloneDX和SWID标识
实践和过程	为将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数据格式、软件安全标识等方向实践指南的研究和编制，明确详细技术要求和流程规范等。

(二) 已有标准使用方面

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