行政命令 (EO) 14028 第 4e 节
软件供应链安全指南
2022 年 2 月 4 日
翻译 樊山
介绍
2021 年 5 月 12 日关于改善国家网络安全的第 14028 号行政命令 (EO) 指示美国国家标准与技术研究院 (NIST) 发布软件供应链安全实践指南。第 4e 节以以下文本开头，其后为十个编号项目，为简洁起见此处省略。
（第 4e 节）在根据本节 (c) 小节发布初步指南后的 90 天内，商务部长通过 NIST 主任与 NIST 主任认为适当的此类机构的负责人协商，应发布指南，确定增强软件供应链安全性的实践。此类指南可能包含根据本节 (c) 和 (i) 小节发布的指南。
EO 还指示管理和预算办公室 (OMB) 要求各机构遵守已发布的指南。
（第 4k 节）在本节 (e) 小节所述指南发布后 30 天内，OMB 主任通过 OMB 内的电子政府办公室管理员行事，应采取适当措施，要求各机构遵守此类指南对于在本订单日期之后采购的软件。
为了收集有关指南可能实践的意见，NIST 从社区征集立场文件，于 6 月举办了一次虚拟研讨会，并于 11 月举办了第二次虚拟研讨会，与其他联邦机构协商，并审查了现有的联邦指南。
本文档首先解释 NIST 处理第 4e 节的方法。接下来，它为承担软件采购相关职责的联邦机构工作人员（例如，采购和采购官员、专业技术人员）定义了指导方针。这些指南旨在帮助联邦机构工作人员了解软件生产商需要哪些信息来了解他们的安全软件开发实践。本文档以提供更多信息的常见问题 (FAQ) 结尾。
指导目的和范围
EO 14028 强调“联邦政府使用的软件的安全性对于联邦政府执行其关键职能的能力至关重要”，并且“迫切需要实施更严格和可预测的机制以确保产品安全运行，以及如预期。”因此，出于三个原因，应在整个软件生命周期中集成安全软件开发实践：1) 减少已发布软件中漏洞的数量，2) 减少利用未检测到或未解决的漏洞的潜在影响，以及 3) 解决防止漏洞再次发生的根本原因。 [SP 800-218]
EO 14028 第 4e 节包含 10 个小节或项目。它们中的每一个都为软件生产商指定了行动或结果，例如商业现货 (COTS) 产品供应商、政府现货 (GOTS) 软件开发商、承包商和其他定制软件开发商。在 EO 14028 发布之前，NIST 已经发布了最初的安全软件开发框架 (SSDF)，它定义了基于结果的安全软件开发实践和软件生产商要遵循的任务。
最初的 SSDF 已经解决了第 4e 节中的大部分项目。NIST 此后修订了 SSDF 以解决第 4e 节的所有项目，从而产生了 SP 800-218，安全软件开发框架 (SSDF) 版本 1.1：降低软件漏洞风险的建议。常见问题解答 #7 包含每个第 4e 节项目与帮助解决它的 SSDF 实践和任务的映射。
SP 800-218 从软件生产者的角度解决了第 4e 节。软件生产者是实施 SSDF 实践的人。第 4k 节解释说，联邦机构将需要遵守针对第 4e 节的 NIST 指南。在这种情况下，联邦机构是软件购买者，而不是软件生产者，因此需要额外的指导来从软件购买者的角度来处理第 4e 节。本文档定义了该指南。
本文档向联邦机构提供建议，以确保他们采购的软件生产商在整个软件生命周期中一直遵循基于风险的安全软件开发方法。这些建议旨在帮助联邦机构从软件生产商那里获得他们需要的信息，这些信息可以用来做出基于风险的软件采购决策。这些建议从软件购买者（联邦机构）的角度解决了第 4e 节中的所有项目。它们涉及软件生产商，通过向联邦机构购买者提供工件和/或证明符合性，将其与安全软件开发实践的符合性作为其内部流程的一部分。
本指南的范围仅限于联邦机构采购软件，包括固件、操作系统、应用程序和应用程序服务（例如，基于云的软件）以及包含软件的产品。已实施软件的位置（例如本地或云托管）无关紧要。联邦机构开发的软件超出范围，联邦机构免费直接获得的开源软件也是如此。由联邦机构购买的软件捆绑、集成或以其他方式使用的开源软件在范围内。
术语
第 4e 节使用了几个术语，包括“符合性”、“证明”和“人工制品”。由于 EO 14028 没有定义这些术语，因此本指南提供了现有标准和指南中的以下定义：
合格评定（Conformity assessment）是“满足特定要求的证明”。 [ISO/IEC 17000] 在第 4e 节的上下文中，要求是安全的软件开发实践，因此合格评定表明软件生产商已经为其软件遵循了安全的软件开发实践。
证明（Attestation）是“根据决定发表声明，表明已证明满足特定要求”。 [ISO/IEC 17000]
如果软件生产商自己证明它符合安全软件开发实践，这可以通过几个术语来了解，包括第一方证明、自我证明、声明和供应商的符合性声明 (SDoC)。
如果软件购买者证明软件生产者符合安全软件开发实践，这称为第二方证明。
如果独立第三方证明软件生产商符合安全软件开发实践，这称为第三方证明或认证。
人工制品是“证据”。 [改编自 NISTIR 7692] 证据是“是否相信的理由；数据作为证明或确定真假的依据。” [NIST SP 800-160 卷.1] 工件提供安全软件开发实践的记录。
在软件开发过程中将生成低级工件，例如威胁模型、日志条目、源代码文件、源代码漏洞扫描报告、测试结果、遥测或特定软件的基于风险的缓解决策。这些工件可以手动或通过自动方式生成，并由软件生产者维护。
可以通过总结源自低级工件的安全软件开发实践来生成高级工件。高级工件的一个示例是可公开访问的文档，该文档描述了软件生产者用于软件开发的安全实践的方法、过程和流程。
EO 14028 第 4e 节的以下小节使用这些术语：
(ii) 生成并在购买者要求时提供证明符合本节 (e)(i) 小节所述流程的工件；
(v) 当买方要求时，提供执行本节 (e)(iii) 和 (iv) 小节中描述的工具和过程的工件，并公开完成这些操作的摘要信息，以包括对评估和减轻的风险的简要描述；
(ix) 证明符合安全软件开发实践；
换言之，当联邦机构（购买者）购买软件或包含软件的产品时，该机构应从软件生产商处获得软件开发符合政府规定的安全软件开发实践的证明。联邦机构还可能要求软件生产商提供工件，以支持其证明符合第 4e 节 (i)、(iii) 和 (iv) 小节中描述的安全软件开发实践，这些小节在此处列出：
(i) 安全的软件开发环境，包括以下行动：
A. 使用管理上独立的构建环境；
B. 审计信任关系；
C. 在整个企业范围内建立多因素、基于风险的身份验证和条件访问；
D. 记录并最大限度地减少对企业产品的依赖，这些产品是用于开发、构建和编辑软件的环境的一部分；
E. 对数据进行加密；和
F. 监控操作和警报，并对尝试的和实际的网络事件做出响应；
(iii) 采用自动化工具或类似流程来维护受信任的源代码供应链，从而确保代码的完整性；
(iv) 使用自动化工具或类似流程来检查已知和潜在漏洞并进行修复，这些工具应定期运行，或至少在产品、版本或更新发布之前运行；
证明符合安全软件开发实践
NIST 为联邦机构在获取软件或包含软件的产品时定义了以下最低建议。这些建议旨在帮助联邦机构和软件生产商就安全的软件开发工件、证明和一致性进行清晰的沟通。
使用 SSDF 的术语和结构来组织有关安全软件开发要求的交流。这使得所有软件生产商在为联邦机构证明符合性时都可以使用相同的词典。软件生产商可以将他们的安全开发方法映射到 SSDF 的安全软件开发实践或相关的信息参考。
要求证明涵盖作为整个软件生命周期过程和程序的一部分执行的安全软件开发实践。由于当今软件的高度动态性，证明事情是如何在持续的基础上完成的（流程和程序）通常比证明这些流程的一个实例生成的特定软件版本的事情是如何完成的更有价值。对于诸如漏洞披露和响应之类的发布后实践尤其如此，其中可能尚未针对最新版本执行流程。
接受符合 SSDF 实践的第一方证明，除非基于风险的方法确定需要第二方或第三方证明。建议使用第一方证明来满足 EO 14028 的要求。这与 NIST SP 800-161 Rev. 1（第二稿）中的指南一致，该指南在第 3.1.2 节中指出：“有多种可接受的验证和重新验证方法，例如必要的认证、现场访问、第三方党的评估，或自我证明。所需方法的类型和严格程度应与所获得的服务或产品的重要性以及相应的保证要求相称。”
当请求一致性工件时，请求高级工件。软件生产者应该能够将高级工件中总结的实践跟踪到由这些实践生成的相应低级工件。不建议为特定软件版本要求低级工件以满足 EO 14028 的要求，但可能需要满足其他机构的要求。避免低级工件的原因包括：
低级工件仅提供安全软件开发的一小部分的时间快照，而高级工件可以提供有关如何执行安全软件开发的全局视图。
人工制品应满足接收它们的受众的需求，从而以可用的格式为该受众提供必要的信息。了解低级工件需要机构花费大量技术资源和专业知识来分析它们并确定如何在更广泛的安全软件开发实践的背景下考虑它们。
低级工件通常包含知识产权或其他专有信息，或攻击者可用于恶意目的的详细信息，因此接受低级工件可为机构提供额外的敏感信息以保护。
这些最低建议适用于联邦机构采购的本指南范围内的所有软件的证明，它们应该是每个机构流程的一部分。这些建议并非旨在取代联邦机构可能对安全软件开发提出的更严格的要求。
在某些情况下，这些最低限度的做法是不够的。例如，一个机构可能需要更深入地了解特定产品的实践，以便更好地了解该产品将如何影响该机构的网络安全风险。正如 SP 800-161 Rev. 1（第二稿）第 1.4.2 节中所讨论的，要求对实践有更高可见度的机构可能会增加软件生产商的成本，从而可能会增加产品价格。有关这些注意事项的更多信息，请参见 SP 800-161 Rev. 1。
常见问题
以下常见问题解答提供了有关该指南的更多信息。我在哪里可以了解更多关于合格评定的信息？
有关合格评定的更多详细信息，请参阅 NIST SP 2000-01，ABC's of Conformity Assessment； NIST SP 2000-02，联邦机构的合格评定注意事项；和 ISO/IEC 17000:2020 – 合格评定 – 词汇和一般原则。 NIST SP 2000-01 和 SP 2000-02 参考了 ISO/IEC 17000 并引用了其中的几个定义，包括“合格评定”。我在哪里可以了解更多关于第一方认证和供应商符合性声明的信息？
更多信息可从 NIST SP 2000-01、ABC 的合格评定和 ISO/IEC 17050-1:2004、合格评定 - 供应商的合格声明 - 第 1 部分：一般要求中获得。NIST 是否有关于网络安全供应链风险管理 (C-SCRM) 的额外资源？
是的，请参阅 NIST 的 C-SCRM 项目网站以获取所有资源的链接。 NIST 主持的联邦 C-SCRM 论坛就是一个例子。该论坛促进联邦机构之间的协作和 C-SCRM 信息交换，以提高联邦供应链的安全性。 NIST C-SCRM 指南的示例包括 SP 800-161，联邦信息系统和组织的供应链风险管理实践和 SP 800-161 Rev. 1（第二稿），系统和组织的网络安全供应链风险管理实践。EO 14028 的任何其他部分是否与本指南相关？
是的。第 4n 节引用了第 4k 节，这在本指南的介绍中进行了讨论。以下是第 4n 条的文本：（第 4n 条）在本命令发出之日起 1 年内，国土安全部部长与国防部长、司法部长、OMB 主任和行政长官协商OMB 内的电子政府办公室应向 FAR 委员会推荐合同语言，要求可供机构购买的软件供应商遵守并证明遵守根据本节 (g) 至 (k) 小节发布的任何要求.机构可以将此指南应用于联邦机构开发的软件吗？
是的，机构可以选择与基于机构的软件开发人员一起实施这些建议，以帮助评估与其软件相关的安全风险，并就其实施和使用做出基于风险的决策。代理机构能否将本指南应用于他们免费直接获得的开源软件？
是的，机构可以选择使用来自提供此类内容的开源软件生产商的证明和工件。这可以帮助机构评估与软件相关的安全风险，并就其实施和使用做出基于风险的决策。-
SSDF 如何帮助解决 EO 14028 的第 4e 节？
下表将每个第 4e 小节映射到有助于解决每个小节的 SSDF 实践和任务。有关每个 SSDF 实践和任务的更多信息，请参阅 SP 800-218。
与 EO 14028 小节相对应的 SSDF 实践
image.png
image.png 我为我的机构承担与软件采购相关的职责（例如，采购和采购官员、技术专业人员）。为了符合 EO 14028 的第 4e 节，我应该向软件生产商提出哪些关于其安全软件开发实践的要求？
来自联邦机构的软件购买者应要求软件生产商提供一致性声明，证明他们的软件开发过程遵循 SSDF 实践，包括常见问题解答 #7 中第 4e 节中特别提到的那些。一致性声明应包括：
软件生产商的名称
对声明所指产品的描述。 （注意：最好在公司或产品线级别而不是按产品来解决这个问题。）
一份声明，证明软件生产者遵循常见问题解答 #7 中适当且适用的安全开发实践和任务
作为主要联系人的个人的姓名和职务，如果购买者要求，可以提供与 EO 14028 第 4e(i)、4e(iii) 和 4e 节相关的安全软件开发活动生成的工件（ iv)我是一名软件生产者，我想将我的产品卖给联邦机构。我需要向他们提供哪些有关安全软件开发的信息？
您应该提供一致性声明，FAQ #8 中对此进行了描述。此外，您可以选择超过 EO 14028 第 4e 节的要求，方法是提供与 SSDF 实践和任务相关的安全软件开发活动摘要的参考或 URL，包括基于风险的和缓解措施。此处发布了一个示例模板，以便在记录活动时重复使用。我是一名软件经销商。我如何向购买者表明我转售的软件符合 EO 14028 第 4e 节的要求？
对于您转售给软件购买者的每个软件，您应确保您可以提供对软件生产商一致性声明的参考，如常见问题解答 #8 中所述。
