12.1 新兴的努力、法规和要求

在新兴法规和要求方面，现在应该清楚的是，世界各国政府都意识到了软件对其机构、组织和整个社会的重要性。软件已与现代社会的几乎每个方面密不可分，从简单的日常休闲活动到最关键的基础设施和国家安全，无所不包。在本书中，我们引用了民选官员、国防领导人和技术巨头的证词，强调软件对现代社会每个关键行业和部门的重要性。

政府终于开始承认社会对软件的依赖，并开始进行投资，将开源软件 (OSS) 视为公共产品，因为它遍布现代社会的各个方面。德国最近努力推出主权技术基金来支持 OSS (https://sciencebusiness.net/news/germany-launch sovereign-tech-fund-secure-digital-infrastructure)。他们的领导层评论了 OSS 在现代数字基础设施中的重要性，尽管它作为一个生态系统很脆弱。

在英国，一个名为 OpenUK 的组织于 2022 年发起了“开源软件安全之夏”活动。参与该计划的领导人强调了现代国家关键基础设施正在 OSS 上构建的现实。由于国家关键基础设施对 OSS 的依赖，这项工作的重点是保护和维护 OSS 的必要性 (https://openuk.uk/launching-the-openuk-summer-of-open-source-software-security)。

另一项值得一提的立法是“2022 年保护开源软件法案”，该法案于 2022 年 9 月提交给美国参议院。该法案规定了网络安全信息安全局 (CISA) 在 OSS 安全方面的职责。CISA 的职责包括进行行业推广和参与、支持联邦保护 OSS 的努力以及与非联邦实体协调以确保 OSS 的长期安全。 CISA 的任务是发布一个框架，该框架将包括政府、行业和 OSS 社区本身，重点是保护 OSS 以及与此相关的最佳实践。该法案还包括关键基础设施评估研究和试点的语言，以确定 OSS 在美国关键基础设施中的作用 (www.congress.gov/bill/117th-congress/senate-bill/4913)。

虽然其中一些参考资料以及我们之前讨论过的国防部 (DoD) OSS 备忘录等项目可能让人觉得对使用和管理 OSS 的推动和兴趣正在加速，但来自战略与国际研究中心 (CSIS) 等来源的研究于 2023 年初发布，指出美国政府几十年来一直在发布与 OSS 相关的政策。该报告引用了 1999 年至 2022 年期间世界各国政府的 669 项 OSS 政策举措（见图 12.1）。

尽管如此，OSS 的使用加速（在我们讨论的 97% 的代码库中都有出现）加上对软件供应链的攻击加速，正在激发政府和行业对保护软件供应链的兴趣，并且这种兴趣将继续下去。

在美国，我们看到政府在保护软件供应链方面采取了巨大的行动。虽然各种努力正在进行中，但行政命令 (EO) 14028“改善国家网络安全”的发布无疑加速了这一现实。行政命令第 4 节“加强软件供应链安全”专门针对这一挑战，并要求美国各地的各政府实体制定指导、要求等，以应对整个软件供应链的风险。 Figure 12.1
Source: www.csis.org/analysis/governments-role-promotingopen-source-software, Center for Strategic & International Studie

该行政令的要求之一是，美国国家标准与技术研究所 (NIST) 需要制定“指导方针，确定增强软件供应链安全性的实践”。NIST 继续更新其安全软件开发框架 (SSDF) (https://csrc.nist.gov/Projects/ssdf)，并根据行政令提供专门的软件供应链指导 (www.nist.gov/system/files/documents/2022/02/04/ software-supply-chain-security-guidance-under-EO-14028-section-4e.pdf)。

基于该指导方针，管理和预算办公室 (OMB) 编写了一份备忘录，题为“通过安全软件开发实践增强软件供应链的安全性”(M-22-18)。这份备忘录提到了美国政府对技术和数字产品的依赖，以及他们面临的持续威胁，这些威胁可能会阻碍政府提供公众所依赖的服务的能力。

备忘录要求美国联邦机构在机构信息系统上使用第三方软件或影响机构数据的软件时，遵守前面提到的 NIST 指导原则。该指导原则适用于备忘录发布之日起机构使用的所有软件，不仅包括新采购，还包括对现有第三方软件使用的任何重大版本更改。

值得注意的是，该备忘录特别排除了机构开发的软件，这当然引起了人们对所述软件安全性的担忧，并要求机构内部采取措施确保进行适当的安全软件开发活动。联邦机构远不能免受安全事件的影响，例如2015年发生的违反人事和管理办公室（OPM）的事件，暴露了2100多万美国人的数据。

备忘录指出，各机构只能使用能够自我证明符合上述NIST指南的软件生产商提供的软件。它呼吁各机构的首席信息官和首席采购官确保满足这些要求。软件生产商必须能够以合规声明的形式提供自我证明，并且这些自我证明必须由机构根据备忘录的要求为所有第三方软件获得。

备忘录还强调了将其证明纳入其产品组合的必要性，以使所有采购机构能够重复使用证明，这可以提高美国联邦生态系统的效率和数据共享。由于软件生产商可能无法完全满足SSDF和NIST软件供应链指南的要求（无论是最初还是可能永远），备忘录还允许使用所谓的行动计划和里程碑（POAM）。

POAM允许软件供应商记录其合规证明中的差距，解释缓解控制/措施、计划关闭日期等。这是一种存在于其他合规计划中的机制，如联邦风险和授权管理计划（Fed RAMP）和NIST风险管理框架（RMF）下的内部机构系统授权。

供应商需要提供有关认证所涵盖的组织和产品的详细信息，然后记录其与安全开发指南的一致性，并将其记录在标准化的自我认证表格中。如果服务或软件被认为是关键的，并且风险有保证，则机构可以选择请求第三方评估。这些第三方评价可能包括美联储RAMP第三方评定组织（3PAO）等团体。

在自我评估和更有可能的3PAO的情况下，值得指出的是，有可能减少联邦政府可以合作的可用软件供应商的数量。如前所述，在讨论联邦RAMP时，联邦RAMP市场(https://marketplace.fedramp.gov/#!/products?sort=productName）是美联储RAMP授权云服务的上市地，在撰写本文时，联邦政府可以使用大约300项授权云服务，尽管该市场已经存在了十年，在更广泛的商业消费市场上有数以万计的云提供商。

因此，尽管这些第三方采购订单的努力是出于善意的，可能会确定更安全的供应商和产品，但由于法规遵从性带来的高昂成本和要求，它们也限制了可用供应商和产品的数量。

许多人认为，在更广泛的风险讨论中，应该考虑失去创新供应商和解决方案的风险，而不是孤立于严格的网络安全。这意味着无法创新和现代化的业务/任务风险也被纳入等式。也就是说，正如我们所提到的，一些领导人，如Joshua Corman，也主张“减少更好的供应商”，试图拥有一个由可靠和安全的产品和组件组成的更安全的供应链。当然，这两种论点都有其优点，并且会因个人和组织的风险承受能力而异。

除了自我证明或由第三方评估是否符合NIST软件供应链和安全开发指南外，各机构还可能在其招标要求中要求软件材料清单（SBOM），特别是如果它被视为NIST定义的“关键软件”，我们之前已经讨论过，并在另一份名为“通过增强的安全措施保护关键软件”的OMB备忘录（www.whitehouse.gov/wp-content/uploads/2021/08/M-21-30.pdf）中记录了这一点。供应商提供的SBOM必须符合美国国家电信和信息协会（NTIA）定义的SBOM格式，并包括第4章“软件材料清单的兴起”中讨论的美国国家电信与信息协会定义的最低要素。

与自我证明非常相似，OMB备忘录强调了跨机构互惠/重复使用SBOM的必要性，以避免机构和供应商的重复工作。基于使用SBOM的潜力，机构可能需要其他工件，如与代码相关的漏洞和完整性输出以及参与漏洞披露计划的证明。联邦能源管理委员会（FERC）的领导人也开始表示希望更新与保护电力公司和其他能源部门实体相关的关键基础设施保护标准。这些愿望包括呼吁提高软件透明度，并指出对自我证明的担忧，而不是像SBOM这样的人工制品，SBOM提供了易受攻击的软件组件的机器可读证据，或者缺乏这些证据 (www.nextgov.com/cybersecurity/2022/12/ferc-chairman-wants-update-cybersecurity-requirements/380666).。

根据爱迪生电气研究所等组织的文件，这似乎是联邦能源管理委员会和北美电力可靠性公司（NERC）等组织的方向，该研究所于2022年10月发布了《解决网络安全供应链风险的模块采购合同语言3.0》。本文件列出了R.1.2.5“建议的EEI合同语言”的要求，该要求侧重于硬件、固件、软件和补丁的完整性和真实性。第（e）节特别规定，“承包商应为生产的（包括许可的）产品提供软件材料清单，其中包括组成组件的组件和相关元数据列表”（www.eei.org/-/media/Project/eei/Documents/Issues-and-Policy/Model--Procurement Contract.pdf）。

软件供应链安全和SBOM出现的另一个地方是美国《2023年国防授权法案》的初始版本和语言。在题为“国土安全部软件供应链风险管理”的第6722节中，该文本要求在提交投标书时包括一份材料清单，并证明提交的材料清单上列出的每个项目“没有影响最终产品或服务安全的所有已知漏洞或缺陷”。它要求使用NIST的国家漏洞数据库（NVD）等来源，我们已经与其他跟踪OSS和第三方软件安全漏洞和缺陷的数据库一起讨论过该数据库。

许多业内人士立即用这种语言指出，拥有无漏洞软件是不切实际的；然而，值得一提的是，该语言还允许通知计划，以缓解、修复和解决BOM中确实存在的每个安全漏洞或缺陷。行业抵制的一个显著例子来自数字创新联盟发布的一封信，该组织代表AWS、谷歌云和VMware等行业科技巨头。这封信请求国会“将SBOM语言从NDAA中删除，并给行业和机构更多的时间来开发更好地保护国家网络安全供应链的解决方案。”对这封信感兴趣的人可以在这里找到：https://alliance4digitalinnovation.org/wp-content/uploads/2022/10/NDAA-FY23-letter-Final.pdf。虽然《2023年国防授权法案》（NDAA）的早期版本确实包括SBOM的语言和进一步的软件供应链透明度，但行业游说和担忧似乎占了上风，2023年NDAA的最终文本中删除了SBOM和漏洞语言。（见www.congress.gov/117/bills/hr7776/bills-117hr7776enr.pdf）。

SBOM和软件供应链语言是否能重新进入未来一年的美国NDAA版本，还有待观察。也就是说，正如我们在其他地方所讨论的那样，国防界的各个实体，如美国陆军，正在围绕SBOM做出努力，通过信息请求（RFI）和其他合同途径向行业发出信号，表明他们致力于追求软件透明度

除了美国联邦范围内的新要求外，国防部的特定部门也表示打算大规模采用SBOM，不仅用于漏洞管理，还用于采办。2022年末，美国陆军发布了一份RFI，旨在寻求行业对“软件材料清单（SBOM）的获取、验证、摄入和使用以及密切相关的事项”的反馈。RFI承认，美国陆军使用数十万个软件组件来实现任务结果。这与我们在中提到的早期观点相呼应，这些观点是由联邦、军事和行业高级领导人提出的，他们强调了软件在未来军事冲突中的作用。美国国务院还表示，打算将SBOM作为其可交付成果合同活动和服务的核心组成部分。

2022年7月，国务院发布了一份征求建议书草案，作为其收购计划的一部分。该合同车辆名为“Evolve”，预计价值高达80亿至100亿美元。在第H.14.7节中，对“材料清单”有一项具体要求，要求承包商以行业标准格式（如软件包数据交换（SPDX）或Cyclone DX）提供SBOM，以捕获软件中包含的各种组件。交付的SBOM必须符合美国国家电信和信息管理局定义的最低要素，并且要求规定这些要素适用于合同中的所有任务订单。

所需频率被定义为与软件及其组件构成的任何更新相关(https://sam.gov/opp/bee1b04eda40442bbdfbca21774d55ce/view). 围绕软件透明度和SBOM的势头不仅限于美国。在欧盟（EU），2022年提出了一项名为《欧盟网络弹性法案》的法案，作为对具有数字元素的产品的网络安全要求的监管。它旨在确保在整个欧盟范围内使用更安全的硬件和软件产品(https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act）。

《网络复原法案》指出，2021年全球网络犯罪的年度成本估计为5.5万亿欧元。该法案指出，充斥漏洞和用户无法充分获取信息的产品网络安全性差的主要问题是了解哪些产品是安全的或它们的安全程度。该法案的主要目标是通过降低漏洞能力，为具有数字元素的安全产品创造发展心理条件，并让制造商在产品的整个生命周期中解决安全问题，让用户能够对具有数字元素产品的安全性做出明智的选择。

在《网络弹性法案》的文本中，特定的语言要求供应商使用SBOM来识别和记录产品中包含的组件。该法案规定，“为了便于漏洞分析，制造商应识别和记录具有数字元素的产品中所包含的组件，包括起草软件材料清单。”该法案特别要求供应商识别产品中易受攻击的第三方组件。