软件透明度

我们中的许多人都会记得2021年12月，我们在亲戚家的客房里，弯腰驼背地坐在小型旅行笔记本电脑前，应对 Log4j 危机。Apache 软件基金会开发的开源 Java 日志框架中的这个漏洞被官方指标和软件专家评为严重漏洞。无论是通过补丁还是其他内联缓解措施，它都不是难解决的漏洞。然而，大多数组织面临的真正挑战是定位漏洞：这个该死的东西在哪里？它深藏在无数现代应用程序的供应链中，软件的生产者和用户根本没有可用的路线图来聚焦错误。

安全的难点是识别漏洞和发现潜入我们供应链的攻击者。相反，我们发现，了解我们制作的软件中有什么还需要大量的工作。

追踪软件中的内容的想法并不新鲜。自1990年代以来，学术界一直在谈论它。2000年代，软件世界的不同角落都在讨论早期的想法。未能考虑到开源许可证，许多大公司陷入了严重的法律麻烦。收集和利用供应商数据是重工业质量革命不可或缺的一部分，这场革命可以追溯到20世纪40年代末，戴明和“丰田革命”启发了几十年后的DevSecOps和现代软件革命。

确实，我们的软件供应链透明度太低，这真是太不可思议了。我经常用 Twinkie 来举例（由 Audra Hatch 和 Josh Corman 首次提出），提出这样一个问题：为什么我们对不可生物降解的零食的了解比对公司、政府和关键基础设施中运行的软件的了解更深入？

在我们开始了解如何实施软件物料清单 (SBOM) 的过程中，花点时间了解一下为什么我们一开始没有这种能力、我们如何开始取得进展以及这种透明度的价值是什么是很有用的。很少有组织愿意分享，原因有些不那么令人高兴，包括不想面临前面提到的开源许可证合规风险。坦率地说，许多组织不想承认技术债务的规模，也不想承担建立基本内部基础设施和流程来跟踪其依赖关系数据的成本。此外，应该承认，开始这段SBOM之旅并不容易——它需要汇集技术专业知识、对多样化软件生态系统的理解以及对激励措施的重视。但在过去五年中，已经取得了巨大的进展。

我们首先需要的是SBOM的共同愿景。许多专家都有一个大致的想法；这些想法在2018年至2020年期间在美国国家电信和信息管理局 (NTIA) 召集的开放、国际“多利益相关方流程”中进行了讨论和完善。社区定义了 SBOM 的基本知识并列出了其核心用例。然后，我们需要一种机器可读的方式来在整个供应链中传达这些信息。幸运的是，软件界的一些人走在我们前面，所以我们能够调整 Linux 基金会的软件包数据交换 (SPDX) 和开放全球应用安全项目 (OWASP) 的 CycloneDX 以满足这些模型。

下一步是创建工具来生成和使用这些机器可读的数据。软件界在普遍实施 SBOM 方面取得了巨大进展，整个生态系统中都出现了新的工具。我们看到更多特定行业和技术的工具，因为工业控制系统 (ICS) 和运营技术 (OT) 固件领域的需求与传统企业软件有所不同，而传统企业软件与云原生领域相比具有独特的功能和集成。生成工具已经开始成熟，新工具不断涌现，以帮助组织在运营和战略上利用这些数据。（这是我工作中的一项福利，首先是在 NTIA，现在在网络安全和基础设施安全管理局 [CISA]，我会与初创企业和开源创新者会面，寻找满足整个软件市场实际需求的方法。）

当然，除了技术和市场之外，三脚架的第三条腿就是政府。近年来，美国政府一直致力于确保供应链安全，我们在世界各地的合作伙伴对此表现出浓厚的兴趣，并进行了政策创新。2021 年 5 月，SBOM 进入了网络安全政策的主要阶段，当时总统关于改善国家网络安全的行政命令 (EO) 宣布，除其他事项外，美国政府的供应商将向购买者提供 SBOM。在本书付印时，预计这些法规的最终细节将公布。这与美国食品药品监督管理局 (FDA) 对美国医疗器械的监管、其他美国监管机构的活动以及世界各地出现的拟议法规相一致。

因为这本书已经在您的手中或者屏幕上，所以您可能已经认识到整个软件供应链透明度的价值。但您可能必须说服其他人，在您的组织或软件生态系统中宣传，争取预算，或说服您的供应商共享数据。尽管信息安全供应商通常会夸大其词，但SBOM中的“SB”并不代表“银弹”。SBOM 是一个数据层。我们仍在构建工具和流程，将这些数据转化为情报，并最终付诸行动。就像公共漏洞和暴露(CVE)标识符实际上并不能修复您网络上的漏洞一样——而 CVE 现在是我们的全球漏洞生态系统不可或缺的一部分——因此，SBOM 也将成为软件安全和质量领域不可或缺的一部分。

软件供应链中的透明度有助于整个软件生命周期。对于软件开发人员来说，SBOM 是一种强大的工具，可以帮助我们了解流程，并确保我们不会构建设计不安全或存在已知风险的产品。对于选择或购买软件的人来说，为什么要使用不了解他们交付的产品的供应商？为什么我们可能会采用在使用前就已过时的软件？对于操作软件的人来说，如果没有SBOM，我们如何应对新发现的风险或为基于寿命终止或支持终止的软件构建的系统制定计划？当然，我们中的许多人都担任这三个角色。随着 SBOM 变得越来越普遍，不可避免地会发现和构建这些数据的更多用途。

软件透明度运动做出了许多令人难以置信的贡献，他们倡导 SBOM 的理念、构建工具并讨论重要的边缘案例。作者 Hughes 和 Turner 出色地捕捉了这些进步（包括他们自己的一些进步），并解释了从SBOM理念到SBOM实践的细节和细微差别。虽然我希望世界各地的从业者都能拿起这本书，为他们的组织和客户取得令人难以置信的成功，但我矛盾的是，我希望这本书的关键价值实际上是短暂的。随着我们中越来越多的人开始使用作者如此有益地设想的可互操作自动化类型来构建和管理我们的软件，并遵循他们制定的路线，SBOM 将不再是新奇和闪亮的，而是成为所有软件制造、销售和使用过程中自然而然的自动化部分。

到那时我们就可以迎接下一个挑战了。

Allan Friedman 博士 Allan Friedman 是网络安全和基础设施安全局的高级顾问和战略家。他负责协调围绕软件物料清单 (SBOM) 的全球跨部门社区工作。他曾担任 NTIA 的网络安全计划总监，领导漏洞披露、SBOM 和其他安全主题的开创性工作。在加入联邦政府之前，Friedman 曾在哈佛大学计算机科学系、布鲁金斯学会和乔治华盛顿大学工程学院担任著名的信息安全和技术政策学者十多年。他是畅销书《网络安全和网络战：每个人都需要知道什么》（Cybersecurity and Cyberwar: What Everyone Needs to Know）的合著者，拥有斯沃斯莫尔学院计算机科学学位和哈佛大学博士学位。

引言

我们生活在一个软件触及社会方方面面的时代。软件涉及从关键基础设施、数字商务到国家安全的各个方面。事实上，截至本文撰写之时，世界经济论坛 (WEF) 预测，到2022年底，全球60%的国内生产总值 (GDP) 将与数字系统挂钩 (www3.weforum.org/docs/WEF_Responsible_Digital_Transformation.pdf)。然而，同一份 WEF 报告发现，只有 45% 的人信任推动现代经济和社会发展的技术。这种缺乏信任的部分原因可以追溯到多年来发生的重大数字数据泄露事件以及软件供应链长期存在的透明度问题。

软件供应链攻击并非新现象，对代码信任的担忧可以追溯到 1984 年 Ken Thompson 著名的“对信任的反思”论文，Thompson 在论文中讨论了无法信任非自己编写的代码的问题。虽然从外部来源使用的代码可能不可信或完全是恶意的，但近年来随着软件供应链攻击的加速，这种说法的表现形式只会更加严重。出于各种动机的恶意行为者已经意识到，他们不仅可以针对单个实体，还可以破坏广泛使用的软件（无论是专有软件还是开源软件），并对整个消费者生态系统产生连锁影响。

随着这些事件的加速，组织已加大努力，以了解软件供应链的挑战、复杂性和事件，并实施了安全措施以减轻相关风险。云原生计算基金会 (CNCF) 编制了一份自 2003 年以来的供应链入侵目录 (http://github.com/cncf/tag-security/tree/main/supply-chain-security/compromise)。该目录涵盖了各种方法造成的供应链入侵，例如利用开发人员工具、开发人员疏忽、恶意维护者，甚至攻击链（即多个入侵链在一起以发起攻击）。

在本文讨论的一些里程碑式的案例（如 SolarWinds、Log4j 等）之前，美国国家情报总监办公室 (ODNI) 于 2017 年发表了一篇论文(http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf)，称其为软件供应链攻击的分水岭之年。该文件列出了 2017 年发生的几起重大软件供应链攻击，这些攻击不仅影响了商业领袖，还影响了支持美国政府的组织。其中一些攻击来自国家行为。ODNI 论文指出，许多软件开发和分销渠道缺乏适当的安全性。ODNI 还描述了一些恶意行为者由于某些组织的网络健康状况较好而向上游发展。对于恶意行为者来说，从上游大规模攻击下游软件消费者通常比针对单个组织更有效率。一些软件供应链攻击可能是无差别的，针对任何消费者，而另一些攻击可能会在知道某些下游消费者的情况下寻找特定的上游软件生产商。

不可否认，数字化系统带来了前所未有的效率、生产力和创新。然而，同样是这些数字化连接软件赋能系统，现在已经产生了人们才刚刚开始理解的系统性风险。复杂的相互依赖关系会增加系统性风险，而不难理解，现有的软件生态系统和数字系统并不复杂。恶意行为者也意识到了针对软件供应链的价值，技术研究行业领导者 Gartner 预测，到 2025 年，约有 45% 的组织将遭受软件供应链攻击。一些人认为这个估计可能偏低，Sonatype 等组织发布的 2022 年报告 (http://sonatype.com/state-of the-software-supply-chain/introduction) 显示，过去三年来，软件供应链攻击每年增长 742%。

随着引人注目的软件供应链攻击事件增多，我们现在看到政府和私营部门组织做出了雄心勃勃的努力。在美国，白宫发布了第 14028 号行政命令“改善国家网络安全”（http://whitehouse.gov/briefing room/presidential-actions/2021/05/12/executive-order-on-improving the-nations-cybersecurity），其中有一节专门用于加强软件供应链安全。该命令包括一个关于组织（包括联邦政府）使用的软件普遍缺乏透明度的部分。

在本书中，我们将更详细地讨论相关的软件供应链事件、行业活动、新兴解决方案以及在保护软件供应链方面仍然存在的重大挑战。

供应链安全的重要性

在深入探讨软件供应链威胁以及新兴框架和指导的具体细节之前，我们应该首先讨论一下为什么这是一个影响现代社会方方面面的关键问题。如前所述，数字平台正迅速影响全球一半以上的经济产出。这些数字平台和系统的动力来自软件，其中大部分是开源软件 (OSS) 组件。OSS 的使用在现代软件生态系统的大部分领域中无处不在。最近的一项研究 (http://synopsys .com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf) 发现，97% 的现代软件代码库包含 OSS，不仅包含 OSS，而且超过一半的代码库都是 OSS。

OSS 现在已从根本上融入到社会上一些最关键的基础设施和系统中。研究表明，交通运输、金融服务和制造业等行业的 90% 以上的代码库都包含 OSS。电信和医疗保健等行业也存在同样的趋势。在美国，国防部 (DoD) 发布了一份题为“软件开发和开源软件”的备忘录 (http://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev OpenSource.pdf)。该备忘录是其更广泛的软件现代化战略 (https://dodcio.defense.gov/portals/0/documents/library/softwaredev-opensource.pdf) 的一部分，称 OSS 是“软件定义世界的基石，对于更快、更灵活地交付软件至关重要，这是其软件现代化工作的关键。”软件现代化战略指出，“安全、快速地交付弹性软件功能的能力是一种竞争优势，将决定未来的冲突。”

正如国防部所强调的那样，创新使用软件不仅对国家安全目的至关重要，而且对整个社会也至关重要。在美国众议院科学、空间和技术委员会举行的题为“保护数字公共资源：改善开源软件生态系统的健康”的听证会上 (www.congress.gov/event/117th-congress/house-event/114727)，多位民选官员和行业专家证实了弹性 OSS 生态系统的重要性。国会议员比尔·福斯特 (Bill Foster) 称 OSS 是“数字生态系统的隐藏劳动力”。国会女议员海莉·史蒂文斯 (Haley Stevens) 表示，“充满活力的开源生态系统是美国竞争力和增长的引擎。” 2022 年白宫主办的开源软件安全峰会强调，大多数主要软件包都包含 OSS，包括国家安全界使用的软件 (www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout of-white-house-meeting-on-software-security)。

许多人开始认为 OSS 是社会中如此重要的一个方面，因此也应该被视为关键基础设施，将其与州际高速公路、电网、水处理和其他基本社会基础设施进行比较 (http://hbr.org/2021/09/the-digital-economy-runs-on-open source-heres-how-to-protect-it)。该论点还声称，将 OSS 指定为关键基础设施将带来额外的资源、跨部门协调、公众意识和对话。

尽管 OSS 无处不在，并且对国家安全、商业行业和社会都很重要，但可以说，它的安全问题一直被忽视。在一篇题为“开源安全：数字基础设施如何建立在纸牌屋上”（http://lawfareblog.com/open-source-security how-digital-infrastructure-built-house-cards）的文章中，研究员 Chinmayi Sharma 指出，开源软件及其相关漏洞普遍存在于所有关键基础设施领域，由于缺乏资源和激励措施，对社会构成了系统性风险。

恶意行为者也注意到了这种缺乏关注的情况，一些研究表明，我们已经看到软件供应链攻击在 2021 年同比增长了 650%。这并不是一个独特的现象，2020 年的增长幅度超过 400%。这些急剧的增长也反映在云原生计算基金会 (CNCF) 的供应链攻击目录等来源中。

软件供应链攻击的这种上升也得到了大西洋理事会等组织的研究支持，其研究报告名为“破坏信任：不安全软件供应链中的危机阴影”白皮书 (http://atlanticcouncil.org/wp-content/uploads/2020/07/Breaking-trust-Shades of-crisis-across-an-insecure-software-supply-chain.pdf)。他们的研究表明，软件供应链攻击急剧增加，第三方应用程序和 OSS 是主要攻击媒介。该报告记录了过去十年中发生的 100 多起软件供应链攻击，攻击媒介多种多样，例如劫持更新、恶意依赖项、受损软件开发平台和账户泄露。这不仅表明恶意行为者持续且越来越多地使用软件供应链攻击，而且由于现代软件生态系统的复杂性，恶意行为者可以使用多种攻击媒介来危害下游软件消费者。正如报告所示，这些攻击不仅影响了数百万用户，而且还迅速成为现代数字社会中民族国家冲突和参与的标准化方法。国家情报总监办公室 (ODNI) 在其 2017 年出版物 (http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf) 中也强调了恶意国家行为者的关注。

受到攻击的不仅仅是 OSS 组件。恶意行为者还瞄准托管服务提供商 (MSP)、云服务提供商 (CSP) 和其他几个实体，所有这些实体在现代软件生态系统中都扮演着不同的角色。

恶意行为者已经意识到针对软件供应链组件或供应商并造成巨大的下游影响的成果，这比单独针对相同数量的受害者更有效率。在这本书中，我们将讨论从软件供应链威胁的背景、值得注意的事件、新兴指导、技术能力和最佳实践到我们未来的发展方向等内容。

本书内容

本书涵盖了与软件透明度和软件供应链安全相关的新兴讨论和挑战的相关主题。其中包括软件供应链威胁的详细背景、现有方法以及应对这一指数级相关威胁的创新工具、技术和流程的兴起。讨论将包括这些威胁对社会几乎所有方面的影响，以及为各利益相关者提供如何应对这些威胁的实用指导。它将涵盖新兴法规及其影响，以及对我们作为一个行业和社会未来走向的预测。

第 1 章：软件供应链威胁背景本章概述了核心主题，例如攻击者的动机和软件供应链攻击的剖析以及相关的里程碑案例。
第 2 章：现有方法 - 传统供应商风险管理本章回顾了现有的软件安全方法，例如传统供应商风险管理、应用程序安全模型以及哈希和代码签名等方法。
第 3 章：漏洞数据库和评分方法本章讨论现有和新兴的漏洞数据库，以及用于对软件和应用程序中的漏洞进行评分和优先级排序的常用方法。
第 4 章：软件物料清单的兴起本章讨论了 SBOM 概念的起源，包括早期的失败和成功以及为其成熟做出贡献的美国联邦和行业组织。
第 5 章：软件透明度的挑战本章重点介绍与软件透明度相关的挑战，例如开源代码和专有代码以及固件和嵌入式软件之间的差异。
第 6 章：云和容器化本章回顾了 IT 的发展，包括云和容器化，以及软件即服务 (SaaS) 领域中与软件透明度相关的复杂性。本章还介绍了与 DevSecOps 相关的工作。
第 7 章：现有和新兴商业指南本章讨论了公共和私营部门组织提供的与软件透明度和软件供应链安全相关的现有和新兴商业指南。
第 8 章：现有和新兴政府指南本章讨论了政府部门提供的与软件透明度和软件供应链安全相关的现有和新兴政府指南。
第 9 章：运营技术中的软件透明度本章讨论了与软件透明度和运营技术 (OT) 相关的一些独特方面以及对更广泛的软件供应链工作的影响。
第 10 章：供应商实用指南本章重点介绍软件供应商的实用指南，以帮助他们满足新兴指南和最佳实践，并促进他们在加强软件供应链安全方面的作用。
第 11 章：消费者实用指南本章为软件消费者提供实用指南，包括是否真的需要 SBOM、如何处理它以及如何完善组织的软件供应链风险管理工作。
第 12 章：软件透明度预测本章涵盖了未来软件透明度的预测，包括新兴法规及其对更广泛市场的影响、有前景的新兴技术，以及我们作为一个行业和社会的未来发展方向。

目标读者

本书将使各种技术和网络安全专业人士受益，例如首席信息安全官 (CISO)、首席技术官 (CTO)、高级技术和安全领导者、安全工程师和架构师、软件开发人员和开源软件爱好者。它还将使关注安全软件采购和采购的采购专业人士和旨在了解新兴软件供应链指导和要求的审计专业人士受益。对软件和社会相关的最佳实践和威胁感兴趣的研究人员和政策制定者也将受益。

第一章软件供应链威胁的背景

本章概述了核心主题，例如攻击者的诱因、软件供应链攻击的剖析以及相关的里程碑式案例。

第一章软件供应链威胁的背景

1.1 攻击者激励因素

供应链攻击规避了传统的外围防御，使其对攻击者非常有吸引力。组织在防火墙、入侵防御和访问控制方面投入了大量资金。这些保护措施是针对直接针对组织基础结构的“推送”式攻击的防御措施。供应链攻击助长了一种更像是“拉动”的场景，即信息技术（IT）的合法用户故意请求一次恶意软件更新，从而破坏其组织。由于请求源自受信任的用户，并且来自公司组织内部，或者是已通过第三方风险管理流程评估后的受信任实体，因此这个更新是认为可信的。结果看起来是组织自己伤害了自己。

在探索防御攻击所需的控制措施时，仅考虑单层架构作为有效的防御措施是不够的。就像网络基础设施管理员意识到他们需要监控出站流量或实施基于主机的控制一样，这种向纵深防御的转变，尤其是跨边界，至关重要。出于各种原因，包括云、移动、社交媒体和现代应用程序基础设施，边界的概念也不断拓展。它不再是一个静态的边界，而是需要被视为信任区域之间的隔离层，无论它们是位于网络边缘、还是作为应用程序或访问控制机制内的逻辑屏障。因此，我们的控制和由此产生的威胁建模必须考虑整个攻击面，并探索每个交互点和信任关系。

供应链攻击也能起到力量放大器的作用。通过识别关键依赖关系或广泛使用的软件，攻击者可以将恶意代码注入任何环境，然后利用该代码。这种情况屡见不鲜，类似于水坑式攻击的概念，攻击者入侵目标群体使用的广泛使用的网站，例如工业控制系统 (ICS) 集成商使用的可编程逻辑控制器 (PLC) 网络论坛。如果攻击者可以入侵访问论坛的每个用户，理论上他们就可以访问这些集成商工作的任何关键基础设施实体。同样，这些集成商使用的任何被入侵的软件都可能将不必要的恶意功能引入安装该软件的环境中，即使在这些顾问转入下一个项目很久之后。

所有这些都意味着软件供应链攻击对攻击者来说非常有利可图。网络间谍活动有一个经济因素，它极大地受益于可重复使用的漏洞和供应链攻击的低入门成本。此外，许多最近的攻击都结合了通过软件供应链部署的勒索软件，这不仅使攻击变得容易，而且为勒索软件运营商带来了直接的经济收益，并让那些担心业务中断的组织越来越担心

第一章软件供应链威胁的背景

1.2 威胁模型

威胁建模是一个经常被谈及的主题，但根据作者的经验，大多数组织很少在实践中执行。作为一个行业，我们经常以相当通用的方式讨论威胁，而从未探索正确建模这些威胁所需的软件或系统的背景。然而，这些活动的核心是攻击面（交互点）的定义，以及对可能出现的问题的探索。

为了确保提供最大的清晰度，我们将定义几个关键术语：

威胁威胁是一种会造成不良后果的负面事件。威胁可能是自然发生的、本质上是良性的，也可能是明显的恶意行为。例如，您企业的计费系统无法捕获交易条目，或者数据中心被龙卷风摧毁。

威胁代理 威胁代理是导致威胁发生的实体。例如，黑客活动分子、恶意内部人员、心怀不满的业务合作伙伴、受到攻击的顾问，甚至是天气模式。人们注意到，威胁归因经常是错误的，对攻击模式的特定威胁代理的假设可能会导致对保护特性的错误假设。例如，如果您认为一个容易受到勒索软件攻击的国家可能是威胁代理，但您却面临着一个更专注于间谍活动的威胁代理，这会如何改变您的安全态势？实际的原产国是否重要，还是会造成不当偏见？

威胁行动 这是威胁主体采取的行动，最终导致威胁发生。例如，威胁主体（如黑客活动分子）可能会贿赂您的系统管理员重新配置计费系统，从而导致最终造成财务影响的威胁。

威胁模型 这是记录系统和威胁的过程，这样我们就可以对与威胁相关的某些类型的系统风险管理决策进行建模。威胁建模有不同的目标，包括一般网络风险管理、系统设计和分析，甚至信息共享模型。

威胁建模方法

威胁建模方法有几种类型。我们先来讨论一下 STRIDE。

Stride

STRIDE 是一种非常常见的威胁方法，用于帮助确定可能出现的问题，尽管它并不是唯一使用的方法。STRIDE 分解为与首字母缩略词一致的助记符：
S欺骗：冒充其他用户或系统组件以获取其对系统的访问权限
T篡改：以某种方式更改系统或数据，使其对目标用户的用处降低
R否认：合理地否认在给定用户或流程下采取的行动
I信息披露：向未经授权的各方发布信息（例如，数据泄露）
D拒绝服务：使系统对目标用户不可用
E特权提升：未经授权授予用户或进程对系统的额外访问权限

大多数供应链攻击都是操作系统的结果，而传统模型（如 STRIDE）是为对系统进行更直接的攻击而设计的，而不是当管理员请求更新其应用程序（以前称为良好，但后来却变成恶意）时发生的间接影响。

Stride-LM

洛克希德马丁公司的研究人员通过添加第七个维度（称为横向移动）扩展了 STRIDE 方法。虽然 STRIDE 对于系统设计很有用，但它不能满足网络防御者的需求。 STRIDE-LM 为防御者提供了一种机制来设计控制措施，使其在最初的入侵点之外更有效地进行防御。

在评估威胁模型是否适用于软件供应链攻击时，请问问自己该模型的设计目的是什么以及它将如何应用于所讨论的场景。例如，许多供应链攻击通过恶意更新或滥用信任来滥用维护阶段，从而绕过旨在检测初始软件入口点的控制措施。同样，由于软件供应链固有的单点故障，这些行动的下游影响可能无法在原始 STRIDE 方法中得到有效建模。随着我们探索本书中的里程碑式案例，您将开始看到横向移动的使用如何为建模提供额外的背景，并使 STRIDE-LM 更适用于面向供应链的攻击.

开放式全球应用安全项目 (OWASP)风险评级方法

OWASP 方法被用作一种定量评分模型，通过利用技术威胁和业务影响标准来得出分数，从而评估特定风险。其核心是使用相当标准的影响 × 可能性计算，但有趣的是等式的两边是如何创建的。以下描述试图捕捉这个公式的基础，但应该注意的是，在实际使用中，改变因素或对非常重要的特定因素施加权重的情况并不少见。例如，在关键基础设施中，我们发现许多实体希望在业务影响中添加第五个“安全”因素，并且通常会赋予它比其他因素更高的权重.

Likelihood = AVG(Threat Agent + Vulnerability)
其中威胁代理 = 技能、动机、机会和规模；漏洞 = 发现的难易程度、利用的难易程度、意识和入侵检测。

Impact T = AVG(Technical Impact + Business Impact)

其中技术影响 = 机密性、完整性、可用性和责任感的丧失；业务影响 = 财务损失、声誉损害、不合规和隐私。 Risk Score = Likelihood X Impact

OWASP可用于评估已识别的风险并确定其优先级以采取行动，但作为威胁建模技术，它对识别未知风险的作用较小。在应用其他威胁建模技术后，将 OWASP 纳入您的流程可能是有意义的。根据我们的经验，它远远优于优先级机制，例如通用漏洞评分系统 (CVSS) 评分，但它确实需要上下文才能发挥作用.

DREAD

DREAD 是 Microsoft 创建的一种传统技术，但我们很少看到它被使用，它通常被认为是一种“过时”的方法。DREAD 使用了类似于 STRIDE 的助记符：
D损害：攻击会有多严重？
R可重复性：重现攻击有多容易？
E可利用性：发起攻击需要多少工作量？
A受影响的用户：有多少人会受到影响？
D可发现性：发现威胁有多容易？

使用攻击树

攻击树（请参阅 http://schneier.com/academic/archives/1999/12/attack_trees.html）是一种从意外或不良后果逆向工作的可视化方法（以便您可以了解该事件如何发生以及最有可能的攻击载体），以及一种创建要实施的优先控制列表以防止该后果的方法。在图 1.1 中，你可以看到，对攻击者来说，最便宜的途径就是直接打开保险箱。优先考虑物理安全控制，以防止他人进入保险箱，或者花更多的钱购买能够抵御此类攻击的保险箱，这可能是明智之举。虽然内部威胁是一种可行的攻击媒介，但攻击者的经济状况使他们不太可能选择这种方法.

这是一种有效的方法，可以开始了解供应链攻击，并了解与更传统的攻击相比，供应链攻击有多么容易实施。对于传统攻击，一半的战斗是获得物理访问权限，甚至试图绕过访问控制。在供应链攻击中，受信任的实体正在采取破坏系统所需的行动。然而，需要穿越的障碍要少得多。让我们看图 1.2 中的攻击示例，它使用了域名抢注攻击，即攻击者提供名称与真实软件包相似的恶意软件包，将恶意组件伪装成 GitHub 上的合法库。这是一个完整的例子。

为了更好地理解这一点，请考虑执行攻击所需的步骤。洛克希德马丁公司开发了一种称为网络杀伤链 (http://lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html) 的方法，它描述了攻击的各个阶段。虽然有很多细微差别，但这些是对手方法的基本步骤（见图 1.3）。

如果对手可以跳过大部分步骤并直接进入指挥和控制，会怎么样？对于对手来说，降低实施攻击的成本和复杂性，并通过了解他们可以实现这些目标的途径，是非常有吸引力的。

威胁建模过程

在本节中，我们将描述一个典型的威胁建模过程。首先，您必须定义您正在构建或更新的系统或应用程序。确定其组件以及这些组件如何相互作用。这开始为识别系统的攻击面奠定基础。它可能是外部可用的应用程序编程接口 (API) 或超文本传输协议 (HTTP) 服务。也许还有其他依赖项，例如需要通信以执行应用程序逻辑或利用联合的身份验证服务的中间件或数据库服务器，但对核心架构理解的需求是启动此过程的基础。

OWASP 应用程序安全验证标准 (ASVS；http://owasp.org/www-project-application-security-verification-standard) 将这种基本的架构理解定义为一项基本要求，包括在设计和未来变更周期中进行威胁建模的需要。OWASP 软件组件验证标准 (SCVS；http://owasp.org/www-project-software-component-verification-standard) 通过要求软件物料清单进一步扩展了这一概念，我们将在本书后面进一步探讨这一点。然而，很明显，要理解威胁以及如何防御威胁，就必须牢牢掌握需要保护的内容.

可以使用许多工具来记录您的系统；其中一种常用工具是 Microsoft 威胁建模工具。多年来，它是唯一可行的选择，但过去几年来，这一领域已经发生了很大变化。威胁建模工具允许软件架构师在开发过程的早期识别威胁，以免补救成本过高。它使用 STRIDE 模型来记录威胁。

在图 1.4 中，您可以看到一个简单的应用程序容器，它将 Internet 访问公开的 Web 服务的上下文与本地访问的上下文分离到文件系统级别，使用信任边界将这些应用程序构造分隔开来。通过以这种方式剖析您的系统，您可以确定潜在威胁代理如何与您的系统交互，并可以开始回答此过程第二部分的问题。还有其他免费工具，例如 OWASP 的 pytm，这是一种基于 Python 的方法，使用常见攻击模式枚举和分类 (CAPEC) 定义自动进行威胁建模，我们将在本章后面进行探讨，以及 Threat Dragon，它更类似于 Microsoft 工具。还有非常强大的商业工具可用，例如 Threat Modeler 和 IriusRisk，它们也采用了 ASVS 设计原则中的先前概念。

威胁建模过程的下一步是确定可能出现的问题。这可能只是简单的错误情况或未接受正确使用应用程序培训的用户，也可能是攻击者试图造成伤害。为了我们的目的，我们将重点关注恶意网络破坏场景来探讨这个主题。

为了说明潜在的软件供应链威胁场景，请考虑图 1.4，其中恶意行为者将恶意日志条目注入 Web 服务，当该服务在本地使用并由日志查看器打开时，会在用户的浏览器中执行恶意 JavaScript。如果许多下游用户使用此 Web 服务，则一次日志注入攻击可能会导致许多依赖此服务的下游用户全部受到攻击。然后，它创建了一个场景，其中攻击者已经破坏了一个 Web 服务，并利用它来破坏许多其他组织，并且现在已经建立了一个滩头阵地，对这些组织或信任它们作为其供应链一部分的下游客户进行进一步攻击。这种数据篡改攻击可能会对下游产生巨大的影响。

知道了可能出现的问题后，您就需要了解可以实施哪些控制措施来最大限度地减少威胁。此阶段的一部分可能包括优先级排序，因为可能无法消除所有潜在威胁；但是，关注最有影响力且成功率较高的场景可能有助于指导控制对话。

例如，在前面描述的场景中，也许清理日志输入或转义字符可能会产生针对此攻击的额外保护。由于攻击者可以通过多种方式绕过传统保护措施，例如为防止跨站点脚本 (XSS) 而实施的保护措施，因此查看类似的保护措施可能会有所帮助，例如 OWASP XSS 预防备忘单中记录的保护措施，该备忘单提供了防止 XSS 漏洞的指导。备忘单列出了防止或限制 XSS 攻击影响的技术 (http://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)。

威胁建模的最后阶段通常涉及评估威胁模型的完整性，并问自己图表是否足够完整以涵盖所有场景，以及是否清楚地标识了信任边界。首先，确定您是否已涵盖所用模型（例如 STRIDE）中定义的所有威胁操作，以及是否已探索所有数据流。最后，确定是否已为所有已识别的威胁制定了风险结果或行动计划，即使已经确定担心所需的缓解措施是否超出您的控制范围且无法采取行动是不可行的。每次在系统中引入重大架构更改时，您都应该关闭模型上的循环并重新验证模型。

此外，我们发现以下概念在软件供应链威胁主题中发挥着重要作用，因此需要花一些时间来定义它们：

溯源(Provenance) 溯源是指工件来自何处。它常常与谱系(Pedigree)混淆（见下一项）。溯源应用于软件时，可能包括特定软件组件的来源或谁为特定库贡献了代码。组织很少在个人贡献者层面进行跟踪，但对于高安全性场景，这可能是值得的。我们通过经验看到，几乎每个广泛使用的开源库都会有来自可能被视为敌对国家的贡献，因此对于选择深入到这一细节级别的组织，可能需要额外的缓解控制或更深入的安全分析来确定这些贡献是否有问题。

谱系(Pedigree) “跟踪和追踪”的概念并不新鲜，事实上，它是法医科学的一个核心概念，与“保管链”日志的应用密切相关，该日志可识别从创建到交付接触过工件的任何人。跟踪指示工件的移动，而保管链则归因于接触工件的个人或组织。安全设备交付的概念同样也出现了，用于跟踪物理资产在全球范围内的运输方式，包括通过 GS1 系列标准使用唯一标识符（如批次 ID 和全球贸易标识符）和保护措施（如物理不可克隆功能 (PUF)）。由于我们主要描述与软件透明度相关的数字工件，因此使用加密和透明度日志可以满足这些要求。与软件透明度相关的谱系可能表示软件包或该软件的安全补丁的历史记录，并且它是一个可以记录在某些软件物料清单格式中的概念。同样，谱系还可以跟踪原点随时间变化的位置，例如 GitHub 存储库从一个维护者更改为新维护者，或者供应商剥离了产品线并将其出售给第三方。这些概念我们将在本书后面进一步探讨。

如今，许多威胁建模框架（如 DREAD 和 STRIDE）被用于各种目的。此类框架通常用于描述安全设计和分析。爱达荷国家实验室 (INL) 的后果驱动网络信息工程 (CCE) 框架侧重于控制与特定业务后果相关的威胁，而不一定控制攻击面的每个点。然后是 STIX 和 PRE-ATT&CK 等框架，它们专为信息共享和其他准备阶段而设计。CAPEC 和 MITRE ATT&CK 等框架具有特定的技术或情境重点。特定于组织的框架包括 NIPRNet/SIPRNet 网络安全架构审查。

同样，大规模威胁建模的一个关键重点往往是关注攻击模式。组织无法正确执行威胁建模的原因在于，大规模执行威胁建模非常困难。Microsoft 安全开发生命周期 (SDL) 将威胁建模列为 12 项活动中的第 4 项——紧接着定义安全要求和关键绩效指标 (KPI)，紧接着定义设计。在设计新系统时，这一点非常有意义，但我们如何在整个环境中大规模地对数百或数千个应用程序进行威胁建模？通常，我们最终会走捷径。这就是攻击模式如此受欢迎的原因，特别是如果我们可以根据已识别的对手或已识别的对手目标群体减少攻击模式的数量。

CAPEC 是 MITRE 托管的公开攻击描述目录，最初由国土安全部创建。此目录包含一个供应链条目 (http://capec.mitre.org/data/definitions/437.html)，可帮助防御者了解这些攻击的构造方式，以便更好地识别防御措施。此供应链攻击的 CAPEC 条目描述了此类攻击，如下所示

此类别中的攻击模式侧重于通过操纵计算机系统硬件、软件或服务来破坏供应链生命周期，以进行间谍活动、窃取关键数据或技术，或破坏关键任务操作或基础设施。供应链运营通常是跨国的，零件、组件、组装和交付发生在多个国家/地区，为攻击者提供了多个破坏点。

此类攻击模式还包括：
■ 挖掘
■ 软件完整性攻击
■ 制造过程中的修改
■ 分发过程中的操纵
■ 硬件完整性攻击

此外，参考 MITRE ATT&CK 也会有所帮助，例如供应链入侵条目 (http://attack.mitre.org/techniques/T1195)，其中还包含三种额外的子技术以及一些可能对防御者有帮助的缓解措施：
■ 入侵软件依赖项和开发工具
■ 入侵软件供应链
■ 入侵硬件供应链

不幸的是，他们目前对供应链的覆盖范围还比较基础，将这种方法与更专业的工作（例如云原生计算基金会 (CNCF) 的工作）相结合可能更有意义，这些工作可能提供防御这些威胁所需的更多特异性。

CNCF 的软件供应链攻击目录还包括一个索引 (https://github.com/cncf/tag-security/blob/main/supply-chainsecurity/compromises/compromise-definitions.md)，其中定义了几种类型的攻击。我们将讨论这些攻击类型，以便共享软件供应链中一些主要攻击媒介的词汇表。攻击类型索引包括：
■ 开发工具
■ 疏忽
■ 发布基础设施
■ 源代码
■ 信任和签名
■ 恶意维护者
■ 攻击链

值得注意的是，有几种攻击类型与现有框架相关，例如 MITRE 的 ATT&CK，其中有专门针对供应链攻击的部分 (http://attack.mitre.org/techniques/T1195)，包括软件依赖项、开发工具和软件供应链本身。

开发人员工具攻击是对用于促进软件开发的工具的攻击。这可能是开发人员的终端设备、软件开发工具包 (SDK) 和工具链。MITRE 建议使用完整性检查机制，例如验证和扫描下载以查找恶意签名。如果恶意行为者能够破坏开发工具，他们就能够从软件开发生命周期 (SDLC) 开始就引入潜在的恶意代码，并玷污所有后续应用程序开发活动和消费者。

疏忽是未能遵守最佳实践，这很常见，因为有太多应用程序安全最佳实践需要了解，而且我们生活在一个日益复杂的数字生态系统中。忽略验证依赖项名称这样简单的事情可能会对组织产生重大影响。恶意攻击者越来越多地使用一种称为域名抢注的攻击方法，如前所述，这种方法利用了对依赖项名称细节的缺乏关注。攻击者通常会瞄准流行的框架或库，以与原始库类似的名称添加恶意代码，然后等待毫无戒心的受害者下载并在其应用程序中使用它。

随着组织现在普遍使用持续集成/持续交付 (CI/CD) 管道和平台来交付软件工件，发布基础设施变得越来越重要。一种缓解技术是代码签名，它有助于确保已发布代码的完整性。但是，正如您将在我们的第一个里程碑案例中看到的那样，对 CI/CD 基础设施本身的攻击可以允许恶意行为者合法地签署软件工件，从而向下游消费者展示它们值得信赖。这种攻击方法可能是毁灭性的和邪恶的，它强调了为什么发布基础设施必须像生产环境一样得到保护，并且它们必须与新兴框架保持一致，例如软件工件的供应链级别 (SLSA)，我们将在接下来的章节中讨论它。

源代码攻击涉及对源代码存储库的攻击，要么直接来自开发人员，要么通过对开发人员凭据的攻击。 2022 年 Verizon 数据泄露调查报告 (DBIR；http://verizon.com/business/resources/reports/dbir) 发现，超过 80% 的数据泄露都涉及凭证泄露。这包括影响源代码或源代码存储库的情况。针对源代码和存储库的恶意行为者通常会尝试将漏洞或后门引入源代码，以便以后利用它们或影响下游消费者。

完整性对于软件供应链的信任至关重要。这通常由数字签名和证明等活动来促进。对代码进行签名为下游消费者提供了一定程度的保证，确保代码的来源及其完整性。话虽如此，泄露签名可能会引发软件供应链攻击。因此，纵深防御等基本安全概念仍然是关键。纵深防御是一种长期存在的网络安全实践，使用多层防御，以确保没有任何一个漏洞或弱点导致整个系统或组织的妥协。恶意行为者需要利用多层防御和安全措施来实现其目标，而不是单一的漏洞或弱点。在前面的例子中，仅使用数字签名是不够的，而且可以被利用。这是 CNCF 索引中列出的攻击类型之一，并被 MITRE 在其 ATT&CK 框架的供应链妥协部分中引用。潜在威胁包括盗窃或私钥、错置信任和滥用证书颁发等活动，如美国国家标准与技术研究所 (NIST) 在其“代码签名的安全注意事项”白皮书中所述（http://csrc.nist.gov/CSRC/media/Publications/white-paper/2018/01/26/security-considerations-for-code-signing/final/documents/security concernances-for-code-signing.pdf）。缓解技术涉及建立可信用户、分离角色、使用强加密和保护签名密钥等活动。

鉴于软件供应链的复杂性以及维护者活动通常具有自愿性质，并非所有威胁都源自项目外部。恶意维护者攻击媒介是 CNCF 索引中列出的威胁之一，涉及维护者或冒充维护者的人故意将恶意软件或漏洞注入供应链或源代码。这可能是由于维护者决定采取恶意行为，或者他们的帐户或凭据已被外部实体泄露而发生的。这些攻击的动机范围从黑客活动分子到那些冒充参与维护者的人，他们只会滥用其权限和访问权限来达到邪恶的目的。

最后，攻击和漏洞不会孤立发生。恶意行为者可能会将多个漏洞和攻击媒介串联在一起，以开展他们的活动和预期意图。看看我们提到的一些攻击类型，一个假设的场景可能涉及恶意行为者冒充感兴趣的贡献者或维护者，只是为了滥用他们的访问权限、插入恶意代码、滥用签名等等。将多个攻击媒介串联起来可能会造成毁灭性的影响，这通常被称为攻击链，Nikki Robinson 博士等研究人员对此进行了研究和讨论。

还有其他新兴方法和框架可以保护软件供应链，并威胁模型可能被恶意行为者利用，例如软件工件的供应链级别 (SLSA)，我们将在接下来的章节中深入讨论

第一章软件供应链威胁的背景

1.3 里程碑案例一：SolarWinds

如果不讨论 SolarWinds 网络攻击，那么现代软件供应链安全事件的讨论就不完整。SolarWinds 是市场上最大的数字系统管理工具提供商之一。2019 年，SolarWinds 开始遭受网络攻击，现在这些攻击被归咎于俄罗斯外国情报局。攻击发生时，SolarWinds 拥有 300,000 个客户，其中包括许多美国政府机构和大多数财富 500 强公司。据估计，在这 300,000 个客户中，有 18,000 个（包括联邦政府机构和客户）收到了受损的软件更新。据说恶意行为者随后专门针对了他们认为是高价值目标的受损客户子集。

虽然在攻击的初始阶段情况并不十分明朗，但现在已经有许多事后报告揭示了恶意行为者的技术复杂性以及受影响的公共和私营部门组织生态系统的下游影响。其中一份由美国政府问责局 (GAO) 编写的报告称 SolarWinds 的网络安全漏洞是“有史以来针对联邦政府和私营部门最广泛、最复杂的黑客攻击之一”(http://gao.gov/blog/solarwinds-cyberattack demands-significant-federal-and-private-sector-response-infographic)。

美国政府问责署还制作了图 1.5 所示的报告 (http://gao.gov/products/gao-22-104746)，以帮助传达与 SolarWinds 攻击相关的活动的高级时间表。

SolarWinds 是一个诱人的目标和典型的软件供应链攻击，因为恶意行为者不太可能对 Solar Winds 作为最终目标感兴趣，而是对 SolarWinds 的客户和下游消费者感兴趣。在这次网络安全攻击之前，SolarWinds 在其网站上吹嘘其强大且备受瞩目的客户名单，该名单随后被删除。SolarWinds 网络安全攻击最初不是由该组织本身发现的，而是由其客户之一 FireEye 发现的，而 FireEye 恰好专注于网络安全。据报道，一名 FireEye 员工被提示重置其多因素身份验证设置，这促使该员工将其提请其团队注意。这随后导致 FireEye 调查该事件并将其追溯到 SolarWinds 的恶意软件，特别是他们的 Orion 软件。 FireEye 的事件响应公司 Mandiant 的首席技术官 (CTO) 表示，该公司检查了 50,000 行代码，才确定 SolarWinds 中存在后门。FireEye 发现 SolarWinds 的软件受到感染后，立即联系了供应商和执法部门，告知他们发现的情况。

虽然攻击时间表的某些细节因来源而异，但前面提到的同一份 GAO 报告提供了一些基本事实。时间表可以从私营部门活动和公共部门参与两个角度来查看，当时联邦执法部门意识到了这一点，联邦调查局和网络安全基础设施安全局 (CISA) 等联邦机构也参与其中。

从时间表的角度来看，据说 2019 年 9 月 SolarWinds 内部系统最初遭到入侵。尽管如此，SolarWinds 首席执行官 Sudhakar Ramakrishna 在 2021 年 RSA 大会上表示 (www.cyberscoop.com/solarwinds-ceo-reveals-much-earlier-hack-timeline-regrets-company blaming-intern)，最初的侦察活动现在可以追溯到 2019 年 1 月。在 2019 年 9 月首次系统攻击的同时，恶意行为者还将测试代码注入 SolarWinds 环境，以验证他们确实破坏了系统并可以执行其预期活动。

恶意行为者使用名为“Sunspot”的恶意软件破坏 SolarWinds 软件开发过程并构建系统。然后，他们在 2020 年 2 月左右将一个现在称为“Sunburst”的后门注入 SolarWinds 的 Orion 产品中。2020 年 3 月，向客户提供了一个修补程序，随后 18,000 名 SolarWinds 客户下载了该修补程序。 2020 年 6 月，威胁行为者删除了其在 SolarWinds 构建的机器上放置的恶意软件。直到 2020 年 12 月，SolarWinds 才收到 Sunburst 的通知。SolarWinds 随后向美国证券交易委员会 (SEC) 提交了一份 8-K 报告 (http://sec.report/Document/0001628280-20-017451)，该报告提供了 SolarWinds 当时所了解的有关情况的见解。

2020 年 12 月 15 日，SolarWinds 发布了软件修复程序来解决受影响的 Orion 产品。当然，这提出了一个有趣的难题，因为供应商之前的软件更新包含恶意软件并影响了客户。 CISA 于 2020 年 12 月 17 日发布了警报 (AA20-352A；http://cisa.gov/uscert/ncas/alerts/aa20-352a)，警告存在一种高级持续性威胁 (APT)，正在危害政府机构、关键基础设施和私营部门。此警报表明，五个不同版本的动态链接库 (DLL) 受到了影响。该警报还特别指出了威胁行为者的耐心、复杂性以及与攻击相关的整体高水平间谍技术。2021 年 1 月还发现了与 Sunspot 相关的其他发现。

网络安全公司 CrowdStrike 发布了对 SolarWinds 网络攻击的详细技术分析 (http://crowdstrike.com/blog/sunspot-malware-technical-analysis)。分析发现，恶意攻击者使用名为 Sunspot 的恶意软件破坏 SolarWinds 构建过程，并将其 Sunburst 后门插入 SolarWinds Orion IT 管理产品中。Sunspot 通过监控编译 Orion 产品所涉及的过程，用 Sunburst 后门代码替换原始源文件之一。然后，该后门促成了恶意攻击者创建反向 shell，以访问运行受影响版本的 SolarWinds Orion 的受感染受害者的基础设施。

关于 SolarWinds 网络攻击及其相关恶意软件和后门，还有更多内容可以写出来，这是迄今为止规模最大、最复杂的软件供应链攻击之一。几位联邦和商业技术领导人将 SolarWinds 网络攻击称为一次警钟，并强调需要加强行业对软件供应链保护的严格要求。

SolarWinds 网络攻击之所以如此邪恶，部分原因是恶意行为者利用了网络安全领域长期存在的最佳实践，即确保在供应商提供更新时修补软件。在这种情况下，更新被毒害，因此那些遵循最佳实践并及时更新/修补的人可能会受到影响。通过破坏构建过程，恶意行为者还能够将被感染的软件伪装成已签名且合法的软件。

自 SolarWinds 事件爆发以来，该公司已在其软件构建流程和功能方面投入了大量资金。一些报告和评论（例如 SolarWinds 首席信息安全官 Tim Brown 的报道）声称，他们修订后的“安全设计”计划每年将花费高达 2000 万美元（http://cybersecuritydive.com/news/solarwinds-1-year-later-cyber attack-orion/610990）。SolarWinds 参加了题为“保护软件开发构建环境”的网络广播（http://cybersecuritydive.com/news/solarwinds-software-build-reproducible-cyberattack-code/596850），他们在其中讨论了他们的安全设计方法，其中包括使用可重现的构建来消除二进制代码中的差异。这涉及到组织如何管理版本和依赖关系的变化，包括拥有恶意行为者需要破坏的多个环境才能成功破坏组织的代码。可重复构建 (http://reproducible-builds.org) 在 SLSA 等框架中被引用，特别是在其最高成熟度和严谨度级别 SLSA 4 级 (http://slsa.dev/spec/faq)。我们将在以下部分讨论可重复构建，但值得强调的是，它是一种成熟的实现，很可能最初被主要软件生产商采用，而且正如 SolarWinds CISO 所指出的那样，这不是一项廉价或轻松的任务

第一章软件供应链威胁的背景

1.4 里程碑案例二：Log4j

虽然 SolarWinds 网络攻击是针对软件供应商的，但 Log4j 事件却大不相同，因为它针对的是广泛使用的开源软件 (OSS)。Log4j 事件于 2021 年 12 月 9 日开始引起公众关注，当时安全研究人员发现了流行软件库 Log4j 中的一个漏洞。Log4j 是一个基于 Java 的日志实用程序，是 Apache 软件基金会项目 Apache Logging Services 的一部分。当时，Log4j 主要用于记录与调试和其他活动相关的信息，以帮助开发人员。在事件发生时，据估计 Log4j 存在于超过 1 亿个环境和应用程序中。

2021 年 12 月 10 日，NIST 的国家漏洞数据库 (NVD) 将 Log4j 漏洞在其通用漏洞评分系统 (CVSS) 上归类为 10.0，并将其与通用漏洞和暴露 (CVE) CVE-2021-44228 相关联。随后还发布了与 Log4j 相关的 CVE，其中不仅包括远程代码执行漏洞，还包括拒绝服务 CVE。

零日漏洞公布后不久，新西兰计算机应急响应小组 (CERT) 警告称，该漏洞已在野外被利用 (http://cert.govt.nz/it-specialists/ advisories/log4j-rce-0-day-actively-exploited)。随后，CISA 发布了一项紧急指令 (http://cisa.gov/news/2021/12/17/cisa-issuesemergency-directive-requiring-federal-agencies-mitigate-apache-log4j)，要求联邦机构缓解 Apache Log4j 漏洞。不久之后，2021 年 12 月 22 日，CISA、FBI、NSA 和国际合作伙伴发布了一份联合公告 (http://cisa.gov/news/2021/12/22/cisa-fbi-nsa-andinternational-partners-issue-advisory-mitigate-apache-log4j)，以缓解 Apache Log4j 漏洞。此联合公告是为了应对全球范围内对 Log4j 漏洞的积极利用而发布的。CISA 主任 Jen East 曾称 Log4j 漏洞对世界各地的组织和政府构成了严重且持续的威胁，合作伙伴国家也表达了类似的看法。您可以在图 1.6 (http://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228) 中查看 Log4j 事件时间线。

与影响特定供应商的特定产品系列的 SolarWinds 不同，Log4j 的影响更加多样化和分散。Log4j 的应用范围非常广泛，从开发人员工具、云服务产品到安全供应商产品，无所不包。正如我们将在本书以云为重点的章节中讨论的那样，最大的云服务提供商 (CSP)，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud，都发布了有关 Log4j 的指导，因为在事件发生时，Log4j 已用于他们的许多云服务产品中。当然，这不仅会对直接使用云服务的客户产生下游影响，还会对在 CSP 的基础设施和服务之上构建的其他组织产生下游影响，这不仅强调了易受攻击的软件组件的影响，还强调了由于软件供应链中的服务提供商，它可能产生的连锁影响.

除了 GAO 和其他机构提供的见解外，网络安全安全审查委员会 (CSRB) 还将 Log4j 作为其调查和报告的第一个网络事件 (http://cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf)。CSRB 是根据网络安全行政命令 (EO)“改善国家网络安全”成立的 (http://cisa.gov/sites/default/files/publications/Cyber%20Safety%20Review%20Board%20Charter_508%20Compliant.pdf)。CSRB 的成立也类似于国家运输安全委员会 (NTSB)，其目标是审查重大网络事件并提出具体建议，以推动公共和私营部门的改进。委员会的成员包括具有不同独特专业知识的公共和私营部门领导人。他们的第一份报告（如前所述）重点关注 Log4j，其中大量提到了软件透明度、库存和治理的必要性，而软件物料清单 (SBOM) 是这一追求的核心组成部分。该报告呼吁组织利用 SBOM 来提高 IT 资产和应用程序清单的准确性，并呼吁管理和预算办公室 (OMB)、国家网络总监办公室 (ONCD) 和 CISA 等组织在生态系统成熟时提供有效使用 SBOM 的指导。该报告 18 次提到 SBOM，呼吁公共和私营部门组织在 SBOM 和软件透明度领域采用并增加投资

CSRB 的 Log4j 报告内容全面，将其建议分为四类。这些建议包括解决 Log4j 的持续风险、推动现有的安全卫生最佳实践、构建更好的软件生态系统以及进行未来投资。报告承认，组织将在未来几年内努力应对 Log4j 漏洞，并应继续报告和观察 Log4j 的利用情况。报告呼吁组织投资于识别易受攻击系统的能力，建立漏洞响应程序，并继续开发准确的 IT 和应用程序清单，这是 SBOM 在软件组件和 OSS 消费环境中发挥作用的地方。企业中拥有强大软件组件清单的组织将能够更好地应对下一次 Log4j 类型的事件，了解其组织是否易受攻击以及在何处易受攻击。报告呼吁 OSS 开发人员参与基于社区的安全计划，并投资培训开发人员进行安全软件开发，这是 OpenSSF OSS 安全动员计划中的一项关键建议，我们将在本书后面讨论。它还呼吁改进 SBOM 工具和采用，并投资于关键服务的 OSS 维护支持。最后，该报告还呼吁在关键领域进行投资，例如联邦政府供应商的软件透明度基本要求、探索网络安全报告系统 (CSRS) 以及研究构建安全软件的激励结构。所有这些建议都与公共和私营部门其他领先组织的建议一致，例如 NIST、Linux 基金会、OpenSSF 等。

为了承认易受攻击的 OSS 组件（例如本案中的 Log4j）威胁的普遍性，FBI 和 CISA 于 2022 年 11 月发布了联合网络安全咨询，宣布美国联邦民事行政部门 (FCEB) 的一个机构遭受了伊朗政府支持的攻击。恶意行为者利用未打补丁的 VMware Horizon 服务器中的 Log4Shell 漏洞，安装加密挖掘软件，甚至横向移动到域控制器 (DC) 并泄露凭据以实施反向代理，从而在环境中保持持久性 (www.cisa.gov/uscert/sites/default/files/publications/aa22-320a_joint_csa_iranian_government-sponsored_apt_actors_compromise_federal%20network_deploy_crypto%20miner_credential_harvester.pdf)

第一章软件供应链威胁的背景

1.5 标志性案例三：Kaseya

另一个值得讨论的非常突出的软件供应链攻击是 Kaseya 勒索软件攻击。Kaseya (http://kaseya.com) 是一家统一的 IT 管理和安全软件公司，专门为托管服务提供商 (MSP) 和 IT 团队提供帮助。他们的解决方案旨在帮助团队在 IT 安全、效率和服务交付方面取得进步。

Kaseya 勒索软件攻击发生在 2021 年 7 月，估计已影响了 2,000 家组织。它被归咎于 REvil 勒索软件组织，这是一个主要讲俄语的恶意行为者团体。REvil 组织的个人与 Kaseya 等攻击有关，但也与针对美国企业甚至政府实体的其他攻击有关。

Kaseya 为客户提供本地和基于软件即服务 (SaaS) 的软件解决方案。2021 年 7 月 2 日，该组织的事件响应 (IR) 团队检测到其名为 Kaseya VSA 的远程管理软件存在潜在的安全事件。初步调查引起了足够多的关注，以至于该组织建议其所有本地客户关闭 VSA 服务器，直至另行通知，并且他们还关闭了自己的基于 SaaS 的产品 (http://helpdesk.kaseya.com/hc/en-gb/articles/4403440684689)。Kaseya 建议客户关闭服务器至关重要，因为攻击者在初始攻击期间删除了 VSA 的管理访问权限。

随后，Kaseya 与 FBI 和 CISA 的外部权威机构和专家合作开展 IR 活动。Kaseya 迅速提供了工具，帮助组织确定他们是否因尝试检测入侵而受到影响。在 CISA 和 FBI 等组织与 Kaseya 合作的同时，他们也开始为可能受到影响的客户提供指导 (http://cisa.gov/uscert/ncas/current-activity/2021/07/04/cisa-fbi-guidancemsps-and-their-customers-affected-kaseya-vsa)。他们的指导包括使用 Kaseya 提供的检测工具、加强身份验证流程以及最大限度地减少与已知可信 IP 地址的网络通信等活动。

与此同时，Kaseya 开始测试补丁以解决问题并实施其他缓解安全控制措施。他们还发布了客户指南，试图为即将到来的补丁活动做好准备（http://helpdesk.kaseya.com/hc/en-gb/articles/4403709150993）。

在此过程中，2021 年 7 月 8 日，白宫发表官方声明，将此次袭击归咎于俄罗斯。美国政府领导层也发表声明，承诺追究俄罗斯对此次袭击的责任。虽然 Kaseya 努力为本地和云端的客户解决问题，但有传言称，该组织的高管此前已在数年内被警告过其软件存在缺陷（http://krebsonsecurity.com/2021/07/kaseya-left-customer-portal-vulnerableto-2015-flaw-in-its-own-software）。更有趣的是，涉及的 CVE CVE-2015-2862 属于 Kaseya 自己。

虽然据称此次攻击本身仅影响了该组织 40,000 多名客户中的 0.1%，但根据该组织首席执行官 Fred Voccola 的评论，这一比例仍然相当于 800 到 1,500 家小型到中型组织，这些组织通过使用 Kaseya 软件的 MSP 受到影响。这种涓滴效应是现代软件供应链复杂性的完美例证，以及单个软件的影响如何影响数千个下游消费者。大多数消费者都无法了解他们的 MSP 用于向他们提供服务的软件，因为软件供应链不透明，尤其是在与 MSP 和 CSP 等外部服务提供商打交道时。下游消费者只知道他们直接从提供商那里消费的服务或软件在交付过程中使用。

值得注意的是，回到白宫关于追究责任人责任的评论，已经逮捕了相关人员。美国司法部 (DOJ) 于 2021 年 11 月宣布 (http://justice.gov/opa/pr/ukrainian-arrested-and-charged-ransomware-attackkaseya)，俄罗斯国内安全机构逮捕了 14 名与 REvil 勒索软件组织有关的个人。这还包括缴获与该组织各种勒索软件漏洞相关的 610 万美元。司法部领导层还强调，他们将继续针对那些专注于美国受害者的个人。

第一章软件供应链威胁的背景

1.6 案例的启示

从这些案例中得出的最重要的结论是，专注于传统的“最后一英里”防御措施（如散列和代码签名）是远远不够的，而且可能会给人一种虚假的安全感。最成功的攻击发生在这些过程的上游，签署恶意代码可能比根本不签署造成更大的危害。

其次，就像传统的网络防御一样，建立“正常”的基线可以为异常检测创建标准参考。这包括许多软件物料清单工件的生成，以及有关这些工件的元数据，如散列和代码签名。虽然不是明确的（这似乎与上一段相矛盾），但这些仍然是有效的技术，但它们必须在流程的早期执行，并在流程的每一步进行验证和重新验证。

除了这些静态工件之外，了解软件的代码执行流程和网络行为对于识别恶意功能也很有价值。例如，在 SolarWinds 的案例中，是行为变化（不一定是在代码审查中发现的任何东西）揭示了这种妥协。安全软件开发是一个包含多个阶段和许多妥协机会的过程。虽然零信任架构的概念是为身份和资源访问（例如应用程序访问控制）而设计的，但核心原则同样适用于安全软件开发。作为零信任核心原则的提醒，这些原则包括:

■ 用户和身份
■ 设备
■ 网络和环境
■ 应用程序工作负载
■ 软件供应链
■ 数据

安全软件需要在整个生命周期内采用多学科方法。虽然软件物料清单之类的技术是工具带中的一种工具，但它无法阻止诸如 SolarWinds 之类的复杂攻击。没有“一刀切”的安全工具可以解决这些问题，它需要彻底改变我们今天开发软件的方式以及我们在软件开发过程的所有阶段和整个软件供应链中管理信任的方式。交付代码的组织要对他们交付的所有代码负责，而不仅仅是他们编写的代码，这意味着上游输入的验证与他们自己的开发团队制作的软件一样重要，甚至更重要。

第一章软件供应链威胁的背景

1.7 小结

在本章中，我们讨论了软件供应链威胁的背景以及攻击者的一些相关诱因。我们还讨论了软件供应链攻击的潜在结构。我们介绍了威胁建模的基础知识及其在防止软件供应链攻击中可以发挥的作用。最后，我们讨论了一些具有里程碑意义的软件供应链攻击，这些攻击影响了各种实体，例如专有软件供应商、OSS 组件和托管服务提供商 (MSP)。

第二章传统的供应商风险管理

传统的供应商风险管理方法历来用于了解软件和产品供应商的安全软件开发实践。其理念是，要求供应商回答一系列关于他们如何处理某些安全控制的问题，这可能是确定他们是否了解他们应该做什么、是否有记录在案的流程以及他们是否在做他们所说的事情的唯一方法。这是通过要求提供额外的证据来表明他们正在做什么来实现的。但首先，让我们了解一下这个问题，并检查一下这种方法的有效性。

第二章传统的供应商风险管理

2.1评估

首先，这些评估面临着巨大的潜在挑战。企业每年如何进行数百甚至数千次评估来执行风险管理计划？最常见的方法是利用一份标准问卷，将其发送给所有供应商，向他们提出相同的问题，以便将供应商相互比较。但哪些问题是有效的？多少个问题才算足够？是否用相同的方式来评估所有供应商？我们怎样获得提出好问题所需的背景信息？又怎样才能有效地处理所有的问卷？这绝对是一项艰巨的工作！不仅对软件消费者来说很麻烦，对软件提供商来说也是如此。因为软件供应商必须使用现有方法，也就是传统的供应商风险管理来处理来自消费者和客户的多个请求，尤其是当他们与许多客户合作时。

其次，一旦建立了流程和执行方法（可能在内部执行或外包给评估提供商），获得供应商的合作可能非常棘手。通常，在续约前或基于供应商应遵守的合同条款进行评估工作是最有效的。然而，这些评估对供应商来说代价很高，并且他们可能缺乏分享信息的动力。例如，如果合同要求他们分享软件中的漏洞并迅速修复这些漏洞，从成本角度来看，这实际上是要求他们参与一项不符合自身最佳利益的活动。

最后，什么被认为是可接受的证据？是一张他们执行所需活动的截图吗？这不过是特定配置或活动在某个时间点的快照，不能保证它会持续一致地发生。那么，活动日志呢？如何确定日志没有被伪造，或者截图能代表整个环境中重复发生的过程吗？政策的证据很好，但怎么知道它是否得到了持续一致的执行？这些评估通常由风险团队进行，缺乏与安全从业者的合作，而安全从业者可以帮助验证这些结果，甚至理解公司关于供应商实践所传达的信息。由于这些原因，许多安全从业者认为传统的风险评估价值不高，仅仅是合规活动。当然，也有例外，但在很多情况下，这种传统的风险评估方法不足以实现全面的风险管理，需要额外的严格性。

这也给消费者带来了挑战。如果你是一家企业，从外部供应商处购买软件和服务，你的组织和团队在给定时间段内（如一个月或一年）只能处理有限的评估、相关文档和与供应商的接触。根据我们的经验，团队通常在向典型组织添加成倍增加的软件、供应商和服务，这超出了团队适当处理或管理它们的能力。这常常导致所谓的影子IT（shadow IT），或者说在企业环境中未经管理的软件。传统意义上的标准化评估也存在挑战，原因包括进行评估的专业人员的主观性以及他们对被评估技术和软件的偶尔缺乏了解。这并不是说专业评估和见解没有价值或将来不会有价值。但在软件透明度、自动化、可见性和文档方面的创新也可以带来更高的对特定软件或供应商及其相关实践的安全性保证。

传统的供应商评估过程通常通过自我声明或第三方评估机构进行，每种方法都有其挑战和缺点。自我声明让供应商自己证明他们符合特定要求，但当涉及收入和合同时，这种方法容易出现问题，并且可能带来主观解释的风险，通常供应商在评估自己时会倾向于给出正面的解释。一个显著的例子是国防部的国防工业基地（Defense Industrial Base, DIB），它要求承包商自我声明符合NIST 800-171要求和控制措施。

多份报告揭示了自我声明分数的显著差距，这些分数被夸大了，与第三方评估的分数形成了鲜明对比。由于安全控制措施未能按预期实施，美国多家联邦国防承包商经历了本可以预防或至少减轻的安全漏洞。这种现实情况导致了国防部网络安全成熟度模型认证（Cybersecurity Maturity Model Certification,CMMC）框架的创建，该框架要求第三方评估合规性。

自我评估的另一面是使用第三方评估机构（third-party assessment organizations,3PAOs），这些独立的第三方会对实体的特定框架或要求的合规性进行初步和定期评估。一个例子是美国联邦政府的联邦风险与授权管理计划（Federal Risk and Authorization Management Program,FedRAMP），该计划帮助授权联邦政府使用的云服务提供商（cloud service providers,CSPs）。虽然这种方法比自我评估提供了更高的保证，但也非常繁琐、昂贵且耗时。

以FedRAMP为例，它已经存在了十年，但截至目前，FedRAMP市场上授权的云服务产品不到300个，而商业市场上可供消费的云服务产品有成千上万。这种模式在提供更高保证的同时，由于第三方评估机构方法对供应商和市场施加的时间和成本，显著减少了对创新解决方案和提供商的访问，导致一些小公司难以承受这些费用和繁琐的过程，或者认为不值得。这些方法在规模上存在挑战，或会对没有足够收入和预算的小公司施加沉重的成本负担。

传统的问卷调查流程繁琐、耗时又昂贵。更糟糕的是，这种流程充满了风险，因为消费者获得的保证来自瞬时证据，基于主观评估，且经常是由软件或服务提供商自我声明，这些提供商因收入和合同关系，倾向于给出正面的评价。传统的供应商风险管理实践通常由手动、基于纸质的活动驱动，这些活动主观且繁琐。

随着软件透明度的提升，我们现在看到的是基于证据的评估，可以查看供应商的软件及其相关组件，以确定其风险状况，这比口头交流和基于表格的问卷调查更能有效证明安全开发实践的有效性。我们还看到市场上有创新解决方案，特别是在云计算和声明式基础设施和应用程序方面，允许近实时的合规性评估，利用API和自动化技术，在摆脱困扰行业数十年的手工表格流程的同时，提供更高的合规保证。当然，我们也认识到并非所有的安全控制都可以自动化或是技术性的，它们始终需要专业见解和评估以及人际互动。

第二章传统的供应商风险管理

2.2 软件开发生命周期评估

软件开发生命周期（Software Development Life Cycle，SDL）评估更侧重于了解供应商的流程。虽然这个框架可能类似于传统的供应商风险评估，但通常由合格的应用安全顾问进行的集中评估更为细致。一般来说，这些评估与记录在案的流程保持一致，并且可能参考定义明确的SDL，例如微软SDL。这使得顾问能够将供应商的流程与最佳实践进行对比，以确定推荐的活动是否已定义和理解，最重要的是，验证这些活动是否以一致的方式实施。

对于大型产品供应商而言，流程不一致的情况尤其常见。例如，一个大型原始设备制造商（Original Equipment Manufacturer，OEM）可能为其每条产品线创建不同的法律实体，这导致10-20个不同的组织，每个实体都有不同的流程。由于法律结构的不同，安全条款的合同要求也存在不一致。如果你评估其中一个实体的SDL，很容易将该评估结果应用于你从他们那里购买的每一个产品。但这样做是不准确的，可能会导致错误的假设和有害的风险决策。

这就是使用诸如软件工件供应链级别（Supply Chain Levels for Software Artifacts，SLSA）等框架的价值所在。我们将在本书后面详细描述SLSA。SLSA以类似于SDL的视角看待威胁环境，识别出可能的薄弱点——即必须验证的外部信任点——因为这些点有可能对你的SDL产生负面影响。

第二章传统的供应商风险管理

2.3应用程序安全成熟度模型

与SDL评估类似，查看诸如构建安全成熟度模型（Building Security in Maturity Model，BSIMM）或软件保证成熟度模型（Software Assurance Maturity Model，SAMM）等模型，可以非常有效地记录供应商软件项目的成熟度。当然，SDL是其中的一部分，但查看这些模型之一，如OWASP SAMM，也称为早期版本中的OpenSAMM，可能会有所帮助（https://owasp.org/www-project-samm）。

BSIMM也被广泛使用，但由于它是一个专有模型，我们更倾向于研究开源方法。SAMM定义了如图2.1所示的领域。

SAMM定义了五个业务功能，如图2.1所示：治理、设计、实施、验证和运营。在这些业务功能中，每个功能包含三个安全实践。每个安全实践涉及两个相互补充并相互构建的活动流。由于SAMM是一个开放模型，它可以内部用于评估一个组织，也可以由第三方外部使用。值得注意的是，NIST安全软件开发框架（Secure Software Development Framework，SSDF）指导——我们将在第七章“现有和新兴商业指导”中讨论，并且对向美国政府出售软件的供应商是强制要求的——经常使用SAMM，并在SSDF的实践和相关任务中交叉引用。

与所有OWASP项目一样，SAMM是一个社区驱动的项目，旨在可衡量、可执行且多用途。与BSIMM不同，SAMM是规定性的，这意味着它规定了组织可以采取的具体行动和实践，以提高其软件保证。正如其名称所示，SAMM是一个成熟度模型。在其指定的安全实践中，范围从1级到3级，起点为0级。尽管SAMM是一个成熟度模型，但并不要求所有组织在所有实践中都达到最高的成熟度水平。成熟度要求和目标取决于组织的资源、合规要求、资源和任务集。让我们深入了解SAMM中的一些业务功能和相关的安全实践。

治理

第一个业务功能是治理，它专注于与组织管理软件开发活动相关的流程。其实践内容包括战略与指标、政策与合规以及教育与指导。战略与指标方面，涵盖了创建、推广，并随时间进行测量和改进；政策与标准则涉及制定并管理其在整个组织中的实施和遵守。教育与指导分为培训与意识和组织与文化两个部分。培训与意识主要提升各利益相关者对软件安全的认知，而组织与文化则致力于在组织内部推动安全文化的形成。

设计

第二个业务功能是设计，它专注于组织创建和设计软件的流程和活动。安全实践包括威胁评估、安全需求和安全架构。威胁评估侧重于应用风险分析和威胁建模等活动流。通过风险分析，组织确定哪些应用被攻破会构成严重威胁，而威胁建模帮助团队了解正在构建的内容、可能出错的地方以及如何缓解这些风险。安全需求涉及软件构建和保护，以及可能参与组织应用开发的相关供应商组织（如外包开发人员）的要求。安全架构处理的是软件设计中涉及的各种组件和技术，确保架构设计的安全性和技术管理，包括识别和管理应用程序所使用的技术、框架、工具和集成的相关风险。

实施

第三个业务功能是实施，它涉及组织如何构建和部署软件组件，并可能包括缺陷管理。所涉及的安全实践如下：

安全构建：使用一致、可重复的构建过程和依赖关系核算
安全部署：提高软件部署到生产的安全性
缺陷管理：涉及管理已部署软件的安全缺陷

安全构建实践包括构建流程和软件依赖。构建流程确保你在部署时使用可预测、可重复的安全构建流程。软件依赖则关注外部库，确保它们的安全状况符合组织的要求和风险容忍度。

安全部署实践专注于将软件交付到生产环境的最后阶段，并确保在此过程中其完整性和安全性。与该实践相关的方面包括部署流程和秘密管理。部署流程确保组织拥有可重复且一致的部署流程，将软件工件推送到生产环境以及必要的测试环境。秘密管理关注对敏感数据（如凭证、API密钥和其他秘密）的适当处理，防止恶意行为者利用这些数据破坏软件开发中涉及的环境和系统。

最后一个安全实践是缺陷管理，专注于收集、记录和分析软件安全缺陷，以便做出数据驱动的决策。相关方面包括缺陷跟踪和指标，并且进行反馈。这些方面涉及缺陷的收集和后续处理，并通过这些活动推动安全性的改进。

验证

验证业务功能涉及组织在软件开发过程中如何检查和测试工件的流程和活动。与验证相关的安全实践包括架构评估、需求驱动测试和安全测试。架构评估验证软件及其支持架构的安全性和合规性，而需求驱动测试和安全测试则基于用户故事等项目，通过自动化检测和解决安全问题。

架构评估包括验证和缓解两个方面。验证旨在确保架构中安全目标和要求的实现，而缓解则是针对现有架构中已识别的威胁进行处理。这些实践中的测试活动确保组织进行诸如滥用/误用测试等活动，采用模糊测试等方法。模糊测试是一种软件测试方法，通过注入无效或格式错误的输入，揭示软件缺陷或识别可能被滥用以攻击应用程序的功能。安全测试则包括广泛的自动化测试基线和深入的理解，涉及对高风险组件和复杂攻击向量的手动测试，这些是自动化测试无法完成的。

运营

运营业务功能确保应用程序及相关数据在整个生命周期内，包括运行时环境中的机密性、完整性和可用性（confidentiality, integrity, and availability,CIA）。安全实践包括事件管理、环境管理和运营管理。进一步细分，这些实践涵盖了各种领域，如事件检测与响应、配置加固和补丁管理。最后，运营管理确保在数据创建、处理、存储和处理的整个生命周期内进行数据保护，并确保不再主动部署或支持已到生命周期末期的服务和软件。这减少了组织的攻击面，移除了其系统和应用程序中可能存在的漏洞组件。

通过利用SAMM并涵盖各种业务功能、安全实践和活动流，组织可以更好地确保其应用程序安全成熟度，其软件消费者也同样受益。

第二章传统的供应商风险管理

2.4 应用程序安全保证

传统上，应用程序安全实践集中在应用程序测试的概念上，我们在这里称之为应用程序安全保证。在这里，应用程序安全超越了治理和流程等较软的主题，旨在回答有关应用程序技术风险的问题。我们在这里讨论五种主要方法和几种使用的技术：

静态应用程序安全测试（SAST）
动态应用安全测试 (DAST)
交互式应用程序安全测试 (IAST)
移动应用程序安全测试（MAST）
软件组成分析（SCA）

静态应用程序安全测试

进行代码审查的概念，对于从事应用程序安全实践的人来说可能并不陌生。这是对某一时刻应用程序或软件组件源代码的静态视图。通常，在一些重要的里程碑，如重大发布或架构变更时，会进行详尽的静态应用程序安全测试（static application security testing, SAST）。而日常的代码审查则仅限于对代码库中新编写或更新的代码进行检查。

SAST可以通过手动或自动方式进行。然而，在大型软件项目中，手动审查可能会面临可扩展性问题。此外，由于某些应用程序框架在不同路径中可能重复使用文件名，这也可能使测试人员感到困惑。即使是手动代码审查，测试人员通常也会遵循优先级流程，重点寻找已知漏洞函数或应用程序的高信任区域，如身份验证和访问、密码管理、数据加密等。挑战在于，像输入验证例程等重要功能可能并不总是在这些审查中被捕捉到，而且结果高度依赖于测试人员的技能和测试范围的时间。

同样，自动化测试可以帮助完成测试的完整性，并以更快的速度处理大规模的代码库，但在所有测试方法中，SAST的误报率最高。即使是最好的SAST工具，误报率通常也在5%或更高。这看起来不多，但当你意识到一个大型应用程序可能识别出成千上万的错误时，情况就不同了。尽管如此，通过利用机器学习（ML）等技术进行创新，可以基于先前的审计活动构建，从而提高准确性。（误报是指基于规则集识别出的发现，尽管这些发现实际上并未对系统构成风险。这些误报可能会导致团队浪费时间分析那些并不实际构成风险但根据使用的工具和规则触发的发现。）这也是对软件材料清单（software bill of materials, SBOM）作为漏洞检测手段的常见批评。误报会制造噪音，损害应用程序安全计划的可信度，并可能导致软件发布延迟或在无明显价值的错误领域重新优先考虑安全工作。这种认知消耗可能会使团队士气低落，并阻碍软件交付的速度。

尽管存在这些问题，SAST仍然是识别软件缺陷、安全性和质量的重要且有价值的手段之一。它也是帮助开发人员了解他们在哪里编写不安全代码的最佳方法之一。许多现代集成开发环境（IDEs），如Eclipse等，配备了SAST工具的插件，当开发人员使用不安全约定或做出可疑的代码质量选择时，这些插件会提供即时反馈。此外，许多安全编码培训平台使用不安全的代码片段示例来培训开发人员编写更安全的代码。

在软件透明度工作中利用SAST的最有用方法之一是帮助验证和改进你的软件物料清单，并识别出哪些大型库被使用，但只需要其中的一小部分功能。通常情况下，一个包含100个或更多函数的库会被导入，但你的软件只调用了不到10个函数，这种情况下，SBOM可能会识别出一些实际上无法被利用的漏洞，导致误报。如果你能剔除不必要的代码，将会减少很多噪音。不过，修改后别忘了重命名你的库，因为SBOM工具会根据库的名称和版本来识别内容，如果名称和版本不匹配，可能会导致识别错误。

动态应用安全测试

虽然SAST通过源代码从内到外检查应用程序，动态应用程序安全测试（dynamic application security testing，DAST）则通过HTTP和其他基于Web的协议从外到内进行测试。需要注意的是，DAST通常局限于Web应用程序，无法用于桌面、移动或其他不监听和响应HTTP的应用程序。此类测试专注于直接与正在运行的应用程序或其组件（如API或监听服务）进行交互。DAST的一个挑战是，测试必须在应用程序达到足够的操作状态后才能进行，因此，其执行时间比SAST要晚得多。一个关键的优势是DAST的误报率较低，但相应的漏报率更高。（漏报是指测试未能检测到实际存在的安全问题，这同样是不理想的。)

通常，这种方法的工作方式是配置扫描器以编程方式与应用程序交互，例如，通过脚本化的浏览器模拟界面。扫描器首先浏览Web应用程序，识别所有路径（除了测试人员排除的那些），跟随页面上的任何链接，并忽略测试范围外的其他Web域。这通常也被称为Web爬虫或蜘蛛。如果需要身份验证，也可以配置扫描器处理应用程序中的特定Web表单。

在蜘蛛程序完成后，DAST工具会构建一个可供测试的路径列表，并使用预配置的测试列表来搜索缺陷，如SQL注入和跨站脚本攻击等。一旦识别出潜在风险并捕获到令工具怀疑问题有效的证据，DAST工具会以扫描报告的形式将这些结果返回给测试人员。自动化的DAST测试通常需要很少的测试技能和交互，但它确实提供了对应用程序工作原理的良好可见性。在某些情况下，这种可见性在构建Web应用程序防火墙规则和了解应用程序的攻击面时非常有用。

更复杂的DAST场景通常涉及拦截代理的概念，即测试人员在其浏览器中配置一个Web代理，拦截他们的HTTP请求和响应，以便进行操作和利用应用程序。尽管这通常是一个手动操作，但从应用程序站点地图开始，可以为测试人员提供测试范围。此外，大多数此类工具确实提供了一定程度的自动化，原生或通过插件实现，如Burp Suite或Zed Attack Proxy（ZAP）工具系列所使用的那样。

混合分析映射（HAM）是一种结合SAST和DAST优势的技术，能够生成混合静态动态测试结果。其理念是，SAST可以对软件进行全面覆盖并识别潜在问题，然后运行DAST，彻底扫描应用程序的攻击面，寻找与SAST发现相关的漏洞。这种方法对于以最大程度的可信度对漏洞进行优先排序非常有效。然而，尽管这种匹配能够提高检测的准确性，SAST的发现仍然需要经过验证，以确保其真实性和相关性。

在软件供应链安全方面，建议回到应用程序的威胁模型，考虑它可能被如何滥用。例如，如果你的应用程序调用外部脚本，外部域名被接管是否会将恶意代码注入到用户的会话中？拦截代理提供了出色的功能，可以操纵和重定向流量，以模拟这些场景。如果应用程序执行组件更新呢？这些场景是无穷无尽的，通过赋予你的测试团队使用灵活工具的能力，发挥创造力并拥抱他们的“邪恶”一面，你可以扩展对潜在风险的理解。

另一个在讨论DAST时值得强调的点是其识别第三方客户端依赖项及其已知漏洞的潜在能力。例如，一个Web应用程序通过脚本标签而不是包管理器（如npm）包含库。大多数SBOM工具可能会忽略这种检查和上下文，而DAST工具可能能够识别并报告这些潜在风险。

交互式应用程序安全测试

另一种测试形式是交互式应用安全测试（IAST），它使用运行时中的应用程序仪表或使用软件开发工具包（SDK）直接进入运行中的应用程序，跟踪代码流动情况，观察数据在应用程序中的流动情况。IAST供应商声称，这种方法可以比其他测试方法更真实地反映应用程序的运行情况，有时使用IAST就像在托管应用程序的服务器上安装一个软件代理一样简单，但通常不支持所有编程语言和框架。

这种技术也是过去十年中出现的一种被称为运行时应用程序自我保护（RASP）的新型保护机制的核心。RASP作为网络应用防火墙（WAF）的替代或至少是补充方法出现。由于RASP了解应用程序内部发生的事情，它不会像WAF那样被绕过WAF风格的攻击或签名变异所欺骗。然而，由于它看不到原生的网络流量，RASP无法在嘈杂的攻击影响网络应用程序之前进行缓解。

事实上，IAST供应商（如Contrast Security）的研究表明，我们认为会给我们带来风险的许多软件实际上从未被我们的代码调用过。大多数开源组件可能只使用了其功能的10-20%。此外，随着SaaSBOM（捕获服务的物料清单）、API、数据流等主题的发展，IAST可能是捕获这些信息最可行的方法之一。这是目前SBOM工具供应商不支持的领域，但随着软件透明度市场在未来几年中的成熟，IAST将扮演的重要角色值得期待。

移动应用程序安全测试

随着移动设备及其相关应用程序的普及，另一种测试形式在行业中变得常见。这被称为移动应用安全测试（MAST）。MAST涉及使用静态和动态测试方法来识别与移动应用程序、平台和设备（如Android和iOS）相关的安全漏洞和缺陷。这种测试可以帮助识别危险功能、过多权限以及可能被恶意行为者利用的漏洞。随着SBOM（软件物料清单）概念的发展，我们现在在移动设备领域看到了SBOM的创新解决方案，例如NowSecure，它可以从运行中的应用程序生成SBOM，包括其应用程序库依赖关系、操作系统级别依赖关系和应用程序正在通信的服务（www.nowsecure.com/press-releases/nowsecure-announces-the-worlds-first-dynamic-software-bill-of-materials-sbom-for-mobile-apps）。

软件成分分析

另一种常见的应用保障方法和工具类别是软件成分分析（SCA）。简而言之，SCA有助于识别代码库中的开源软件（OSS）及其相关依赖关系。组织已经开始广泛使用OSS组件和库。SCA可以帮助评估应用程序的安全性、许可证合规性和代码质量。一些SCA工具提供支持生成SBOM（软件物料清单），以帮助提供组成应用程序的组件和依赖关系的详细清单。正如我们将在第10章“供应商的实用指南”中讨论的那样，了解应用程序或产品中包含哪些OSS组件及其相关的许可和漏洞信息是至关重要的。行业实践者通常还建议在SDLC（软件开发生命周期）早期使用SCA工具，以便在软件开发期间识别和减轻漏洞，防止这些漏洞传递给应用程序用户或在SDLC的后期阶段需要更昂贵和破坏性的修复。在第6章“云和容器化”中，当我们讨论推动DevSecOps时，我们将触及这一点。

第二章传统的供应商风险管理

2.5哈希和代码签名

使用加密验证的历史可以追溯到几十年前，通过诸如MD5和SHA-256之类的算法构建单向哈希。其理念是由于这是不可逆的加密，不能被操控，并且因为哈希理论上应该是唯一的，可以用于表示文件的完整性。如果攻击者修改了软件，并且你计算的文件的结果哈希与软件供应商提供的哈希不匹配，你是安全的。但如果攻击者在替换软件时也替换了哈希呢？它是否以任何方式在带外计算或存储？如果答案是否定的，那么很难确定哈希的合法性。此外，像monomorph（https://github.com/DavidBuchanan314/monomorph）这样的工具允许创建所谓的哈希碰撞，即两个不同的文件可以产生相同的哈希，从而使其唯一性失效。因此，MD5在法医学上已经不被认为是可靠的。更强的哈希机制如SHA-256等更好，但它们仍然存在信任问题。

此外，单独计算哈希的过程在操作上并不高效。考虑以下八步过程：

确定要下载的文件。
下载文件。
确定哈希的存储位置。
下载哈希文件。
确定哈希方法。
如果尚未安装，则下载并安装哈希计算工具。
使用哈希工具处理文件。
将输出与文件的哈希进行比较。

另外，有一些工具可以使这一过程更容易，但你仍然需要处理源文件。一些供应商已经开始在其软件更新机制中执行哈希验证，但很难知道他们在这里具体做了什么以及是否有效。

哈希不仅用于验证下载文件的完整性，还可以确保软件物料清单中元素的有效性，查找恶意软件数据库中的组件哈希，并理解你所看到的证明是否真的与你认为的一致。许多逆向工程工具甚至会创建代码块或函数级别的哈希，以唯一标识函数，在某些工具中被称为函数ID（FIDs）。

然而，哈希可能非常脆弱，因为两个完全相同的文件在生成哈希的过程中，可能会由于生成方式或生成时间的不同而产生不同的哈希。一些典型的场景包括在构建过程中哈希一个组件，而不是在源代码中表示的组件。代码中的优化，如去除符号或特殊字符，可能会导致功能上相同但哈希不同的软件。甚至在Windows和Linux上创建的哈希也可能不同，具体取决于创建哈希时如何处理行尾字符。

法医学中出现的一种技术是哈希相似性，或使用距离算法进行哈希。像ssdeep和TLSH（https://tlsh.org）这样的哈希函数提供了一种手段，用于识别两个哈希何时非常相似，并且在试图识别不完全相同但足够接近以进行比较的独特软件组件时非常有用。

类似于哈希的概念是代码签名，这是一种通过受信实体加密签名代码或文件对象以验证他们生成该工件的技术。这是使用公钥加密完成的，其中签名者使用私钥证明其身份，任何人都可以使用公钥验证签名。

这是一个非常强大的机制，直到你意识到任何人都可以获得代码签名证书，如果验证者不验证签名文件的实体是否是他们期望看到的实体，这可能会导致一种虚假的安全感。在公钥加密的背景下，如果证书颁发机构被破坏，可能会使签名或对所颁发证书的信任失效。最后，我们已经看到几个场景，其中合法软件的签名加密材料被盗并嵌入到恶意文件中，或者实体被破坏并其私钥被盗。然而，如果需要使用时间戳机构（TSA），可以在一定程度上减轻这种风险。

一种出现并显示出希望的技术是通过签名链进行证明。例如，一个大的SBOM可能需要来自多个利益相关者的输入，或者我们可能希望将构建证明与SBOM链接。通过签署这些证明，我们创建了一个机制，可以进行多个证明的自动验证和链接，而无需单个实体了解SBOM的所有方面。

签名领域最新的创新之一是名为Sigstore的努力，它将在后续章节中详细讨论。

第二章传统的供应商风险管理

2.6总结

在本章中，我们讨论了一些与传统供应商风险评估、第一方与第三方证明挑战以及应用程序成熟度模型相关的历史背景。我们还讨论了一些常见的应用保障和安全措施工具和方法，以识别并促进缓解应用程序中的漏洞和缺陷。在下一章中，我们将深入探讨一些行业对漏洞评分、数据库及传统漏洞优先级方法的改进。

第三章漏洞数据库和评分方法

关于应用程序安全和漏洞管理的对话的一个关键方面是对漏洞进行分类和评分的方法。这是推动软件透明度的一个重要方面，更重要的是，软件安全。如果不了解存在哪些软件漏洞以及这些漏洞的评分方式，组织就很难确定漏洞的优先级以进行修复。软件生产商可以确定漏洞的优先级进行修复，以降低客户的风险，并告知客户其产品中漏洞的严重性和可利用性。软件消费者可以了解他们正在使用的软件的固有风险，并就其消费和使用做出风险知情决策。

第三章漏洞数据库和评分方法

3.1公共漏洞与暴露

“公共漏洞与暴露”（CVE）是一个项目，旨在识别、定义和编目公开披露的影响软件或硬件的网络安全漏洞。作为一个组织，CVE涉及国际研究人员和组织的参与，这些合作伙伴帮助发现和发布漏洞，并以标准化格式描述这些漏洞。CVE项目和概念的起源可以追溯到1999年1月由David Mann和Steven Christey撰写的一份MITRE白皮书，标题为“Towards a Common Enumeration of Vulnerabilities”（https://cve.mitre.org/docs/docs-2000/cerias.html）。这份白皮书描述了当时的网络安全格局，其中包括多个独立的漏洞数据库，它们具有独特的格式、标准和分类法。白皮书的作者解释了这如何影响互操作性和漏洞信息的共享。在互操作性的障碍中，他们提到了不一致的命名约定、管理来自不同来源的类似信息，以及数据库之间映射的复杂性。

为了促进安全软件工具之间的互操作性，提出了CVE作为一个标准化列表，帮助列举所有已知漏洞，分配标准的唯一名称，并且开放和共享没有限制。

这一努力在20多年的时间里已经成为行业的基石，来自35多个国家的200多个组织参与了这一项目，CVE系统收录了超过200,000个漏洞。参与组织被称为CVE编号授权机构（CNA；www.cve.org/PartnerInformation/ListofPartners）。CNA包括软件供应商、开源软件项目、漏洞赏金服务提供商和研究人员。它们被CVE项目授权，可以为漏洞分配唯一的CVE ID，并将CVE记录发布到CVE列表中。组织可以申请成为CNA，但必须满足特定要求，例如具有公开的漏洞披露政策、具有漏洞披露的公开来源，并同意CVE使用条款（www.cve.org/Legal/TermsOfUse）。

在第一章“软件供应链威胁的背景”中，我们讨论了国家漏洞数据库（NVD），尽管NVD和CVE之间有密切合作，但它们是不同的项目。CVE起源于MITRE，现在是一个由社区驱动的合作努力。而NVD由国家标准与技术研究所（NIST）发起。两个项目都由美国国土安全部和网络安全基础设施安全局（CISA）赞助，并免费供公众使用。CVE表现为一组漏洞记录，包括识别号码、描述和公开引用，而NVD是一个与CVE列表同步的数据库，以确保已披露的CVE和NVD记录之间的一致性。NVD提供了额外的信息，如修复方法、严重性评分和影响评级。NVD还通过高级元数据和字段使CVE可被搜索。

CVE由几个工作组组成，每个工作组都有不同的重点领域，包括自动化、战略规划、协调和质量。这些工作组致力于改进整个CVE项目并提升其对社区的价值和质量。除了工作组外，CVE还设有CVE项目委员会，以确保项目满足全球网络安全和技术社区的需求（www.cve.org/Resources/Roles/Board/General/Board-Charter.pdf）。该委员会负责监督项目，引导其战略方向，并在社区中推广。

一些与CVE项目相关的基本术语包括：

■ 漏洞
■ CVE标识符
■ 范围
■ CVE列表
■ CVE标识符
■ 范围CVE记录

CVE将漏洞定义为软件、固件或硬件中的缺陷，这些缺陷由于可以被利用而对受影响组件的机密性、完整性和可用性（CIA）三元组产生负面影响。CVE标识符（CVE ID）是由CVE项目分配给特定漏洞的唯一字母数字标识符，使得多个方可以自动化处理和共同讨论这些漏洞。范围是指CVE项目内的组织对特定硬件或软件集的独特责任。CVE列表是由CVE项目识别或报告的CVE记录的总目录。CVE记录提供与CVE ID相关的漏洞的描述性数据，由CNA提供。CVE记录可以是保留的、发布的或拒绝的。保留状态是指由CNA保留的初始状态，发布状态是指CNA填写数据后成为CVE记录的状态，拒绝状态是指CVE ID和记录不应再使用但仍在CVE列表中作为无效CVE记录的未来参考。

CVE记录也经历一个定义好的生命周期。这个生命周期包括发现、报告、请求、保留、提交和发布的阶段（见图3.1）。最初，某个组织发现一个新漏洞，向CVE项目或参与者报告，并请求一个CVE ID，该ID在保留期间由CVE项目参与者提交相关详细信息。最后，CVE记录被发布供公众下载和查看，以便在需要时开始适当的响应活动。

自CVE项目成立以来，CVE项目和CVE记录列表呈线性增长。根据发布的CVE记录统计数据（www.cve.org/About/Metrics），截至本文撰写时，每季度发布的CVE记录从几百个增长到超过6000个。这是由于项目的日益普及、安全研究人员的增加、软件供应商参与的增加以及网络安全的整体增长和可见性。

第三章漏洞数据库和评分方法

3.2国家漏洞数据库

漏洞有助于指导软件生产者和消费者降低风险，并为行业提供广泛的关于生态系统中存在的漏洞的知识。虽然行业中有多个漏洞数据库，但最著名的例子之一是NIST的国家漏洞数据库（NVD; https://nvd.nist.gov）。NVD是一个综合性的网络安全漏洞数据库，整合了所有公开的美国政府漏洞资源，并提供了对行业资源的引用。

NVD于2005年正式成立（https://nvd.nist.gov/general/brief-history）。NVD的起源可以追溯到1999年，其前身是互联网攻击工具分类（ICAT）。ICAT最初作为一个攻击脚本数据库开发，涉及SANS研究所的学生作为项目分析员。ICAT面临一些资金挑战，但在SANS以及NIST员工的努力下得以存续。在获得美国国土安全部（DHS）的一些额外资金后，ICAT发展到超过10,000个漏洞，最终被重新命名为NVD，成为如今的NVD。随着项目的发展，NVD采用了仍在使用的流行漏洞数据和评分系统，例如通用漏洞评分系统（CVSS）和通用平台枚举（CPE；https://nvd.nist.gov/products/cpe）。

截至本文撰写时，NVD包含超过200,000个漏洞，并且这个数字还在不断增长，因为新的漏洞不断出现。NVD被全球对漏洞数据感兴趣的专业人士以及希望关联漏洞发现及其详细信息的供应商所使用。

NVD通过分析已在CVE字典中发布的CVE来促进这一过程。通过参考CVE字典并进行额外分析，NVD的工作人员生成关于漏洞的重要元数据，包括CVSS评分、通用弱点枚举（CWE）类型和以CPE形式表示的适用性声明。值得注意的是，NVD工作人员不进行漏洞测试，而是利用供应商和第三方安全研究人员的见解和信息来创建这些属性。随着当前信息的出现，NVD经常修订元数据，例如CVSS评分和CWE信息。

NVD整合了来自CVE项目的信息，CVE项目是我们将在本章后面“CPE”部分讨论的漏洞字典。在NVD中集成新发布的CVE后，NVD通过严格的分析过程评估这些CVE，包括审查CVE的参考资料，这些参考资料涵盖了互联网上公开可用的信息。CVE被分配一个或多个CWE标识符，以帮助分类漏洞，并通过CVSS分配可利用性和影响指标。适用性声明通过CPE提供，以确保通过这些适用性声明识别特定版本的软件、硬件或系统。这有助于组织采取适当的行动，取决于漏洞是否影响他们正在使用的特定硬件和软件。一旦完成初步分析和评估，任何分配的元数据（如CWE、CVSS和CPE）都由高级分析师进行质量保证审核，然后发布在NVD网站和相关数据源上。

NVD提供丰富的数据源（https://nvd.nist.gov/vuln/data-feeds）和API（https://nvd.nist.gov/developers/start-here），供组织和个人获取已发布的漏洞数据。API允许相关方以更加自动化和可扩展的方式程序化地获取漏洞信息，而不是手动查看数据源。NVD API经常更新且可搜索，包括其他好处，如数据匹配，并且通常被安全产品供应商用来作为其产品提供的一部分，提供漏洞数据。

第三章漏洞数据库和评分方法

3.3软件标识格式

推动软件供应链安全性和软件透明度的一个基本方面是需要有效的方法来识别软件组件，包括拥有足够的信息来唯一地识别每个软件组件。然而，这种需求远不是一个微不足道的问题，因为软件领域由数千个不同的软件供应商、部门和社区组成。美国国家电信和信息管理局（NTIA）在他们的“软件识别挑战和指导”白皮书（www.ntia.gov/files/ntia/publications/ntia_ sbom_software_identity-2021mar30.pdf）中关注了这个问题，该白皮书是通过NTIA的多利益相关者过程产生的。NTIA指出，有必要在短期内功能性地识别软件组件，但也需要在未来使多个现有的识别系统实现合理化。这样做将缓解一些挑战，并帮助行业围绕一个统一的解决方案进行反弹。为了控制围绕软件组件识别的一些混乱，NTIA建议尽可能使用现有的识别系统，但指出这并不总是可能的，这导致一些人不得不使用“尽最大努力”的识别方法。

尽管整个行业的软件生产商和消费者都在广泛推动采用和集成软件材料清单（SBOM），但关于SBOM组件的识别，目前还没有权威的消息来源。软件供应商通常根据其组织和相关活动的需要来定义和识别软件组件。组件识别不是一个静态事件，而且可能会由于分叉和采用项目和组织收购等因素而改变，因此这个问题可能会进一步加剧。

综上所述，有一些主要的软件识别标准被行业和NTIA认可，如cpe、软件标识标签（SWIDs）和软件包url（PURLs），我们接下来将快速查看它们。

CPE

通用平台枚举（CPE）是一种结构化的命名方案，用于描述和识别跨企业IT资产的应用程序、操作系统和硬件设备的类别。最初由NIST（www.govinfo.gov/content/pkg/GOVPUB-C13-5d78ccf04a5285bc768fb03ea45 dd6bb/pdf/GOVPUB-C13-5d78ccf04a5285bc768fb03ea45dd6bb.pdf），CPE于2011年8月发布，已经经过了几次迭代，截至本文时最新版本为2.3（https://cpe.mitre.org/specification）。CPE解决了以标准化的方式引用IT产品和平台的需求，同时对于处理和自动化也是机器可读的。NIST维护一个CPE字典（https://csrc.nist.gov/Projects/Security-Content-Automation-Protocol/Specifications/cpe/字典），它作为一个商定的CPE名称列表。它有XML格式，可供公众消费和使用。

最新的CPE规范，2.3，将CPE标准分解成一个堆栈中的一套单独的规范，其中包括以下内容：

■名称
■名称匹配
■字典
■适用性语言

该名称是CPE规范的基础，用于定义为IT产品类分配名称的标准化方法。名称匹配用于定义一种将源CPE名称与目标CPE名称进行一对一比较的方法。它决定了两个实体之间是否存在公共关系。例如，IT资产管理工具可以收集有关系统上安装的软件的信息，并识别已安装或存在的特定软件。该字典定义了创建和管理CPE字典的标准化方法，这些字典是CPE名称及其相关元数据的存储库。堆栈中的最后一个规范是适用性语言，它通过形成组成的CPE名称和引用的复杂逻辑表达式，定义了一种描述IT平台的标准化方式。CPE规范提供的一个例子是一个操作系统，如Windows XP，它运行微软Office 2007，以及操作系统上的一个特定配置，如有源无线网卡。

软件标识标签

软件标识（SWID）标记是由国际标准化组织认可的一种格式，是一种用于描述软件产品（https://csrc.nist.gov/projects/softwareidentification-swid/guidelines）的结构化元数据格式。SWID使用数据元素来识别软件产品，以及在产品生产和分发中发挥角色的产品版本、组织或个人，以及软件产品组成的工件。一些软件资产管理和安全流程将SWID作为活动的一部分，如对软件资产的漏洞评估、丢失的补丁程序或特定的配置管理评估。它还可以用作验证软件完整性的一部分，或作为安全操作活动的一部分。

NIST在其出版物NISTIR 8060“创建可互操作的软件标识（SWID）标签的指南”（https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf）中详细描述了使用SWID标签。NTIA还在其出版物“现有SBOM格式和标准的调查”（www.ntia.gov/files/ntia/publications/sbom_ formats_survey-version-2021.pdf）中讨论了SWID。SWID标签被各种标准机构使用，如可信计算组（TCG）和互联网工程特别工作组（IETF）。作为一个标准，SWID帮助定义一个软件产品的生命周期。SWID使用了四种类型的标签：

■ 基础
■ 补丁
■ 数据
■ 补充

基础标签用于识别和描述安装在计算设备上的软件产品，而补丁标签表示对已安装的软件产品进行的增量更改。数据标签表示处于预安装状态的可安装软件产品，例如有关安装软件包或软件更新的元数据。补充标签可用于向任何被引用的SWID标签添加信息。软件管理工具可以使用它们来添加元数据，而不改变其他标记格式。要可视化SWID标签的生命周期功能，请参见图3.2，它显示了前面提到的NTIA出版物中的一个示例。

虽然我们在SBOM格式的讨论中加入了SWID，但SWID并没有像其他主要SBOM格式(例如SPDX和CycloneDX)那样收到同等关注，因为它主要侧重于软件识别作为主要用例，并且缺乏其他格式提供的丰富的上下文。但是，需要注意的是，CycloneDX原生支持SWID进行软件识别。

PURL

软件包URL（PURL; https://archive.fosdem.org/2018/schedule/event/purl/attachments/slides/2298/export/events/attachments/purl/slides/2298/meet_purl_FOSDEM_2018_narrow.pdf）可帮助解决与软件包命名约定和协议相关的问题。现代软件开发涉及消耗和生产大量的软件包，如NPM和Ruby gem。然而，在涉及到软件包的识别、位置和供应时，每个包管理器和生态系统都使用不同的命名约定和方法。

为了解决这一挑战，nexB（www.nexb.com）--他们开发ScanCode和VulnerableCode、软件组成分析（SCA）和免费和开源软件（FOSS）安全扫描工具--开发了PURL规范（https://github.com/package-url/purl-spec）。PURL项目的目标是标准化在软件包管理器、工具和更广泛的软件生态系统中识别和定位软件包的方法。PURL由六个数据元素组成：

■方案
■类型
■命名空间/名称
■版本
■限定符
■子路径

有些元素是可选的，而其他元素则是必需的。这最终会形成一个URL字符串，比如pkg:bitbucket/birkenfeld/pygmentsmain@244fd47e07d1014f0aed9c. scheme是pkg常定的URL方案。Type是指示程序包类型的必需元素，如maven或NPM。命名空间，如Maven和Docker，是一个可选的元素。名称是显示程序包名称的必需字段；版本是一个可选的数据元素。限定符提供了额外的上下文，如操作系统、体系结构或分布，而子路径可以识别包中的其他子路径；这两个元素也都是可选的。

PURL最初是在FOSDEM 2018等活动上展示的。自成立以来，它现在被许多人认为是一个事实上的标准，用于包url的项目，如领先的SBOM格式CycloneDX和SPDX，OSS索引，和世界各地的其他组织。

开放全球应用程序安全项目（OWASP）、Linux基金会和Oracle等人的成员也已经开始努力让NVD采用PURL，以改进漏洞管理（https://owasp.org/blog/2022/09/13/sbom-forumrecommends-improvements-to-nvd.html）的自动化和组件识别.一个被称为SBOM论坛的组织，由供应链顾问和博客主 Tom Alrich（http://tomalrichblog.blogspot.com）领导，发表了一篇题为“操作脆弱性管理的组件识别的建议”的论文（https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20 Identification%20for%20Vulnerability%20Management.pdf）.在该文中，作者指出了命名问题，即开源产品或组件在不同的包管理器和注册表之间具有不同的名称。为了在漏洞识别和修复方面更有效，组织需要为软件组件制定一个标准化的命名约定。

NVD目前对软件产品使用CPE名称；然而，CPE命名约定带来了各种挑战，阻碍了与软件安全相关的自动化工作。NVD中的cpe主要通过供应商、产品和版本字符串来识别软件和硬件组件。NVD采用PURL有可能缓解与CPE使用相关的一些挑战，并促进改进的软件识别，以及帮助与SBOM采用和自动化相关的工作。

第三章漏洞数据库和评分方法

3.4 Sonatype OSS索引

随着OSS的采用不断增长，并日益对现代应用程序和产品的重要部分做出贡献，人们越来越需要了解与OSS组件相关的风险。超声型OSS指数已经成为一个帮助解决这个问题的著名来源。该索引提供了数百万个OSS组件的免费目录，以及组织可以使用这些扫描工具来识别OSS组件的漏洞和相关的风险，并降低组织的风险。OSS索引还提供了补救建议，与NVD一样，它有一个健壮的API，用于作为集成的扫描和查询的一部分。NVD和OSS索引之间的一个关键区别是使用了PURL而不是CPE。NVD使用CPE来唯一地识别受漏洞影响的脆弱产品，而OSS索引则使用PURL规范来描述组件或软件包的坐标。

除了能够搜索OSS组件并找到与漏洞相关的任何信息外，OSS索引还支持扫描项目的OSS漏洞，并通过索引的代表性状态传输（REST）应用程序编程接口（API）与现代连续集成/连续交付（CI/CD）工具链进行集成。作为更广泛的推动“安全左移”的一部分，将安全移到软件开发生命周期(SDLC)的早期，这种工具链和构建时集成有助于在将代码部署到生产运行时环境之前识别OSS组件中的漏洞。OSS索引API集成被许多流行的扫描工具用于各种编程语言，如Java Maven插件、Rust Cargo Pants、OWASP依赖检查和Python的ossaudit等。值得注意的是，虽然OSS索引对社区使用是免费的，但它也不包括任何特别策划的情报或来自专家的见解。然而，Sonatype确实提供了其他服务来提供额外的智能、管理库和提供自动化功能。

第三章漏洞数据库和评分方法

3.5 开源漏洞数据库

2021年，谷歌安全发布了（https://security.googleblog.com/2021/02/ launching-osv-better-vulnerability.html）开源漏洞（OSV）项目（https://osv.dev），目的是“改善对开源软件的开发者和消费者的漏洞分类”。该项目源于谷歌安全早期的“了解、预防、修复”项目(https://opensource.googleblog.com/2021/02/know-prevent-fix-frameworkfor-shifting-discussion-around-vulnerabilities-in-open-source.html).OSV致力于提供有关漏洞产生和修复位置的数据，以使软件消费者能够了解漏洞的影响以及如何降低风险。OSV的目标是最小化维护人员发布漏洞所需的工作量，并提高下游消费者的漏洞查询的准确性。OSV通过强大的API和查询漏洞数据，为开源软件包消费者自动执行分类工作流程。它还降低了软件维护人员试图提供可能影响下游消费者的提交和分支中受影响版本的准确列表所产生的开销。

谷歌安全发布了一些博客，展示了OSV如何将SBOM与漏洞连接起来，因为OSV能够以一种专门为映射到开源包版本和提交散列而设计的格式来描述漏洞。它还收集了来自各种来源的信息，如GitHub咨询数据库（GHSA）和全球安全数据库（GSD）。甚至还有一个称为spdx-osv（https://github.com/spdx/spdx-to-osv）的工具，它从软件包数据交换（SPDX）文档中列出的信息创建一个OSS漏洞JavaScript对象表示法（JSON）文件。

OSV不仅仅是一个在OSV.dev上可用的数据库；它也是一种模式和OSV格式。OSV指出，有许多漏洞数据库，但没有标准化的交换格式（https://ossf.github.io/osv-schema）。如果组织希望拥有广泛的漏洞数据库覆盖，他们必须使每个数据库都有自己独特的格式和模式。这一问题阻碍了软件消费者采用多个数据库，并阻碍了软件生产者将其发布到多个数据库。OSV旨在提供一种所有漏洞数据库都可以围绕的格式，并允许它们之间实现更广泛的互操作性，并减轻希望使用多个漏洞数据库的软件消费者、生产者和安全研究人员的负担。OSV以基于JSON的编码格式运行，具有各种字段细节，如ID、已发布、撤回、相关、摘要和严重性等，包括子字段。

第三章漏洞数据库和评分方法

3.6 全球安全数据库

尽管 CVE 计划得到了广泛采用，但许多人指出该计划存在问题，其方法以及无法跟上动态技术格局。随着云计算的兴起，云安全联盟 (CSA；https://cloudsecurityalliance.org) 等组织已成为现代云驱动 IT 时代指导和研究的知名行业领导者。CSA 的显著努力之一是创建全球安全数据库 (GSD)，它将自己描绘成解决现代问题的现代方法，声称 CVE 是一种过时的方法，没有跟上现代复杂的 IT 格局。这项工作由 Josh Bressers 和 Kurt Seifried 牵头，他们在 Red Hat 都拥有丰富的漏洞识别和治理经验和专业知识，而 Kurt 甚至还在 CVE 董事会任职。

在 CSA 博客文章《我们为何创建全球安全数据库》（https://cloudsecurityalliance.org/blog/2022/02/22/why-we-created-the-global-security-database）中，Kurt 列举了创建 GSD 的几个原因，以及 CVE 等其他计划未能达到预期的原因。该博客追溯了漏洞识别的起源，早于 CVE 的 BugTraq ID 计划，该计划要求相关方订阅并阅读可用的漏洞信息。他描述了 CVE 计划的发展，最初每年只有一千个左右的发现，在 2011 年开始下降之前达到 8,000 个 CVE 的峰值。正如我们之前讨论的那样，本文还展示了 CNA 的增长。然而，尽管 CNA 数量增长，但 Kurt 指出，近 25% 的 CNA 至少一年没有活动。 2017 年，发布和分配的 CVE 数量达到峰值，除了 2020 年的激增外，CVE 分配活动一直保持平稳，如图 3.3 所示。

本文介绍了 Josh 和 Kurt 参与的早期工作，例如分布式弱点归档项目，并讨论了 Linux 内核如何参与这项工作。Linux 项目拒绝与 CVE 计划合作，Greg Kroah-Hartman 在题为“2019 年内核配方 — CVE 已死，CVE 万岁！” (www.youtube.com/watch?app=desktop&v=HeeoTE9jLjM) 的演讲中对此进行了详细讨论。在该视频中，Greg 指出，由于应用和反向移植给用户的修复程序数量众多，CVE 计划与 Linux 内核配合不佳。Greg 解释了 Linux CVE 的平均“修复请求”时间线为 100 天，表明对 Linux 内核 CVE 缺乏关注，从更广泛的层面来看，Linux 项目的进展速度太快，无法适应严格管理的 CVE 流程。

GSD 公告描述了服务如何“吞噬世界”，现代软件和应用程序绝大多数都是以服务形式提供的，鉴于云计算以各种模式激增，这一点很难反驳，但最明显的是软件即服务 (SaaS) 等应用程序。作者解释了 CVE 计划在涵盖即服务应用程序方面缺乏连贯的方法。“吞噬世界”的评论是指之前的口头禅，即软件已经吞噬世界，但现在世界上许多软件都是以服务形式提供的。

在作者和GSD领导引用的其他变化中，还有像Python（20万）或NPM（130万）等软件包的迅猛增长。还有一种观点认为，CVE项目缺乏透明度、社区访问、参与度，并且缺乏与使用OSS软件包的供应商相关的数据，例如Log4j。

如果您有兴趣参与开放且由社区驱动的 GSD 工作，您可以在 GSD 主页 (https://globalsecuritydatabase.org) 或 Slack 或邮件列表 (https://groups.google.com/a/groups.cloudsecurityalliance.org/g/gsd?pli=1) 等通信渠道上了解更多信息。

第三章漏洞数据库和评分方法

3.7 公共漏洞评分系统

虽然CVE计划提供了一种识别和记录漏洞的方法，NVD丰富了CVE数据并将其呈现在一个强大的数据库中，但通用漏洞评分系统（CVSS）则评估安全漏洞的严重性并分配严重性分数。CVSS致力于捕捉软件、硬件和固件漏洞的技术特性。它提供了一种平台和供应商无关的行业标准化评分方法，并且在分数来源的特性和方法方面完全透明。

CVSS起源于国家基础设施咨询委员会（NIAC）在2000年代初期的研究，CVSS版本1于2005年初问世。虽然NIAC的研究导致了CVSS的创建，但在2005年，NIAC选择了事件响应和安全团队论坛（FIRST）来领导和管理未来的CVSS计划。FIRST是一个位于美国的非营利组织，为计算机安全事件响应团队提供资源，如CVSS。虽然CVSS由FIRST拥有和运营，但其他组织可以在遵循FIRST CVSS规范指导的前提下使用或实施CVSS。CVSS经历了几次迭代，最初的CVSS在2005年初发布，CVSS v2于2007年发布，CVSS v3于2015年发布。截至本文写作时，CVSS已更新到v3.1规范。CVSS由三个核心指标组组成，如图3.4所示。

如前所述，CVSS由三个指标组组成：基本指标、时间指标和环境指标。漏洞的严重性基于固有特性，这些特性在假定最坏情况的情况下保持不变，无论部署环境如何。另一方面，时间指标调整基本分数，考虑随时间变化的因素，包括漏洞利用工具的实际可用性。环境指标根据计算环境的具体情况调整基本和时间严重性分数，包括减少风险的缓解措施的存在。

基本分数由产品所有者或第三方（如安全研究人员）分配。这些分数/指标在分配后保持不变，因此会被发布。由于发布方不会拥有托管或操作环境的全部背景信息以及潜在的缓解控制措施，因此CVSS消费者可以根据需要通过时间和环境分数来调整分数。成熟的组织通过基于这些因素进行调整，能够更好地优先处理漏洞管理活动，基于更准确的风险计算，考虑到其具体环境和所涉及的控制措施。

深入探讨每个指标组，基本指标组涉及随时间一致的固有特性，除非有新信息出现，无论该组存在于何种环境中。基本指标组包括可利用性指标和影响。可利用性指标包括攻击向量、攻击复杂性以及所需权限等。这些指标围绕一个易受攻击的组件及其被利用的难易程度。另一方面，影响指标使用传统的网络安全CIA三元组（机密性、完整性和可用性），这涉及漏洞被利用的后果以及对易受攻击组件的影响。

基本指标

基本指标做出了一些假设，例如攻击者对系统及其防御机制的了解。截至本文写作时，CVSS 3.1是现行版本，而CVSS 4.0正在开发中。我们的讨论将基于CVSS 3.1的视角。正如之前提到的，基本指标还包括特定于可利用性和影响的指标。在可利用性指标中，有攻击向量和复杂性、所需权限、用户交互和范围等因素。

攻击向量指标旨在提供关于恶意行为者可能使用的攻击方法的背景。由于需要物理接近才能进行攻击的情况较少，因此攻击向量的评分受到影响。攻击向量指标包括网络、邻接、本地或物理等值。从网络角度来看，攻击向量可能绑定到本地网络、远程可利用性，甚至可能涉及整个互联网。而邻接则绑定到特定的物理或逻辑范围，例如共享蓝牙网络/范围或在同一局域子网中。本地涉及访问系统键盘或控制台，但也可能包括远程SSH访问。本地还可能需要用户交互，例如通过网络钓鱼攻击和社会工程。最后，物理指标值意味着恶意行为者需要物理访问易受攻击的组件才能利用漏洞。

虽然攻击向量指标基于攻击者可用的路径和方法，但攻击复杂性涉及超出恶意行为者控制的条件，可能包括易受攻击组件上存在的特定配置。攻击复杂性分为低或高。低复杂性指的是允许恶意行为者反复成功利用易受攻击组件的情况，而高复杂性则更复杂，可能需要恶意行为者收集知识、准备目标环境或插入网络路径，例如使用路径攻击。

所需权限指标描述了攻击者必须具备的权限级别才能成功利用漏洞。在不需要任何权限的情况下，基本分数会最高；而在需要恶意行为者具备管理员级别访问权限的情况下，分数会较低。所需权限的值包括：

■ 无：不需要访问系统或组件

■ 低：需要基本用户权限

■ 高：需要管理员级别的权限才能利用漏洞

用户交互指标描述了除恶意行为者外的其他用户需要进行的操作，以使漏洞成功利用。一些漏洞可以在没有其他用户参与的情况下成功利用，而其他漏洞则需要额外用户的参与。此指标非常简单，可能值为“无”或“需要”。

最后一个可利用性指标是范围，描述了易受攻击组件的利用是否可能超出其自身的安全范围并影响其他资源和组件。该指标要求了解易受攻击组件对其他资源的影响范围，更基本地说，需要了解哪些组件最初在其管理权限之下。范围的两个指标值是“未改变”和“已改变”，表示利用对其他安全权限管理的组件的影响程度。

在基本指标中，还有影响指标，以传统的CIA三元组（机密性、完整性和可用性）表示。CVSS建议分析人员将其影响预测合理地与恶意行为者可能造成的实际影响保持一致。如果你熟悉NIST风险管理框架对CIA的指导，你会注意到两者的相似之处。CIA指标值包括无、低或高。无意味着对CIA没有影响，低意味着对CIA有一定程度的损失，高意味着对CIA的完全损失以及在特定场景下漏洞利用所能造成的最严重影响。

时间指标

正如之前提到的，时间指标会随着时间的推移而变化，例如活跃的漏洞利用会提高分数，而可用的补丁会降低CVSS分数。请记住，这些因素与行业相关，而不是特定用户的环境或某个组织可能已实施的特定缓解措施。时间指标包括漏洞利用代码成熟度、补救水平和报告可信度。

漏洞利用代码成熟度基于相关利用技术的当前状态和可用于利用漏洞的代码的可用性。这通常被称为“野外利用”，一个显著的例子是CISA的“已知利用漏洞目录”（Known Exploited Vulnerabilities Catalog，www.cisa.gov/known-exploited-vulnerabilities-catalog），该目录定期更新已知被积极利用的漏洞，联邦机构需要修补这些已知的可利用漏洞。该列表已包含数百个漏洞以及适用于许多组织的各种软件和硬件利用方法。随着新漏洞被发现和确认，该列表会定期更新。漏洞利用代码成熟度指标包括未证明（unproven）、概念验证（proof-of-concept，PoC）、功能性（functional）、高级（high）和未定义（not defined）。这些指标代表了从没有利用代码或仅为理论性的情况，到完全功能化且自动化且不需要手动触发的情况。

补救水平指标有助于驱动漏洞优先级排序工作，涉及通过可用的官方修复方案进行的临时解决方案。潜在的指标值包括不可用（unavailable）、临时解决方案（workaround）、临时修复（temporary fix）和官方修复（official fix）。修复漏洞可能是可行的，或者需要非官方的临时解决方案，直到发布、验证并验证为可消费和实施的官方修复方案。

最后一个时间指标，报告可信度，涉及漏洞报告及其相关技术细节的实际可信度。初步报告可能来自未经验证的来源，但可能会逐渐被供应商或信誉良好的安全研究人员验证。潜在的指标值包括未知（unknown）、合理（reasonable）和确认（confirmed），代表了对报告的漏洞和细节的信心逐渐增加。这些因素会影响漏洞的整体评分。

环境指标

对于组织特定的背景，这是环境指标发挥作用的地方。由于每个环境都是独特的，并且有一系列可能影响环境评分的因素，如技术堆栈、架构和特定的缓解控制措施，每个软件消费者的环境指标都会有所不同。

环境指标帮助组织根据其操作环境的特定因素调整基本分数。这些修改围绕CIA三元组（机密性、完整性和可用性），允许分析人员根据每个CIA方面在组织业务功能或使命中所扮演的角色分配相应的值。修改后的基本指标是由于用户环境的具体情况而覆盖基本指标的结果。值得注意的是，这些修改需要对基本和时间指标因素有详细的了解，以进行准确的修改，从而不会低估漏洞对组织构成的风险。

CVSS 评分尺度

CVSS 使用一个定性的严重性评级尺度，范围从 0.0 到 10.0，如图 3.5 所示。

所有不同的 CVSS 评分指标和方法都会生成一个称为向量字符串的内容，CVSS 规范将其定义为“一种特定格式的文本字符串，包含分配给每个指标的每个值，并应始终与漏洞评分一起显示。” 向量字符串由指标组、指标名称、可能的值以及它们是否是必选项组成。这最终形成一个向量字符串，例如“攻击向量：网络，攻击复杂性：低，所需权限：高，用户交互：无，范围：未改变，机密性：低，完整性：低，可用性：无。”

计算这些指标需要详细了解可能的字段、值和其他因素。我们强烈建议您访问 CVSS v3.1 规范文档，以了解更多关于公式和指南的信息（www.first.org/cvss/v3.1/specification-document）。

批评意见

尽管CVSS被广泛使用和采用，但它也有其批评者。安全研究员和作家Walter Haydock在他的“Deploying Securely”博客（www.blog.deploy-securely.com）中的文章《CVSS：评估风险的不合适行业标准》（www.blog.deploy-securely.com/p/cvss-an-inappropriate-industry-standard）中，对CVSS提出了批评。Walter认为CVSS不适合评估网络安全风险。他引用了多篇行业领袖的文章，这些文章表明，尽管行业广泛使用CVSS进行风险评估，但单独使用CVSS进行风险评估并不恰当（https://pt-br.tenable.com/blog/why-you-need-to-stop-using-cvss-for-vulnerability-prioritization）。

正如Walter的文章以及其他文章所指出的，CVSS通常被用来帮助组织根据漏洞的利用难度和可能的影响程度来优先处理漏洞。像Tenable这样的组织的研究指出，不论这些漏洞是否可能被利用，CVSS评分为高或严重的漏洞中有超过50%从未被利用（https://pt-br.tenable.com/research）。研究表明，所有被评为高或严重的漏洞中，有75%从未实际有已知的利用代码发布，但安全团队仍然优先处理这些漏洞。这意味着，组织可能在浪费有限的时间和资源，优先处理不太可能甚至从未被利用的漏洞，而不是解决那些具有活跃利用代码的漏洞。

由于采用这种笼统的方法追踪CVSS评分为高和严重的漏洞，组织可能忽视了大量评分在4到6之间且具有活跃利用代码的漏洞，从而错失了大量风险。这是可以理解的，因为组织通常需要处理数百甚至数千个资产，这些资产通常与许多漏洞相关。当你淹没在大量漏洞数据中时，很难追踪和进行细致的漏洞管理，更不用说清楚了解哪些资产属于你的组织并构成风险。

要更深入了解CVSS，可以查看NIST发布的内部报告8409《衡量通用漏洞评分系统基本评分公式》（https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8409.pdf）。

第三章漏洞数据库和评分方法

3.8 漏洞预测评分系统

基于对CVSS的批评，一些人呼吁使用漏洞预测评分系统（Exploit Prediction Scoring System, EPSS）或将CVSS与EPSS结合，以使漏洞指标更具可操作性和效率。与CVSS类似，EPSS也由FIRST管理。EPSS以其开放和数据驱动的努力为荣，旨在估计软件漏洞在野外被利用的概率。CVSS关注漏洞的固有特性，最终形成严重性评分。然而，仅仅依靠严重性评分并不能表明漏洞被利用的可能性，而这对于需要优先处理漏洞修复和缓解工作的漏洞管理专业人员来说是至关重要的信息，以最大限度地减少组织风险。

EPSS有一个面向公众开放的特别兴趣小组（SIG），欢迎那些对参与该项目感兴趣的人加入。EPSS由志愿者驱动，由研究人员、安全从业者、学术界和政府人员领导，但FIRST拥有根据组织需要更新模型和相关指导的权利，尽管这是一个行业协作的方式。目前，该小组拥有来自RAND、Cyentia、弗吉尼亚理工大学和Kenna Security等组织的主席和创建者。EPSS有几篇论文深入探讨了相关主题，如攻击预测、漏洞建模和披露以及软件利用（www.first.org/epss/papers）。

第三章漏洞数据库和评分方法

3.9 EPSS模型

EPSS旨在帮助安全从业者及其组织改进漏洞优先级排序工作。在当今的数字环境中，识别出的漏洞数量呈指数增长，这一数量因系统和社会的数字化程度提高、对数字产品的审查增加以及研究和报告能力的提高而不断增加。EPSS指出，组织每月只能修复5%到20%的漏洞。实际上，已发布的漏洞中只有不到10%被确认曾在野外被利用。长期以来的劳动力问题也在发挥作用，例如年度（ISC）2网络安全劳动力研究（www.isc2.org/News-and-Events/Press-Room/Posts/2021/10/26/ISC2-Cybersecurity-Workforce-Study-Sheds-New-Light-on-Global-Talent-Demand），显示全球网络安全专业人员短缺超过200万人（见图3.6）。

这些因素使得组织需要一个连贯且有效的方法来优先处理带来最高风险的漏洞，以避免浪费有限的资源和时间。EPSS模型通过创建漏洞在接下来的30天内被利用的概率评分来提供支持，评分范围在0到1之间，即0%到100%。为了提供这些评分和预测，EPSS使用来自各个来源的数据，如MITRE CVE列表、关于CVE的发布日期数据，以及来自AlienVault和Fortinet等安全供应商的野外利用活动观察数据。

EPSS团队发布的数据支持其使用不仅仅是CVSS评分，还包括EPSS评分数据的做法，以实现更有效的漏洞修复。例如，许多组织规定，CVSS评分达到或高于特定值（如7或以上）的漏洞必须修复。但这种方法仅基于CVSS评分优先处理漏洞修复，而不考虑漏洞是否已知被利用。将EPSS与CVSS结合使用更为有效，因为这样组织可以根据漏洞的严重性评分以及它们是否已知被积极利用来优先处理漏洞，使组织能够处理对其构成最大风险的CVE。

EPSS关注两个核心指标：效率和覆盖率。效率指标评估组织在使用资源修复漏洞方面的能力。EPSS指出，大部分组织的资源花在修复已知被利用的漏洞上比随机修复仅基于CVSS严重性评分的漏洞更有效。覆盖率指标评估被修复的漏洞中已被利用的漏洞的百分比。

为了展示其提出的方法的效率，EPSS在2021年使用CVSS v3基本评分、EPSS v1和EPSS v2数据进行了研究。他们考虑了一个30天的时间段，以确定CVE的总数、修复的CVE数量和被利用的CVE数量。正如图3.6所示，几个事实显而易见。首先，大多数CVE根本没有被修复。其次，被修复的CVE中，被利用的CVE仅是其中的一部分。这意味着组织没有修复大多数CVE，而在他们修复的CVE中，许多并没有被积极利用，可能不会带来最大的风险。这也表明，EPSS v2通过最大化被修复的已被利用的漏洞的百分比，进一步提高了漏洞修复工作的效率。当组织在网络安全从业人员方面面临资源挑战时，通过让资源集中在对组织构成最大风险的漏洞上，最大化投资回报至关重要。EPSS试图帮助组织更有效地利用有限的资源，提高降低组织风险的效果。

第三章漏洞数据库和评分方法

3.10 EPSS的批评意见

与CVSS类似，EPSS也受到业界和学术界的批评。卡内基梅隆大学软件工程研究所（SEI）博客上的一篇文章《Probably Don’t Rely on EPSS Yet》（https://insights.sei.cmu.edu/blog/probably-dont-rely-on-epss-yet）对EPSS提出了质疑。SEI最初发布了一篇题为《Towards Improving CVSS》的论文，对CVSS进行了尖锐的批评，EPSS便是在该论文发布后不久推出的（https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=538368）。

文章提出的一些主要批评包括EPSS的不透明性及其数据和输出问题。文章讨论了EPSS的开发过程、治理或目标受众如何被决定的方面尚不清楚。文章指出，EPSS依赖于现有的CVE ID，这意味着EPSS对软件供应商、事件响应团队或漏洞奖励小组等实体没有帮助，因为这些小组处理的许多漏洞尚未获得CVE ID，且可能永远不会获得。此外，EPSS在处理零日漏洞时也无济于事，因为这些漏洞在被利用时才获得关注，而没有已知的关联CVE ID。

文章的作者还对EPSS的开放性和透明性提出了担忧。尽管EPSS自称是一个开放和数据驱动的努力，并且如前所述还有一个特别兴趣小组（SIG），但EPSS及其管理组织FIRST仍然保留在任何时候更改网站和模型的权利，无需解释。实际上，即使是SIG成员也无法访问用于底层EPSS模型的代码或数据。SIG本身对模型没有监督或治理权，而模型更新或修改的过程对SIG成员乃至公众都不透明。文章指出，由于EPSS由FIRST管理，EPSS模型和数据也可能被从公共贡献和使用中撤回。

文章表明，EPSS专注于预测漏洞在接下来的30天内被利用的可能性。但要做出这种预测需要一些基本的条件。这些条件包括NVD中已有的CVE ID并且具有相关的CVSS v3向量值、与CVE ID关联的活跃利用尝试的入侵检测系统（IDS）签名、来自AlienVault或Fortinet的数据贡献（它们向EPSS提供数据），以及与未来30天相关的模型。正如作者指出的，只有10%的具有CVE ID的漏洞有伴随的IDS签名，这意味着90%的具有CVE ID的漏洞在利用时可能不会被检测到。这也导致对Fortinet和AlienVault的IDS传感器及相关数据的依赖，可以通过更广泛的安全供应商社区的进一步参与来缓解。

第三章漏洞数据库和评分方法

3.11 CISA的观点

随着关于漏洞优先级排序和管理的讨论日益激烈，像CISA这样的组织也对此发表了看法。2022年11月发表的一篇题为《Transforming the Vulnerability Management Landscape》的文章（www.cisa.gov/blog/2022/11/10/transforming-vulnerability-management-landscape）中，CISA执行助理主任Eric Goldstein讨论了现代数字环境的复杂性和漏洞加速出现的速度。

根据文章，CISA提出了推动漏洞管理生态系统进步的三个关键步骤：

扩大通用安全咨询框架（CSAF）的使用，提供自动化的机器可读安全咨询
增强漏洞利用交换（VEX）的采用，帮助软件消费者了解特定产品何时受可利用漏洞的影响
通过使用利益相关者特定漏洞分类（SSVC）和CISA的已知利用漏洞（KEV），帮助组织优先安排漏洞管理资源

我们将在本节中更详细地讨论这些步骤。

通用安全咨询框架（CSAF）

CISA列表中的首项是使用CSAF来自动化生成机器可读的安全咨询。正如CISA指出的，每当发现并披露一个新漏洞时，软件供应商必须评估其产品并验证是否适用，如果适用，决定如何修复并将此信息传达给其客户群体。在供应商进行这些工作的同时，恶意行为者也在积极寻找机会利用漏洞，可能在供应商能够直接修复（例如SaaS环境）或发布补丁并由终端用户应用之前（例如传统的本地软件）。随着漏洞发现和披露速度的加快，尤其是与CVE相关的漏洞，迫切需要自动化和加速这一活动，以便将信息迅速传达给软件消费者，这正是机器可读性和自动化的作用所在。

CSAF由OASIS通用安全咨询框架（CSAF）技术委员会领导。OASIS是一个非营利联盟，帮助创建和推广各种最佳实践和标准。OASIS提供了一些优秀的资源供那些想要了解CSAF的人使用，包括他们的“什么是通用安全咨询框架（CSAF）？”视频（www.youtube.com/watch?app=desktop&v=vQ_xY3lmZOc）或非常全面的CSAF 2.0规范（https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html）。

根据规范的定义，“CSAF支持创建、更新和互操作交换安全咨询，作为产品、漏洞及其影响和缓解状态的结构化信息。”这些咨询以JSON格式提供。

传统上，安全咨询以静态文档形式发布，如PDF文件和网站，供人类阅读。其挑战在于漏洞发现和披露速度加快，以及在恶意行为者利用漏洞之前进行修复的竞赛，使得机器和自动化的需求变得至关重要。这种情况与其他网络安全领域有许多相似之处，这些领域也越来越多地采用机器可读的工件，例如使用开放安全控制评估语言（OSCAL）的治理风险与合规（GRC）工具和基础设施即代码及合规即代码的传统IT。现代技术环境变化太快，人类无法作为中介来应对。

CSAF还致力于提供一套强大的工具（https://oasis-open.github.io/csaf-documentation），如CSAF解析器、可视化工具、可信提供者和聚合器等。值得注意的是，截至本文写作时，这些工具仍在开发中，可能缺乏某些功能，例如CSAF解析器尚不支持CSAF 2.0。这些工具每个都配有GitHub存储库、文档和代码库，以帮助组织和采用者更好地利用CSAF并将其作为其网络安全和漏洞管理活动的一部分，无论是作为软件消费者还是生产者。

CSAF架构文档主要涉及三类信息：

■文档的框架、聚合和参考信息

■CSAF咨询创建者认为相关的产品信息

■与所讨论产品相关的漏洞信息

CSAF还原生支持引用用于平台数据、漏洞分类和评分等行业标准化内容的架构。例如CPE、CVSS和CWE，每个都有一个用于使用的架构。

通过这一基本概述，很容易看出CSAF如何帮助引入一个机器可读安全咨询的时代，这些咨询可以自动化并有助于加速创建、分发和接收安全咨询，从而惠及软件提供商和消费者，并在软件生态系统中做出关于网络安全风险的快速决策。如需了解更多信息，可以查看详尽的规范本身或观看一些可供参考的CSAF视频（https://oasis-open.github.io/csaf-documentation）。

漏洞可利用性交换

在关于CSAF的讨论基础上，CISA的第二个关键步骤是广泛采用VEX。我们将在第4章“软件物料清单的崛起”中讨论VEX，因此这里只作简要介绍。在高层次上，VEX允许软件供应商断言特定漏洞是否影响某个产品以及是否不影响某个产品。实际上，组织面临网络安全人才短缺的问题，VEX允许组织优先将时间和资源花在对其构成风险的漏洞上，而不是那些可能无法利用且不构成风险的漏洞上。VEX文档作为SBOM的密切伙伴，提供关于SBOM中包含的漏洞的可利用性的信息，这些文档可以与SBOM一起或独立于SBOM生成。由于漏洞不断被发现和披露，即使没有新的软件发布，也可能会出现新的漏洞，因此在某些情况下，VEX的节奏可能与SBOM不同。

行业在SBOM和VEX领域的规范和工具方面不断创新。例如，在2023年初，软件供应链领导者Chainguard宣布，通过与HPE和TestifySec等其他公司的合作，他们创建了OpenVEX规范。OpenVEX旨在保持简洁、合规、可互操作和可嵌入。更多信息可以在OpenVEX的GitHub存储库中找到（https://github.com/openvex/spec）。

特定利益相关者漏洞分类和已知被利用的漏洞

行业内的一个持续需求是帮助组织优先处理构成最大风险的漏洞。

CISA（网络安全和基础设施安全局）已策划并发布了一个已知被利用的漏洞（KEV）目录，并通过一项强制性操作指令（BOD） (www.cisa.gov/binding-operational-directive-22-01)要求联邦机构修复这些KEV。CISA建议，如果商业组织受到这些KEV的影响，也应采取同样的措施。该目录以网页形式发布，同时也提供CSV或JSON文件格式。组织和个人还可以订阅KEV目录更新公告，通过电子邮件通知新KEV的添加。

一个漏洞要进入KEV目录的标准包括以下几点：

■它必须有一个CVE ID分配。
■根据可靠证据，该漏洞正在在野利用。
■对于该漏洞有明确的补救指导，例如供应商提供的补丁或更新。

正如我们之前讨论的，CVE计划由CISA赞助，但由MITRE运行，MITRE是一个联邦资助的研究与开发中心（FFRDC）。CVE计划的目的是识别、定义和编目公开披露的漏洞。CVE ID由CVE编号机构分配，并有三种可能的状态：保留、发布或拒绝。

CISA 的 KEV 目录并不使用漏洞可利用性本身作为纳入目录的标准。相反，必须有可靠证据表明该漏洞已被尝试利用或成功利用。例如，可能有证据表明恶意行为者尝试在目标上执行代码但未成功，或者仅在蜜罐系统上执行。与尝试利用不同，成功利用意味着恶意行为者成功利用目标系统上的漏洞代码，从而能够在系统或网络上执行某种未经授权的操作。CISA 谨慎地指出，PoC漏洞利用不会被纳入 KEV 目录，因为尽管研究人员可能展示了某些漏洞可能被利用，但没有证据表明它在实际环境中已被利用或尝试利用。

纳入 KEV 目录的第三个标准是明确的修复指导。这意味着组织可以采取明确的行动来减轻 KEV 的风险。这些行动可能包括应用供应商更新，或者在潜在的严重情况下，如果没有可用的更新或产品已到达生命周期终点且不再更新或支持，则完全从网络中移除受影响的产品。CISA 还承认，在缺乏相关更新和补丁的情况下，组织通常会寻求实施缓解措施（防止漏洞被利用）或变通方法，这些是手动更改，用于在补丁可用之前保护易受攻击的系统免受利用。

在使用 KEV 的指导基础上，CISA 正致力于通过特定利益相关者漏洞分类（SSVC）帮助组织优先分配漏洞管理资源。SSVC 是通过 CISA 与卡内基梅隆大学的软件工程研究所（SEI）合作创建的。SEI 对单独使用 CVSS 等资源的批评并不陌生，2018 年发布了一篇具有一定批判性的白皮书《Towards Improving CVSS》，指出广泛使用的 CVSS 在漏洞优先级管理中的若干缺陷（https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=538368）。值得一提的是，尽管倡导使用诸如 SSVC 这样的框架，像 CISA 这样的联邦组织仍然强制使用 CVSS，尽管他们积极与诸如 SEI 这样的组织合作，这些组织已指出 CVSS 的缺点和不足(www.blog.deploy-securely.com/p/revealing-the-governments-approach)。

如 CISA 的 SSVC 指南所述，SSVC 是一种定制的决策树模型，旨在协助美国政府及相关实体优先处理漏洞响应，但其他组织也可以使用。SSVC 包括四种可能的决策，如图 3.7 所示。

该指南建议组织了解漏洞的范围，因为这也会影响决策树的使用。例如，漏洞是否遍布整个企业，或仅影响关键系统的一部分。

在使用 SSVC 并逐步通过决策树时，组织应考虑多个因素。这些因素包括利用状态，可以使用国家漏洞数据库 (NVD) 或信息共享与分析中心 (ISACs) 等来源。这些来源通常提供关于漏洞是否没有利用证据、是否存在概念验证 (PoC) 或是否正在实际环境中被积极利用的见解。

接下来，组织需要了解利用漏洞的技术影响。在这里可以类比 CVSS 的基础评分概念——严重性。可能的取值包括“部分”，即恶意行为者对系统的控制或影响有限；以及“完全”，即恶意行为者对漏洞所涉及的软件或系统的行为具有完全控制权。

另一个关键因素是漏洞利用是否可以自动化。对于恶意行为者来说，能够自动化利用的漏洞比需要人工干预和实施的漏洞更容易扩展其恶意活动。这里的决策值是简单的“是”或“否”。如果答案是“是”，那么恶意行为者可以自动化执行洛克希德·马丁公司网络杀伤链（ (www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html)）步骤1-4：侦察、武器化、投递和利用。指导意见还提到，除了自动化，还必须考虑漏洞链结，因为为了成功利用漏洞，可能需要或可能可以将多个漏洞或弱点连在一起。

从技术影响开始，考虑到任务的普遍性，即对任务基本职能或有关实体的影响。SSVC 指导意见将这些功能定义为“直接与完成组织在其法定或执行宪章中规定的使命相关的功能。”组织通过业务连续性规划（BCP）等演习来识别 MEFs。决策值包括最小、支持或必要。必要是指存在漏洞的组件直接为至少一个 MEF 或实体提供能力，且漏洞利用会导致任务失败。而支持则意味着存在漏洞的组件支持 MEFs 但不直接支持它们。最后，最小是指既不适用必要也不适用支持的情况。

决策树中的下一个考虑因素是公众福祉的影响，即存在漏洞的组件或系统对人类的影响程度。SSVC 采用了美国疾病控制与预防中心（CDC）对福祉的定义：人类的身体、社会、情感和心理健康。这里的决策分为影响的严重程度，可以是物质上的或不可逆的，以及伤害的类型，从身体上的、心理上的，甚至是经济上的伤害都包含在内。

最后是缓解状态的考虑，它衡量了及时缓解脆弱性的困难程度。需要考虑的因素包括：

■缓解措施是否公开可用。
■进行所需系统更改的难度。
■是否存在修复方案或需要临时解决方法。

指导意见强调，缓解措施的价值不应改变 SSVC 决策的优先级，但应积极跟踪和考虑 SSVC。图 3.8 是决策树的示例，但也可以以表格格式表示。

第三章漏洞数据库和评分方法

3.12 行动意见

CISA 指导意见优先考虑的步骤包括使用 CSAF 自动化安全公告，并通过 VEX 等资源告知软件消费者漏洞利用的影响。然而，同时也明确指出，需要主观的网络安全专业知识，尤其是在复杂的决策树中。自动化在减轻组织和网络安全团队认知负荷方面发挥了关键作用，但仍需具备网络安全和软件专业知识，以理解漏洞对更广泛的企业和系统环境的影响，并确定如何优先分配组织资源来应对这些挑战。

第三章漏洞数据库和评分方法

3.13 小结

在本章中，我们了解了行业漏洞数据库和评分方法。这包括传统漏洞数据库及其潜在的局限性，以及整个漏洞生态系统中新兴的数据库。我们还审视了常见的软件身份格式及其带来的挑战，以及为缓解这些挑战所提出的解决方案。同时，我们探讨了漏洞如何分类、评分和传播。在下一章中，我们将看看软件物料清单 (SBOM) 及其相关工件如 VEX 的兴起。

第四章软件物料清单的兴起

本章讨论了 SBOM 概念的起源，包括早期的失败和成功，以及为其成熟做出贡献的美国联邦和行业组织。我们还将深入探讨 SBOM 格式、特定字段以及漏洞利用交换（VEX）出现的一些细节

第四章软件物料清单的兴起

4.1 法规中的SBOM:失败和成功

尽管行业内可能存在一系列与软件物料清单 (SBOM) 相关的动态，但达到当前这一点是经过了多年的努力，涉及了各种政府和行业组织的参与。最值得注意的是，最近的 SBOM 动态发生在国家电信和信息管理局 (NTIA) 的推动下。

也就是说，虽然NTIA以及Log4j和SolarWinds等事件可能在最近围绕SBOM的发展势头中发挥了关键作用，但早期涉及Apache Struts 2和openssl2相关漏洞的事件是由于引入了立法，如2014年网络供应链管理和透明度法案(www.congress.gov/bill/113th-congress/house-bill/5793/text)。

该法案侧重于使用第三方和开源软件(OSS)代码为美国政府开发或购买的软件、固件和产品的完整性，并要求在联邦政府的软件、固件或产品合同中包含组件清单或物料清单。在这一努力中，早期的重要先驱之一是行业领袖 Joshua Corman，他曾在多家行业领先的私营公司和 CISA 工作，他还创立了“I am The Cavalry,”该团体关注数字安全、公共安全和人类生命的交集。

《2014 年网络供应链管理和透明度法案》因行业对其呼吁增加产品中软件组件透明度的抵制而未能完全实现。然而，这表明，尽管在撰写本文时 SBOM 受到广泛讨论，但这一话题实际上已经被讨论和期望了近十年之久。

其他值得注意的例子包括2017年6月发布的《医疗保健行业网络安全任务组报告》，该报告呼吁制造商和开发人员创建一个“物料清单”以描述医疗设备中的组件（www.phe.gov/Preparedness/planning/CyberTF/Documents/report2017.pdf）。

NTIA:宣传SBOM的必要性

近期在联邦领域的软件物料清单（SBOM）工作的推广由NTIA（国家电信和信息管理局）主导。自2018年起，NTIA一直致力于推动软件组件透明度。2018年7月，NTIA召开了多方利益相关者会议（http://ntia.doc.gov/federal-register-notice/2018/notice-071918-meeting-multistakeholder-process-promoting-software），讨论了软件组件透明度、挑战及潜在解决方案。

这些早期会议由当时担任NTIA网络安全倡议主任的Allan Friedman博士参与。Friedman自早期以来一直是围绕SBOM和软件透明度行业对话中的重要人物，与上文提到的Joshua Corman一样，现在他在网络安全和基础设施安全局（CISA）担任高级顾问和策略师，依然在帮助推动软件透明度和SBOM进程。

NTIA认识到现代软件是由许多来自开源和商业行业的组件和库构成的（http://ntia.gov/blog/2018/ntia-launches-initiative-improve-software-component-transparency）。它也承认创建和维护这些组件及其相关漏洞的清单非常具有挑战性。该组织及其多方利益相关者社区一直致力于理解改进软件组件清单、实践以及相关政策和市场挑战的方法。

在推动软件透明度和软件物料清单（SBOM）的过程中，NTIA（国家电信和信息管理局）发布了大量相关文件和指导（可在http://ntia.gov/SBOM找到）。这些文件涵盖了介绍SBOM、提高对SBOM的理解、SBOM实施以及相关技术资源等内容。

根据《网络安全行政命令》中的第4节“加强软件供应链安全”，子节(F)要求NTIA在《网络安全行政命令》发布60天内公布SBOM的最低要素。随后，NTIA在2021年7月发布了《软件物料清单（SBOM）最低要素》（http://ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf）。该指导文件确立了SBOM的最低要素，定义了如何思考这些最低要素的范围，并描述了软件供应链透明度的SBOM用例。NTIA的指导文件论证了系统共享和组件元数据的跟踪有助于支持软件供应链的透明度。

在本节中，我们将分解NTIA的最低要素指导。他们的指导包括并详细说明了三类要素:

■数据字段
■自动化的支持
■实践和流程

NTIA的指导意见指出，每个软件都可以表示为一个层级树结构，其中包含组件和子组件。这些组件包括从其他来源获取的第三方组件，以及作为独立软件单元存在的一方组件。三个元素类别中，第一个是数据字段，包含了应跟踪和维护的每个组件的基本信息。这些数据字段的主要目的是帮助组织在整个软件供应链中跟踪这些组件。NTIA定义了一组基准数据字段集合，如表4.1所示。

组织可以使用这些数据字段将组件与其他数据源进行映射，这一过程被称为“富集（enrichment）”。从表4.1可以看出，目的是提供诸如组件供应商、组件名称和版本等基本信息，然后将组件与相关的上游组件关联起来。这通常被称为依赖关系，因为大多数软件包括第三方代码，导致一方和第三方代码在组件和应用程序中形成依赖关系。值得注意的是，NTIA的指南讨论了一些挑战，如供应商和软件供应商之间的不同版本管理方法。

除了数据字段，NTIA为SBOM确定的另一个核心组成部分是自动化支持的需求。SBOM普及和采用的怀疑者指出，需要强大的工具和自动化支持来使SBOM的采用在大规模情况下准确且成功。自动化支持将使组织能够将SBOM集成到其现有的漏洞管理、供应链风险管理和网络安全计划中。NTIA的SBOM指导讨论了三种主要的SBOM格式，将在“SBOM格式”部分中涵盖。

最后，NTIA的SBOM指导涵盖了实践和流程，重点是SBOM在组织操作和采用中的使用机制。主要讨论的实践和流程包括以下内容：

■频率
■深度
■已知的未知
■分发和交付
■访问控制
■错误纠正

频率（Frequency）与新SBOM的创建频率有关。NTIA的指导意见强调，每次新建或发布软件时，必须创建新的SBOM。如果软件供应商了解到组件的附加细节，包括纠正之前传输的错误，也需要创建新的SBOM。

深度（Depth）指的是SBOM在依赖树中应该深入到的层次。NTIA的指导意见指出，SBOM至少应包含所有顶级组件，并列出传递依赖项。传递依赖项可以定义为软件运行、编译或测试所必需的组件。虽然列出所有传递依赖项并不总是实际可行，但指导意见确实指出，如果必要，应该提供足够的信息以查找这些传递依赖项。在深度方面，不同的组织和行业可能有不同的要求，甚至由于内部政策或法规要求而有所不同。SBOM的消费者会试图为其软件产品指定深度，特别是在涉及专有软件供应商和合同、法律方面的问题时。

已知的未知（Known Unknowns）的概念围绕着SBOM作者在进一步依赖关系的沟通中的清晰性。有些情况下并非所有依赖项都是已知的，这在指导意见中被称为已知未知。SBOM作者可以传达数据已知是不完整的，告知软件消费者在其软件使用中可能存在未解决和未知的风险。

分发和交付（Distribution and Delivery）涉及确保需要知晓SBOM的实体能够及时获取，并具备适当的权限和访问控制。SBOM采用的这一领域仍在发展中，无疑会采用多种方法。分发和交付的方法也会因所涉及的软件和系统的性质而异，例如嵌入式系统或在线服务，每种方式的分发和部署给终端消费者的方式都不同。对于美国政府，《网络安全行政命令》规定要求，即“为每个产品提供给购买者一个软件物料清单（SBOM），直接提供或发布在公共网站上”。

访问控制是SBOM采用和使用中至关重要的一部分。在软件生产商之间持续标准化SBOM交付实践的过程中，对于数据共享的容忍度会有所不同。一些可能希望将信息公开和开放，例如开源维护者或一些私人软件公司，如JupiterOne（http://jupiterone.com），他们已经将其SBOM发布在http://jupiterone.com/sbom。然而，一些软件供应商，特别是那些认为其SBOM敏感或具有特定客户需求的供应商，如国防或国家安全社区中的供应商，可能希望只在特定条款和条件下并在特定的访问控制下提供此信息。这是一个将继续发展和成熟的SBOM和软件透明度领域。

最后，指南中提到了容错实践。这意味着允许遗漏或错误的存在。整个行业的软件供应链安全内部实践仍在成熟中，错误和疏忽肯定会发生。这是一条双向的路，软件生产者在适当的时候可以提供额外的见解或澄清，软件消费者也理解初期可能不完美。通过这种相互合作，可以改善整个软件供应链的卫生状况。

NTIA对SBOM的对话和采用的贡献远远超出了最低元素指南，如前所述，包括澄清一些误解（http://ntia.gov/files/ntia/publications/sbom_myths_vs_facts_nov2021.pdf）、解释视频和常见问题解答（http://ntia.gov/files/ntia/publications/sbom_faq_-_20201116.pdf）。他们最常被引用的出版物之一是SBOM框架文件（http://ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf），该文件涵盖了从软件透明性和系统风险相关的问题声明、什么是SBOM、SBOM流程和使用案例、以及NTIA用来制定其指南的多利益相关者过程概述。

尽管NTIA作为促进SBOM采用和更广泛的软件供应链透明性的基本催化剂发挥了作用，这一努力已经继续发展，现在由CISA支持（http://cisa.gov/sbom）。毫无疑问，这一部分是由于Allan Friedman从NTIA转移到CISA，鉴于他一直是SBOM采用和使用的最积极的倡导者之一。CISA努力通过其社区参与、开发和进展活动，将NTIA的早期努力推进到更远的地方，最终目标是实现SBOM在行业中的规模化和运营化。

截至撰写本文时，CISA最重要的SBOM活动和社区参与是2021年12月举办的SBOM-a-Rama。这是为期两天的活动，第一天重点讨论了SBOM能力的现状，第二天则重点讨论了使SBOM的采用和使用更加可扩展和有效。参与者包括一系列公共和私人部门的领导者，如国会议员James Langevin、长期SBOM和软件透明性倡导者Josh Corman，以及来自开放世界应用安全项目（OWASP）、Linux基金会等行业组织的代表。

讨论包括基础性话题，如什么是SBOM及其重要性、领先的SBOM格式如SPDX和CycloneDX、以及在医疗保健、能源和汽车工业中的早期概念验证（PoC）努力。两个活动日的录音和演示文稿可在http://cisa.gov/cisa-sbom-rama上获得。在后续章节中，我们还将深入探讨如领先的SBOM格式等话题。

第四章软件物料清单的兴起

4.2 行业努力：国家实验室

为应对特定行业的需求，几个概念验证（PoC）小组作为NTIA SBOM研讨会的一部分被建立。医疗PoC至少经历了三次迭代，此外还成立了汽车PoC和其他几个小组。这些小组中有些对公众开放，有些仅限邀请。在许多情况下，即使是公共工作组也对解决方案提供商如何支持这些工作有限制。爱达荷国家实验室 (INL; http://inl.gov/sbom-poc) 成立了一个以能源用例为重点的 PoC，最初由 INL 的 Virginia Wright 和 Tom Alrich 组成，Tom Alrich 是著名的供应链和北美电力可靠性公司关键基础设施保护 (NERC CIP) 合规顾问和行业博客作者，现在被许多人视为 SBOM 专家。Tom的角色现已被Allan Friedman取代，但该工作组对关键基础设施相关问题的教育和讨论的开放性值得一提。

能源计划委员会整理的资料是仅次于 NTIA 官方网站（www.ntia.gov/SBOM），可供公众使用的保存最完好的资料。过去会议的完整录音以及许多其他参考资料、链接和与SBOM相关的主题均可获取。虽然重点是能源使用案例，但这项工作的基础教育方面为任何希望熟悉这些主题的人提供了一个丰富的起点。

在能源部（DoE）的支持下，国家实验室从研究和思想领导的角度发挥着宝贵的作用，重点关注从气候变化到绿色能源进步，再到网络安全的方方面面。例如，一个名为“优化安全与能源管理的区块链”（http://netl.doe.gov/BLOSEM）的研究计划重点关注区块链技术的多种使用案例，其中许多案例都与供应链安全有关。一些值得注意的的例子如使用区块链识别交付给公用事业的设备是否是预期设备，配置和设定值的完整性检查，以及 SBOM 和硬件物料清单（HBOM）的安全分发和区块链互操作性。

这项工作由 "电网现代化计划 "发起，该计划是能源部的一项合作计划，由电力输送和能源可靠性办公室以及能源效率和可再生能源办公室共同资助，并由国家可再生能源实验室（NREL）和国家能源技术实验室（NETL）负责执行。除了这两个实验室，还有许多其他行业合作伙伴，包括太平洋西北国家实验室（PNNL）等。PNNL正在利用他们在电网网络安全和运行联邦资助的电力区块链方面的专业知识和经验共同领导区块链用例的开发。

此外，通过 "弹性工业控制系统网络测试"（CyTRICS）计划 (http://cytrics.inl.gov)，我们致力于确定如何最好地表示系统的各个组成部分，包括硬件和软件。这些努力在某种程度上是封闭的，只对产品供应商开放，但这里创建的生态系统为作为系统描述符的 SBOM 主题提供了一个基础用例。此外，CyTRICS为关键基础设施的产品安全和供应链信息创建了一个通用框架和存储库，虽然尚未过渡到商业使用，但它是公私合作如何为软件透明度主题的创新创造机会的一个范例。

第四章软件物料清单的兴起

4.3 SBOM格式

为使 SBOM 的采用标准化和成熟化，各方努力围绕几种主要的 SBOM 格式开展工作。迄今为止，三种主要的 SBOM 格式是软件识别 (SWID) 标签、CycloneDX 和软件包数据交换 (SPDX)。这三种 SBOM 格式各有利弊和主要用途。CycloneDX 和 SPDX 分别得到了不同组织的支持，CycloneDX 得到了 OWASP 的支持，而 SPDX 则得到了 Linux 基金会的支持。如前所述，在过去几年中，围绕 SBOM 的公开对话大多是由 NTIA 和 SBOM 格式等工作所引导的，标准也不例外。NTIA发布了《SBOM格式与标准白皮书》（http://ntia.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf），指出了软件透明度方面的问题，并评估了当前可用的 SBOM 格式。这份白皮书于2019年发布，自此之后，围绕这些 SBOM 格式（尤其是 CycloneDX 和 SPDX）的讨论不断发展。虽然在谈话的早期，NTIA 的文档等资料中提到 SWID 是一种 SBOM 格式，但它并没有具体满足 NTIA 对 SBOM 的最低要求，例如 SWID 规范中规定的 SBOM 生成时间戳。美国陆军这个正在大规模采用 SBOM 的组织明确表示，他们不会使用 SWID 格式的 SBOM，而是需要 CycloneDX 或 SPDX (https://sam.gov/opp/0b824ec63e2541e082c58c65b6e1702d/view)。

NTIA团队关注的一些关键领域包括需要记录可操作和可执行的机器可读格式，同时也承认不会要求单一格式，并推动一个多种格式可以并存的生态系统。每种主要的SBOM格式都以不同的表现形式和文件格式呈现信息。表4.2是使用NTIA SBOM最低要素作为基准的三种格式的示例。

表 4.2: 三种 SBOM 格式

属性	软件包数据交换格式SPDX	CycloneDX	软件识别标签SWID
作者名称	(2.8)创作者	元数据/作者/作者	@role (tagCreator), @name
时间戳	(2.9)创建	元数据/时间戳	Meta
供应商名称	(3.5)包装供应商	供应商发布者	@role(softwareCreator/publisher), @name
组件名	(3.1) 软件包名	名称	@version
版本号	(3.3) 软件包版本	版本	@version
组件哈希	(3.10) 软件包校验码: (3.9): 软件包验证码:	Hash"alg"	/../ @[hash-algorithm]: hash
唯一标识符	(2.5) SPDX 文档命名空间: (3.2) SPDXID:	bom/serialNumber component/bom-ref	@taqgID
关系	(7.1) 关系: 描述：包含：	(嵌套组件/子组件和/或依赖图中的固有属性)	@rel, @href

来源: ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf. U.S Department of Commerce, Public domain

软件识别（SWID）标签

SWID标签专注于软件清单和授权管理。它通过在软件中查找SWID标签来实现功能。SWID标签的格式由国际标准化组织（ISO）和国际电工委员会（IEC）的ISO/IEC 19770-2标准定义，截至撰写本文时，最新版本为ISO/IEC 19770-2:2015。

SWID标签文档包括一组结构化的数据元素，用于识别软件产品，包括产品版本、参与产品生产和分发的组织/个人，以及构成软件产品的各种部件。它们还可以用于建立不同软件产品之间的关系。

SWID通常被诸如软件资产管理（SAM）和安全工具等工具使用，帮助自动化与软件产品在整个软件开发生命周期（SDLC）中相关的一些行政开销。

SWID 规范包括多个角色和利益相关者，如标签生产商、平台提供商、软件提供商、标签工具提供商和标签消费者。在更广泛的软件生态系统中，这些利益相关者中的每个人都在使用 SWID 来完成他们的各种用例和任务。

尽管在早期的NTIA文档中SWID 被认可为是一种 SBOM 格式，但业界已将 CycloneDX 和 SPDX 作为两种主要的 SBOM 格式。与 SBOM 格式相比，SWID通常被认为更像是CPE（公共漏洞与曝光，Common Platform Enumeration）

CycloneDX

SPDX 由 Linux 基金会等组织倡导，而 CycloneDX (http://cyclonedx.org) 则由安全社区的长期领导者 OWASP 领导。CycloneDX是一种自定义的“轻量级SBOM标准，设计用于应用安全环境和供应链组件分析”（见图4.1）。CycloneDX的核心团队包括Patrick Dwyer、Jeffry Hesse、软件供应链领导者和依赖性跟踪（Dependency Track）的创建者Steve Springett，后者担任该小组的主席（http://dependencytrack.org）。除了 OWASP 的支持，CycloneDX 还得到了洛克希德-马丁公司、Contrast Security、Sonatype 等公司的支持。

CycloneDX 的独特之处在于，它从一开始就被设计为一种 BOM 格式，可满足各种使用情况，包括软件即服务 BOM（SaaSBOM）。除软件外，CycloneDX 还支持多种使用情况。

CycloneDX 还支持在其他系统和 BOM 中引用组件、服务和漏洞，采用嵌套和分层方法，以适应现代软件生态系统在硬件、云和 SaaS 方面的复杂性。CycloneDX 将这种功能称为 BOM 链接。它支持 JSON 和 XML 格式。用户可以引用外部 BOM 的 URL，甚至是 BOM-Link URI，其中使用了外部 BOM 的序列号和版本。

此外，CycloneDX 还可对所有第一和第三方组件进行完整、准确的清查，以进行风险识别。它通过组件类型和类别的强大列表来实现这一点，这些组件类型和类别不仅包括软件和应用程序，还包括设备甚至服务。它可以通过三个字段识别漏洞：

CPE（Common Platform Enumeration）：用于操作系统、应用程序和硬件设备漏洞的规范。
SWID（Software Identification）：用于安装的软件的规范。
PURL（Package URL）：用于软件包元数据的规范。

CycloneDX 支持通过哈希值和加密技术对与 BOM 相关的组件进行完整性验证。通过 Sigstore 及其配套的 Cosign 等项目，软件签名正日益成为推动软件供应链安全成熟的最佳实践。CycloneDX 支持可扩展标记语言（XML）和 JavaScript Object Notation（JSON）的封套签名，而 Cosign 目前还不支持这种签名。CycloneDX 还支持出处（provenance），即表示组件作者和组件供应商的能力。基于出处的概念，CycloneDX 可通过交流组件的祖先、后代和变体来描述组件的世系，从而支持组件的世系。对于高保证软件供应链要求而言，实施出处、血统和数字签名代表了强大的供应链能力，也是 NIST 的网络安全供应链风险管理（C-SCRM）等指南所推荐的。

CycloneDX 还支持漏洞可利用性交换 (VEX)，该交换提供了对软件产品和组件中已知漏洞可利用性的深入了解，并可由软件生产商进行交流。我们将在 "Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosures "一节中更深入地介绍 VEX。

软件包数据交换(SPDX)

作为一个项目，SPDX 的成立旨在为软件包相关信息创建一种通用数据交换格式，以便共享和收集。在主要的 SBOM 格式中，SPDX 支持的文件格式最多，包括 RDF、XLSX、SPDX、JSON 和 YAML。SPDX 还旨在成为一种动态规范，能够描述一组软件包、文件或片段。与 SWID 一样，SPDX 也是目前获得 ISO 认证的三大主流格式之一 (http://linuxfoundation.org/press/featured/spdx-becomes-internationally-recognizedstandard-for-software-bill-of-materials)，这意味着它已满足 ISO 规定的标准化和质量保证的所有要求。这项成就是由 Linux 基金会于 2021 年 9 月宣布的。该公告还强调了 SPDX 已被英特尔、微软、西门子、索尼等大公司所采用，这些公司都参与了 SPDX 社区。

SPDX 规范目前是 2.3 版（http://spdx.github.io/spdx-spec）。要被视为有效的 SPDX 文档，必须包含 SPDX 规范本身定义的特定字段和部分。

SPDX 文档可由各种字段和数据组成，如文档创建信息、包信息、文件信息、片段信息、许可信息、关系和注释。文档创建信息用于在使用处理工具时实现向前和向后兼容性。包信息用于描述不同的实体，如产品、容器和组件等，并可用于对共享上下文的相关项目进行分组。文件信息包括文件元数据，如名称、校验和许可证和版权信息。片段是可选的，主要用于数据来自不同的原始源或与其他许可证绑定的情况。SPDX 还支持文档、包和文件的关系。最后，注释允许审阅者将其审阅活动中的信息纳入 SPDX 文档。

SPDX还提供了“SPDX Lite”配置文件，它是SPDX规范的子集，旨在与特定行业的工作流程保持一致，同时兼顾遵守总体 SPDX 标准和规范。Lite配置文件侧重于文档创建和软件包信息部分以及相关的基本信息。

漏洞利用可行性交换（VEX）和漏洞披露

SolarWinds 网络安全事件 (http://cisa.gov/news/2020/12/13/cisa-issues-emergency-directive-mitigate-compromise solarwinds-orion-network)的余波，再加上网络安全 EO，将软件供应链安全以及相关的 SBOM 话题推向了安全对话的中心舞台。再加上 Log4j 漏洞 (http://cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf) 让无数企业忙于确定其影响，SBOM 现在已被视为现代网络安全漏洞计划的一个重要组成部分，并将迅速得到采用 (http://cisa.gov/sites/default/files/publications/VEX_Use_Cases_April2022.pdf)。

如上图4.2所示，一个SBOM树可以展示上游关系声明，以展示组件及其关系，包括声明组件起源是否未知。

使用 SBOM 所带来的最大好处之一就是能够识别潜在的易受攻击组件。领先的 SBOM 平台和工具（如 Dependency Track）通过将与组件相关的漏洞与使用 SBOM 分析其软件组件的人员的注意力联系起来来实现这一目的。Dependency Track 和其他工具通过查询国家漏洞数据库 (NVD；http://nvd.nist.gov)、Sonatype OSS 索引 (http://ossindex.sonatype.org)、VulnDB (http://vulndb.cyberriskanalytics.com) 或 OSV (http://osv.dev) 等来源来促进这一过程。然而，漏洞与软件中的某个组件相关联，并不意味着该组件可以被利用。这就是 VEX 发挥作用的地方。

VEX进入对话

根据NTIA的指南（http://ntia.gov/files/ntia/publications/vex_one-page_summary.pdf），VEX的主要用例是

为用户（如运营商、开发商和服务提供商）提供更多信息，说明产品是否受所含组件中特定漏洞的影响，如果受影响，是否建议采取补救措施。

VEX 为漏洞添加了背景信息，为风险管理活动提供了依据。与其他领先的 SBOM 和软件供应链透明度与安全指南一样，VEX 也是在 NTIA 的软件组件透明度多方利益相关者流程（Multistakeholder Process for Software Component Transparency）的基础上诞生的。尽管如此，该指南指出虽然 VEX 是针对特定的 SBOM 用例开发的，但它并不局限于SBOM 的使用，同时也不一定是必需的。

正如本书其他章节所述，存在漏洞并不意味着它是可以利用的。这是非常重要的信息，因为漏洞管理程序和活动与组织一起执行风险管理。在网络安全风险管理中，组织试图根据组织的风险承受能力识别、分析、评估和应对网络安全威胁。这样，组织就会根据风险发生的可能性和严重程度确定风险的优先级。如果不知道漏洞是否可被利用，就不可能准确预测其可能性。

VEX: 添加上下文和清晰度

那么，VEX 究竟是如何解决这一难题的呢？它授权软件供应商发布 VEX，即关于特定产品中漏洞状态的声明。VEX 支持以下四种主要状态选项：

未受影响：不需要针对此漏洞进行补救措施。
受影响：建议采取行动来修复或解决此漏洞。
已修复：这些产品版本已包含对漏洞的修复。
正在调查：尚不清楚这些产品版本是否受漏洞影响。将在后续发布中提供更新。

以SBOM本身为例，我们看到了朝着机器可读的工件和文档推进，这使得自动化、准确性和速度得到了提升。在合规领域，我们也看到了类似的趋势，如NIST的开放安全控制评估语言（OSCAL; http://pages.nist.gov/OSCAL），它将传统的基于纸张的安全控制和授权文件转换为机器可读格式。

VEX 采取了类似的做法，它不需要通过电子邮件发送安全公告或有关漏洞和建议的详细信息，而是将这些信息转化为机器可读的格式，以促进自动化和现代化安全工具的使用。这些工具能更快地响应当前的威胁态势，而不是依赖人力和手动活动。随着对软件供应链透明度和安全性的推动，我们不难想象这样一个世界：企业软件库存能够在仪表盘和工具中可视化，同时还能显示其相关漏洞和漏洞的实际可利用性，所有这些都由 SBOM 和随附的 VEX 数据支持。这与现代生态系统形成了鲜明对比，在现代生态系统中，大多数组织都没有准确的库存，不知道他们所使用和部署的软件组件，也不知道与之相关的漏洞。尽管现代软件主要由开源软件组件（OSS）组成，据估计，开源软件组件占据了软件的80-90%。

指南还指出，虽然VEX可以由软件供应商撰写，但也可以由第三方撰写，这使得用户可以自行决定如何使用数据。这使得很容易想象到，安全研究人员和漏洞供应商可能会尝试为其产品提供VEX，作为其产品提供的一部分。

VEX和VDR对比

除了VEX概念外，漏洞通告或漏洞披露报告（VDR）的主题增加了一些混淆，但实际上这是一个非常简单的主题。VDR 会在出现漏洞时通知您，其中既包括已知漏洞，也包括未知漏洞。此外，VDR提供有关漏洞的附加元数据，包括谁发现了漏洞、有关公开利用的信息以及其他附加信息。ISO 29147标准和NIST 800-161r1文档概述了VDR的以下要素，如下所示：

VDR要素概述

一般信息：有助于目标受众了解此安全公告是否适用于他们。
标识符：此安全公告的唯一标识符，如供应商使用的唯一编号方案，漏洞标识符（例如CVE）、产品标识符（如CPE或PURL）。在与SBOM对比时，此属性可能是连接断言的较好属性之一。
日期和时间：初始安全公告的日期和时间以及任何更新。将VDR的时间戳与其他断言进行比较时，可以帮助确定VDR是先于还是后于其他处理的断言，并且是否包含比其他产品更为更新的信息。
真实性-签名：虽然不包括在ISO标准中，但NIST已指出签名的需求，签名可能是用于将多个断言与任何信任级别链接在一起的最佳方式之一。
标题：简要标题应足够唯一，清楚地说明安全公告的内容，包括产品名称和版本或CWE类别。
概述：扩展标题，提供足够的细节，使读者能够了解安全公告对其产品的适用性。
受影响产品：清楚说明受VDR影响的产品，并提供足够信息，使读者能够了解其产品是否受影响。这可能包括用于测试的在线脚本的链接，或特定的元数据，如文件哈希、字符字符串或唯一版本指示符。
受影响组件：虽然 ISO 标准中没有包括这一点，但 NIST 的文件中却有详细说明，这也是我们理想的捕获组件级详细信息的地方，这些信息可以与 SBOM 相结合，并以与受影响产品相同的方式使用--例如，说明组件需要如何实施或使用才能成为易受攻击的组件。仅仅存在易受攻击的组件可能不足以满足易受攻击的条件。
预期受众：此安全公告的预期受众是谁？开发人员？最终用户？虽然这是VDR中的可选字段，但可用于传达使用 VDR 的其他背景信息。
本地化：可能针对特定地区和特定语言发布安全公告。此部分允许传达任何需要传达的区域特定信息或上下文，即使只是翻译也可以。
描述：描述应传达其他信息，如软件弱点类别及其可以在什么条件下被利用的信息，可能包括外部参考，如CWE分类器。
影响：通常与技术影响相关，例如机密性、完整性或可用性的损失，这些信息可能在CVE或CVSS子分数中找到。
严重性：使用标准的严重性评分，如CVSS，或供应商使用的严重性评分，如果使用，提供漏洞的严重性的可量化度量。不管您对CVSS评分有何看法，这是整个行业衡量严重性的方式，并且是最可能使用的指标。
修复措施：VDR应指示如何修复漏洞、打补丁或重新配置，或者至少应提供一个允许减轻漏洞风险的解决方法。在许多情况下，初始VDR可能不包括修复指南，但应尽快进行更新，一旦了解如何减少利用风险。
参考资料：可能存在许多外部参考资料，例如CVE、供应商知识库、产品页面、研究人员博客或其他有用的支持信息，这些信息在VDR内引用。
信誉：应该给予参与检测、研究、减轻漏洞及其他漏洞报告生命周期阶段的研究人员和组织适当的信誉。这是完全自愿的。
联系信息：为产品用户提供足够的信息，以便联系供应商获取更多信息。
修订历史：应非常清楚地说明这是否是原始安全公告还是更新。如果是更新，则应保持版本历史，并与VDR内的日期和时间信息一致。
使用条款：最后，安全公告是有许可的文章，应包含版权信息和使用条款。例如，在许多情况下，只允许许可产品所有者使用，或者可能完全禁止重新分发。

你会注意到，虽然漏洞披露报告（VDR）通知用户存在问题，但它并不告知用户某事并非问题。这是一个重要的区别，因为与VDR类似，SBOM的分析报告可能会产生大量误报。通过在现有的VDR格式中加入VEX语句（例如CycloneDX构建漏洞报告数据模型的方式），可以简洁而一致地确定漏洞的存在，并告知用户该漏洞是否构成问题。

漏洞未构成问题的原因有很多。根据Contrast Security的行业报告（www.contrastsecurity.com/security-influencers/2021-state-of-open-source-security-report-findings），软件中使用的80%开源组件实际上从未在产品的执行流程中调用。因此，我们可以认为，在开源组件中发现的后续漏洞中，有 80% 可能同样不存在风险，因为它们从未被使用过。这显然是一个卫生问题，也可能是代码膨胀和效率问题，并且很可能增加了攻击面，但这可能并不代表软件真正存在漏洞。

其次，许多供应商会“回溯”安全修复，即在代码库中插入其他的代码或其他形式的措施防止漏洞利用，但是组件的版本号却从未更新。这意味着，任何针对 NVD 的分析，如果要查找特定版本来告知漏洞，可能会查找不同的组件。目前，NVD中没有唯一标识软件文件的概念，只有通用平台枚举 (CPE)，即供应商、产品、版本、架构和类似元数据的描述。

最后，配置也很重要。在许多情况下，软件只有在以非常特定的方式进行配置时，或者在使用软件默认情况下不附带的特定共享库时，才会出现漏洞。当出现这些情况时，VEX可以提供额外的上下文信息，告知用户这些情况并不会转化为实际的可利用风险。

虽然 VEX 被认为是机器可读的文档，但我们认为它比 SBOM 更具有动态性。SBOM 大多是静态文档，与特定的软件版本相关联，而其漏洞状态会随着时间的推移而改变，如发现新漏洞、发现无法利用的漏洞、通过缓解措施修复的漏洞等。我们认为这可能更适合基于应用程序接口（API）的发布模式，在这种模式下，漏洞状态更新不仅是机器可读的，而且还能随着有关漏洞状态的新信息被发现而通过自动化方式持续发布。

第四章软件物料清单的兴起

4.4 行动建议

正如我们所讨论的，SBOM 计划从 NTIA 转移到网络安全基础设施安全局 (CISA)，与此同时 SBOM 的倡导者和领导者 Allan Friedman 也转移到了 CISA。自此之后，CISA 在 2022 年发布了另外两份 VEX 文档。一份是 VEX 用例文档，另一份是漏洞可利用性交换 (VEX) 状态说明 (http://cisa.gov/sites/default/files/publications/VEX_Status_Justification_Jun22.pdf)。

VEX 用例文档提供了 VEX 文档的最小数据元素，就像 NTIA 为 SBOM（与网络 EO 相关）定义的最小元素（参见表 4.1）一样。在本指南中，它指出 VEX 文档必须包含 VEX 元数据、产品详细信息、漏洞详细信息和产品状态。这些产品状态详细信息包括有关产品漏洞的状态信息，可以是“未受影响”、“受影响”、“已修复”或“正在调查中”。

VEX 状态说明随后侧重于 VEX 文档的要求，即包含说明 VEX 文档创建者为何选择断言产品状态为“未受影响”（如果他们确实做出了选择）的说明。这允许供应商提供产品未受漏洞影响的理由。选项包括组件或易受攻击的代码不存在、易受攻击的代码无法被对手控制或代码不在执行路径中，最后，产品中已经存在内联缓解措施。

VEX 是帮助 SBOM 采取行动的关键下一步，它提供了产品供应商关于其产品中存在的漏洞可利用性的背景见解和断言。通过使用 VEX 文档定义的最小元素及其相关的“不受影响”理由字段（如果适用），软件生产商能够让软件消费者做出风险知情决策，以推动他们的漏洞管理活动，作为更广泛的网络安全计划的一部分。

第四章软件物料清单的兴起

4.5 将 SBOM 与其他证明结合使用

SBOM 只是一种证明；它是一份包含其内部声明证据的文件。它通过附加到这些声明上的加密验证的质量和真实性得以强化。因此，通过数字签名将 SBOM 连接在一起的概念变得可行，这使得即使是不完整的 SBOM 也能提供价值，因为它们可以与其他 SBOM 结合，每个额外的证明为第一个 SBOM 增加保证信息。然而，我们希望探索其他一些可以与 SBOM 一起包含的证明类型，以构建完整的证据包。

来源真实性

来源真实性是 NERC CIP 合规性要求（CIP 010 和 013）重点关注的一个概念，其理念是您可以使用文件哈希或代码签名材料验证文件本身，但同样重要的是验证对文件来源的信任。它试图回答诸如文件来自哪里？它是受信任的实体吗？它是我们认为的同一个实体吗？该实体是否以某种意想不到的方式受到损害或修改？

解决方案提供商开始解决此问题的一些常见方法是查看与检索软件文件的 Web 域相关联的传输层安全性 (TLS) 证书信息，并确保证书有效，同时确保证书受信任。它是否有合理的有效期？它最近是否以不寻常的方式发生变化？公司名称是否符合预期？也许昨天是 Microsoft Corp.，但今天是 Microsoft, Inc.。这可能是需要调查的事情。最重要的是，创建正常基线和识别异常有助于组织识别来源的真实性或试图破坏它的行为。

DNS 信息是可能需要验证的其他信息。域名是否已更改为一组新的 IP 地址或地理定位到世界不同地区？对于可能根据互联网健康状况或请求者位置为来自世界各地的流量提供服务的内容交付网络 (CDN)，很难以高度的信心进行探索。有些人甚至提出，互联网路由劫持（例如多年来发生的 BGP 劫持）可用于提供恶意文件。这也变得非常难以验证，但这些场景对于威胁模型来说相当有趣。

通过根据这些标准进行检查并生成可以加密绑定到正在生成的 SBOM 的证明文件，我们可以进一步丰富 SBOM 中已经包含的出处数据。

构建证明

关于构建环境的证明对于增强软件工件的保证也非常有用。这些可以包括有关构建系统本身的信息，甚至可以验证构建活动中使用的流程或控制。

考虑一下，在软件工件供应链级别 (SLSA) 框架中，攻击目标之一是构建系统。如果攻击者可以破坏构建系统，您如何信任在该服务器上构建的任何东西？理想情况下，构建服务器与生产服务器正确隔离，并作为极其敏感的资产进行适当强化。验证服务器是否符合强化指南，例如安全技术实施指南 (STIG)，它们是安全模板，可提供额外的保证，确保构建服务器不太可能成为入侵源。有些供应链供应商（例如 TestifySec）将这些证明用作其自动化的一部分，甚至可以应用构建策略，要求通过 STIG 检查才能成功构建。

同样，您可能已经实施了一些流程，例如需要多个开发人员同意代码签入，然后才能继续构建。这些构建证明可以捕获上游流程所需的任意数量的安全要求，以用作构建流程的安全门，以及可用于验证高保证软件构建的证明。支持这一点的工具的一个例子是 OSS 项目“Witness”，它有助于创建证明并执行策略以确保软件供应链的完整性。（www.testifysec.com/blog/attestations-with-witness）

依赖管理和验证

随着开发人员对来自外部来源的软件组件的使用不断增加，管理这些库、包、组件或依赖项（通常称为依赖项）的需求也随之增加。正如我们所讨论的，依赖项通常被集成以节省开发人员和组织的时间和资源，并加快上市/任务的时间并加速创新。不可避免的现实是，您使用的依赖项越多，您必须管理的依赖项就越多。

依赖项通常在两种情况下讨论，即直接依赖项或传递依赖项。顾名思义，直接依赖项是您的应用程序直接引用和使用的组件。传递依赖项是您的依赖项本身使用的组件，从而创建了对依赖项的依赖关系。这两种类型的依赖项都有其相关的风险和注意事项。虽然好处很多，但随着直接或传递依赖项数量的增加，潜在风险也在增加。当然，其中包括许可问题，但从安全角度来看，它们还包括漏洞、恶意代码和攻击媒介的可能性。

Endor Labs 的《依赖管理现状》等报告指出了这一点。报告发现，95% 的漏洞存在于传递依赖项中，这增加了开发人员评估和解决的难度。此外，还有一项发现，50% 的最受欢迎的软件包在 2022 年没有发布，30% 的软件包的最新版本在 2018 年之前，导致代码陈旧且可能存在漏洞 (www.endorlabs.com/blog/introducing-the-state-of-dependency-management-report)。

使用许多依赖项还存在管理开销方面的挑战。开发社区本身使用了一个可爱的术语“依赖地狱”，因为安装依赖于其他特定版本软件包的软件包会带来挫败感。问题是由于多个软件包依赖于相同的共享组件但版本不同或存在兼容性问题的情况而发生的。

每个依赖项或组件都有其问题。包括库被废弃且未被维护、代码编写不当、没有文档，当然还有易受攻击的代码，如果维护人员仍然存在或目前是项目的积极参与者，他们可能会或可能不会修复这些代码。

话虽如此，组织可以采取一些最佳实践来减轻与依赖项管理相关的一些挑战和风险。这些建议包括确定哪些依赖项必须先于其他依赖项更新，使用诸如对项目的关键性或安全风险等因素。另一个建议，当然，说起来容易做起来难，是通过完全删除来最小化未使用的依赖项，只保留代码中需要的依赖项。不这样做会导致代码臃肿、攻击面增加和管理开销挑战。在许多情况下，您还可以自动更新软件依赖项，从而最大限度地减少与依赖项管理相关的手动工作量。在这种情况下，最受欢迎的示例之一是 Dependabot，它有助于自动更新各种编程语言（如 Ruby、JavaScript、Python 和其他几种语言）的依赖项。 Dependabot 得到了 GitHub 和 GitLab 等最大的持续集成平台的支持。

除了自动化之外，组织还应制定软件依赖关系管理策略。为组织的开发人员制定依赖关系管理指南可以确保整个组织遵循标准化方法，并可以实施治理，如 Microsoft 的 S2C2F 或 NIST 的软件供应链指南等框架中所述，我们将在第 6 章“云和容器化”中介绍。制定标准化的政策和流程有助于监控安全问题、提高应用程序性能和确保许可合规性。

软件依赖关系不会消失，而且整个行业对软件包、库和组件的大规模重用只会加速。这不可避免地导致需要适当的软件依赖关系管理和验证流程。未能实施结构化方法将导致安全风险得不到解决，从而给开发团队带来负担，这可能会阻碍交付并为许可违规敞开大门。

Sigstore

软件供应链安全的一个基本方面涉及对完整性、透明度和保证的需求。这就是 Sigstore 发挥作用的地方。正如本书中提到的那样，我们看到了对软件供应链的极大关注，尤其是在 SolarWinds 和 Log4j 等重大事件之后。NIST 在其网络安全供应链风险管理 (C-SCRM) 800-161 文档以及 CISA 中发布了网络安全 EO 和更新指南。我们还看到了白宫的关注，白宫于 2022 年初主办了软件供应链安全峰会。在那次峰会之后，Linux 基金会和 OpenSSF 发布了 OSS 安全动员计划，该计划的重点是使用数字签名来增强对软件供应链的信任。这项任务主要集中在采用和发展一种名为 Sigstore 的技术上。

Sigstore 是用于签名、验证和保护软件的标准。正如我们所讨论的，软件的使用在每个垂直行业和业务类别中都无处不在。然而，尽管我们使用软件的方式已经并正在改变世界，但确保我们在整个生态系统中使用的软件具有通常所需的完整性水平的方法却很少。软件供应链通常缺乏数字签名的使用，而当它没有使用数字签名时，它通常使用传统的数字签名技术，而这些技术在自动化、扩展和审计方面可能具有挑战性。

Sigstore 最初于 2021 年 3 月由 Red Hat 和 Google 合作发布，并作为 Linux 基金会的一个项目发布，旨在解决软件来源或构建方式的问题。Sigstore 特别致力于改善软件供应链的完整性和验证活动。

正如 Sigstore 联合创始人 Dan Lorenc 所说，Sigstore 是“为软件开发人员提供的免费签名服务，通过轻松采用由透明日志技术支持的加密软件签名来提高软件供应链的安全性。”正如 Sigstore 项目创始人、Red Hat 的 Luke Hinds 在博客“Sigstore 介绍”(https://next.redhat.com/2021/03/09/introducing-sigstore-software-signing-for-the-masses) 中所写，该项目基于一些真实的假设，例如很少有项目实施代码签名，以及密钥管理是一项困难的活动。从那时起，该小组问了自己一系列“如果”问题，例如“如果密钥不需要撤销或存储会怎样？”以及“如果所有签名事件都在安全媒介上公开，会怎样？”

采用

自推出以来，Sigstore 的行业采用率和兴趣度不断提高。尽管 Sigstore 是在 2021 年初才发布的，但它已经引起了一些最大的 OSS 项目的关注，其中之一就是 Kubernetes 项目。Kubernetes 是市场上规模最大、采用最广泛的容器编排平台。它宣布将以 Sigstore 为标准，并在其 1.24 版本中使用 Sigstore (https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73)。这使 Kubernetes 的消费者能够确保他们使用的发行版是用于消费的。除了这一认可之外，如前所述，OpenSSF 的 OSS 安全动员计划有一个专门用于数字签名的部分，重点关注采用和使用 Sigstore 作为软件供应链完整性缺口的解决方案。 2022 年初，Sonatype 宣布 Maven Central 将采用 Sigstore 作为解决软件供应链中出处问题的解决方案 (https://blog.sonatype.com/maven-central-and-sigstore)

Sigstore 组件

那么，Sigstore 到底是什么？它是如何工作的？为什么它很重要？Sigstore 的成立是为了帮助解决 OSS 供应链中现有的一些空白，以及我们如何处理完整性、数字签名和 OSS 组件的真实性验证。这至关重要，因为据估计，90% 的 IT 领导者都在使用 OSS（请参阅 www.soocial.com/open-source-adoption-statistics），组织优先考虑聘用 OSS 人才，而且我们已经看到了几起值得注意的软件供应链事件。Sigstore 汇集了多种 OSS 工具，如 Fulcio、Cosign 和 Rekor，以协助进行数字签名、验证和代码来源检查。代码来源是指拥有一条保管链的能力，显示代码的来源和来源。 Uber 隐私和安全团队在 https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5 上发表了一篇精彩的博客，讨论了他们如何处理代码来源路径。

要解压一些核心 Sigstore 组件，让我们从 Fulcio (https://github.com/sigstore/fulcio) 开始。Fulcio 是一个专注于代码签名的根证书颁发机构 (CA)。它是免费的，颁发与 OpenID Connect (OIDC) 相关的认证，并且经常使用开发人员已经关联的现有标识符。随着云原生架构和容器部署的快速采用和增长，对容器进行签名已成为一项关键的安全最佳实践 (www.csoonline.com/article/3656702/managing-container-vulnerability-risks-tools-and-best-practices.html)。密钥管理是一项繁琐的活动，通常由 CSP 或第三方提供商在云空间中作为托管服务提供。 Sigstore 通过支持 Cosign 的方式帮助缓解部分复杂性，并通过使用“无密钥签名”或使用临时密钥或临时密钥缓解部分密钥管理挑战（www.chainguard.dev/unchained/zero-friction-keyless-signing-with-kubernetes#:~:text=Keyless%20enables%20this%20signing%20process,Let's%20Encrypt%20did%20for%20TLS）。尽管使用了临时密钥，您仍然可以通过 Fulcio 的时间戳服务确保签名的有效性（www.chainguar.dev/unchained/busting-5-sigstore- myths）。

这就是 Cosign 的作用所在，因为它支持各种签名选项，并且可以无缝支持生成密钥对和签名容器工件以存储在容器注册表中。它使云原生环境能够根据公钥验证容器，并确保容器由受信任的来源签名。在构建期间对映像工件进行数字签名并验证这些签名是云原生计算基金会 (CNCF) 云原生安全白皮书 (https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) 中强调的一项关键安全最佳实践。

接下来是 Rekor (https://docs.sigstore.dev/rekor/overview)，它是一个不可变且防篡改的账本，是软件维护和构建活动的一部分。它使软件消费者能够检查元数据并对他们正在使用的软件及其整个生命周期中涉及的活动做出风险知情决策。回到我们之前关于软件来源的观点，开发人员可以使用 Rekor 通过透明日志为软件来源做出贡献。

另一个值得注意的方向是新兴的指南，例如软件制品的供应链等级（SLSA；https://slsa.dev/spec/v0.1/levels）和 NIST 安全软件开发框架（SSDF）（https://csrc.nist.gov/publications/detail/sp/800-218/final）。SLSA 第 3 级强调需要审计软件来源和完整性，这一点 Sigstore 支持，如前所述。SSDF 中提到的具体实践也指出了提供来源和验证机制的必要性。这很重要，因为联邦政府正逐步要求向政府销售软件的生产商按照 SSDF 中的实践进行证明（www.nextgov.com/cybersecurity/2022/02/nist-suggests-agencies-accept-word-software-producers-executive-order/361644）。通过采用 Sigstore，您可以使您的组织与这里讨论的新兴标准和最佳实践保持一致，并减轻可能导致安全事件及相关影响的关键软件供应链风险。

提交签名

在现代源代码管理中，Git 通常是事实上的选择系统。Git 允许各种实体（如作者和提交者）提交提议的更改。通常，这些实体是同一个人，但并非总是如此。也就是说，在许多情况下，通过设置用户名或电子邮件，冒充另一个提交者可能很简单。因此，特别是在敏感环境中，签署 Git 提交已成为一种最佳实践，这确保了你可以证明你是某段代码及其元数据（如时间戳）的作者。签名的提交虽然不能解决所有问题，但可以减轻一些潜在风险，例如前雇员试图通过冒充同事引入恶意代码或创建恶意拉取请求，而假身份有良好声誉。

签名提交不能阻止恶意行为者冒充他人，因为他们仍然可以尝试假冒身份，但没有数字签名将迅速引起那些足够关注的人的怀疑。

Git 通常使用 GNU Privacy Guard（GPG）等方法来促进签名提交。GPG 在 Git 中的工作原理是允许你将公钥上传到流行的 Git 平台（如 GitHub 和 GitLab），然后使用你的私钥签署提交。GitHub 提供了管理提交签名和签名提交的文档（https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits）。

SBOM 的批评和关注

如果我们不讨论一些在整个行业中 SBOM 采用过程中的常见批评、关注和挑战，我们将是不负责任的。

这些关注中最集中的来源之一是 NTIA 发布的 SBOM FAQ(www.ntia.doc.gov/files/ntia/publications/sbom_faq_-_fork_for_october_22_meeting.pdf)中的“常见误解与关注”部分，但其他行业的其他人也通过各种渠道提出了此类关注。

让我们来看看 NTIA 文件中列出的常见误解和担忧，以及其他一些误解和担忧.

攻击者的可见性

围绕 SBOM 的一个担忧是它们可能作为“攻击者的路线图”，这是它们常被提及的。这可以更广泛地描绘为围绕通过模糊性提供安全的辩论，这在网络安全行业已经持续了一段时间，双方都有合理的观点。通过模糊性提供安全通常总结为通过保密作为提供系统或组件安全的主要方法，而不是具体的安全控制和合理的安全工程。我们可以引用长期行业思想领袖 Daniel Miessler 的观点，他区分了良好的模糊性与糟糕的模糊性，指出“判断模糊性是好是坏的关键在于它是作为良好安全的层次使用，还是作为其替代品使用。前者是好的，后者是坏的。”（https://danielmiessler.com/study/security-by-obscurity）
Miessler 的观点是，保密在某些情况下肯定是有益的，但它不是合理安全工程的替代品。行业中的其他人认为 SBOM 可用于攻击 API，例如 Dan Epp 在其博客中所讨论的“Can SBOM Help You Attack APIs?”（https://danaepp.com/can-sbom-help-you-attack-apis）但即便如此，该文章也指出 SBOM 帮助防御者了解它们是否易受攻击以及在何处，这比进攻方面的担忧更重要，因为攻击者无论有无 SBOM 都会不可避免地寻找这些弱点。
针对 SBOM 是否为“攻击者的路线图”的问题，NTIA 指出，恶意行为者不需要 SBOM，因为事先了解不是攻击的前提条件。NTIA 还指出，恶意行为者已经有工具来识别软件组件，不受法律约束，因此可以这样做，而不像守法的道德用户。NTIA 声明，SBOM 将“拉平竞争环境”，为防御者提供他们已经拥有的同样的见解和透明度。恶意行为者能够使用二进制分析工具来理解软件组成和组件组成。虽然这点没有争议，但拥有 SBOM 将使软件消费者更好地理解与其使用的软件相关的初始风险，以及现有和新出现的漏洞。通过这样做，SBOM 帮助防御者了解风险并采取适当行动。

知识产权

围绕 SBOM 讨论的另一个常见担忧是知识产权和源代码。NTIA 反驳了这一点，指出 SBOM 不要求组织披露源代码，源代码是否共享由软件提供商自行决定。SBOM 专注于构建软件的组件，而不是披露源代码本身。软件组件代表部分情况，但不是软件实际运行的完整路线图。NTIA 的指南指出，了解第三方成分和整个执行配方之间存在显著差异，此外第三方组件不属于使用它们的软件供应商的知识产权，而是属于创建这些组件的上游实体，并受其创建时分配的任何适当许可证的约束。值得指出的是，尽管推动增加 SBOM 采用，但所有相关来源都建议适当保护 SBOM 本身，符合最低特权访问控制和知情即需的最佳实践。像 OMB 的 22-18 备忘录这样的来源，要求联邦机构可能需要从软件供应商获取像 SBOM 这样的工件，也要求机构在这些工件未公开发布时安全地存储它们。

工具和运营化

围绕广泛采用 SBOM 最有效的担忧之一是缺乏广泛可用的工具来促进创建、分发、摄取、丰富、分析和运营化 SBOM。现在许多人同意有足够的工具来帮助创建 SBOM，并且我们在整本书中多次提到它们。然而，撰写本文时，用于处理附加活动（如分发、摄取、丰富和分析）的工具仍在成熟中。如前所述，国土安全部（DHS）和网络安全基础设施安全局（CISA）等组织正在努力创新这一领域，以及商业领域，我们看到一系列商业公司正在进行研发投资和产品以填补这一空白。值得注意的例子包括 ChainGuard，该公司由前 Google 工程师创立，在 2022 年筹集了 5000 万美元。其他值得注意的例子包括 Endor Labs、TestifySec 和其他几家公司，包括行业领导者 Google，他们正在为组织提供帮助管理其 OSS 摄取和使用的创新软件供应链重点管理服务。再次引用美国联邦领域，OMB 的 22-18 备忘录还要求政府“建立一个集中存储库，用于软件证明和工件”，其中将包括 SBOM。
虽然围绕 SBOM 的担忧（如对攻击者的可见性、知识产权、工具和能力的成熟度）可能是有效的，但作为一个行业，我们普遍同意，透明度的推动及其带来的好处超过了这些担忧。这并不是说这些担忧完全没有价值，不应该被解决，但继续走不透明的软件生态系统的道路，无法了解底层软件组件及其相关风险和漏洞已不再可行。

第四章软件物料清单的兴起

4.6 总结

在本章中，我们讲述了 SBOM 的兴起，以及其从 NTIA 等机构开始的早期努力，现阶段则转移至美国联邦的 CISA。我么讨论了不同的 SBOM 格式，还提到了 VEX 概念的出现，这有助于减少因 SBOM 漏洞带来的一些问题。我们还探讨了一些常见的 SBOM 批评和关注点，并指出随着行业对 SBOM 的采纳和实施，这些领域将继续发展。

第五章软件透明度的挑战

在美国国家电信和信息管理局（NTIA）软件物料清单（SBOM）计划的早期讨论中，设备的 SBOM 主题作为一个复杂的因素出现。目前，人们的共识是，SBOM对许多组织来说是一个新概念，因此使讨论复杂化是不可取的。毕竟，设备软件和固件不就是软件吗？

第五章软件透明度的挑战

5.1 固件和嵌入式软件

我们将这一类别分为几个讨论领域：作为操作系统的固件、嵌入式设备的固件，以及 SBOM 在某些特定设备场景（如医疗设备）中的应用。

Linux 固件

作为操作系统的固件，特别是 Linux 固件，是最容易理解的，但需注意的是，这些 SBOM 非常复杂。Linux 实际上是由数千个软件产品拼凑而成的操作系统。因此，要获得所需的透明度来了解这些软件可能会很有挑战性。但这是该领域中较容易解决的问题之一。我们为 Linux 看到的许多工具往往只是运行一个 Red Hat Package Manager（RPM）命令，除非通过大规模逆向工程处理映像，或在构建过程中在每个软件对象级别生成 SBOMs。现实情况是，由于 Linux 操作系统的构建方式存在如此多的碎片化，依赖单一实体来产生高保真度的可见性可能是一个挑战。

实时操作系统固件

实时操作系统（RTOS）固件通常更具挑战性，因为传统意义上的 RTOS 并没有文件系统。很多情况下，RTOS 更像是一个二进制文件，而不是像 Linux 风格的固件映像。对 RTOS 作者来说，这是一个可以解决的问题，我们过去也见过 VxWorks 的公共 SBOMs。然而，对于某些工业控制系统的遗留或专有 RTOS（如不使用 QNX 或 VxWorks 的系统），这个问题常常是个盲点。逆向工程可能是处理遗留软件或供应商无法提供必要可见性时唯一可行的方法。

嵌入式系统

嵌入式固件通常是高度优化的小代码。可能是运行在系统芯片（SoC）上的代码，或系统 BIOS。这些代码常常是低级代码，人类很难理解这些固件的分析。此外，为了优化和减少固件的内存占用，许多字符串和符号被剥离，这使得传统的软件组件识别方法变得非常困难。结合高安全区（如可信执行环境，TEE），这些代码运行在一个受保护的区域，不仅增加了安全性，还增加了理解软件功能和运行位置的难度。这在尝试了解软件组件的可利用性或对手如何影响软件执行时尤为明显。

设备特定的 SBOM

在考虑 SBOM 在高度监管环境中的应用时，尤其是医疗设备，需要注意认证是针对设备层面进行的。美国食品药品监督管理局（FDA）可以将胰岛素泵认证为设备，医疗设备的 SBOM 通常只有一层深度。这通常更像是软件库存而非完整的 SBOM。由于这些设备受到高度监管，变化发生得不频繁，SBOM 和分析结果通常比较静态。但令人担忧的是，这些设备的功能有时可能不太依赖于设备上运行的代码，而是依赖于云基础设施和其他外部依赖项，这对很多物联网（IoT）设备尤其如此。这些设备的外部应用程序编程接口（API）、分布在全球的支持基础设施或其他外部依赖项带来了显著风险。尽管这些设备看起来技术上很成熟，但输入和信任关系的变化创造了一个软件透明度和供应链使用案例的盲点。此外，不同设备接收更新的情况也带来了挑战。有些设备可能通过无线网络、互联网或 USB 闪存盘接收更新，这可能导致相同型号的设备在任何给定时间具有不同的 SBOMs。

第五章软件透明度的挑战

5.2 开源软件和专有代码

在软件领域，代码主要分为两类——开源软件（OSS）和专有软件——这使得讨论软件供应链中的透明性变得复杂。OSS 与任何人都可以查看、使用和贡献 OSS 代码有明显不同。尽管存在一些所谓的“源代码可用”的专有软件（即源代码可以查看甚至修改，但不被认为是开源），专有代码通常不对外开放查看、使用或贡献，通常由开发各种业务软件的内部或外部的软件和技术供应商或组织控制。这种允许任何人使用 OSS 代码的能力也包括专有软件生产商，他们经常这样做。据估计，97％的软件至少包含一些 OSS 代码（www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf）。不仅几乎所有代码库中都包含 OSS，而且它通常可以占到代码库的近 80％。

在软件讨论中，“数字公地”一词经常被使用，它是“公地”的一个子集。公地被认为是帮助治理资源生产和集体行动的社会机构（https://policyreview.info/concepts/digital-commons）。在这种情况下，数字公地是公地的一个子集，涉及数据和信息的资源，以及数字领域中的文化和知识。当软件开发人员应用现有 OSS 许可证时，代码通常成为 OSS，这些许可证授予其他用户某些权利，这些权利通常是法律排他性授予的，例如编辑和重新分发代码的能力。一旦发生这种情况，任何获得项目数字访问权限的人都可以复制、使用、更改并提出对项目和代码的贡献。

软件产品通常与几种类型的软件许可证相关联，这些许可证通过条款、支持协议、限制和费用帮助管理其使用。软件许可证不仅定义了软件分发和使用的规则，还通常列出了最终用户在安装、保修和责任等方面的权利。在讨论 OSS 和专有软件时，OSS 软件许可证通常授予用户修改和重用源代码的能力，以及实际访问源代码本身的权限。专有软件许可证则通常不提供修改和重用代码的能力，当然也不提供对源代码的直接访问。有些情况下，软件不受许可证覆盖，被认为是公共领域软件或私人无许可证软件，如某些仍可能需要版权保护的商业应用。不遵守软件许可要求可能会产生后果，如允许版权持有人起诉或甚至使侵权者面临禁令。

常见的软件许可类型包括以下几种：

宽松许可 这些许可证对软件的修改或分发方式限制最少，但可能需要在后续分发中注明版权信息。常见示例包括 Apache、BSD 和 MIT 许可证。
弱 Copyleft 通常称为 GNU 较宽松通用公共许可证（GNU Lesser General Public License）（www.gnu.org/licenses/lgpl-3.0.en.html），它允许以最小义务链接到开源软件库，并且整个作品将在后续许可类型下分发，即使是专有许可证，要求最少。
公共领域许可证 每个人都可以自由使用和修改软件，无任何限制；这种许可证类型并不常见。
Copyleft 许可证也称为互惠许可证，在商业上可能比其他一些许可证类型更具限制性。Copyleft 允许开发人员修改许可证代码并将其纳入其他项目，甚至修改专有代码并分发，但必须在同一许可证下完成。原始软件和修改内容包含在新项目中，这使得此许可证对有商业利益的开发人员不太有吸引力。
商业/专有 这些许可证类型用于限制复制、修改和分发代码的能力。被认为是最严格的软件许可证类型之一，商业/专有许可证防止未经授权的使用软件，并且对商业利益最具保护作用。

除了许可方面的考虑，开源软件的使用非常普遍，如前所述，在专有软件和产品中也很常见。这是由于各种原因，例如节省开发时间、利用现有工作、降低成本并加快上市时间。使用开源软件代码可以使开发人员和团队专注于更多增值活动，如开发自定义代码或功能，专注于使命和业务目标。如本书简介中所述，开源软件代码几乎在每个环境中都很普遍，包括能源、金融、通信、医疗保健和国防工业基地等关键基础设施领域。尽管表面上看，开源软件的普及可能有意义，鉴于其带来的创新和社区合作，但也带来了挑战。研究发现，88％的代码库包含两年以上没有新开发的开源软件组件，81％的代码库至少包含一个漏洞，近 90％的代码库包含的开源软件不是最新版本。
这意味着过时、维护不善和易受攻击的开源软件存在于几乎所有社会领域，包括关键基础设施领域。
在专有软件方面，也存在独特的挑战。虽然开源软件通常在其来源中分配了常见漏洞和暴露（CVEs），如国家漏洞数据库（NVD），并可以使用漏洞扫描工具扫描以识别已知漏洞，但专有代码可能更难，需要其他技术来识别漏洞。此外，专有软件的源代码通常不公开，使得评估和分析不那么简单。推动 SBOMs 的使用将创造一个软件供应商和供应链在其产品中提供 SBOMs 的情况，同时还将揭示相关漏洞。
OSS 和专有软件在漏洞披露和修复方面存在明显差异。在专有软件方面，供应商通常有合同文件和协议，允许他们告知软件用户潜在的漏洞和风险影响。但在 OSS 领域则不然。因为 OSS 对所有人开放访问、使用、重用和修改，因此很难有一个集中通知或机制来通知任何受 OSS 项目或组件漏洞影响的人。这一问题因 OSS 组件被整合到其他项目和代码中作为依赖项而更加严重。这使得软件消费者必须彻底了解其环境中的软件，并警惕任何通知、漏洞和与这些软件组件相关的风险。
常有人认为 OSS 可以比专有软件更安全，因为代码是开放的，所有人都可以查看和分析。OSS 社区中一个常见的格言称为 Linus's Law 声称：“只要有足够的眼睛，所有的 bug 都是浅显的。”这似乎很直观，因为如果有足够多的软件开发人员和安全专家查看代码，bug 和漏洞的可能性会减少。尽管这在非常流行的 OSS 项目如 Linux 和 Kubernetes 上可能是正确的，但在更广泛的 OSS 生态系统中并不成立。OSS 项目数以百万计，其中一些可能有维护人员和贡献者的繁荣生态系统，而另一些则常由一小群人甚至单个人维护。一些研究表明，几乎四分之一的 OSS 项目只有一个贡献者（https://dl.acm.org/doi/abs/10.1145/3510003.3510216），更令人惊讶的是，几乎 95％的项目有少于 10 个开发者贡献了大部分代码（www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf）。值得注意的是，专有软件供应商也有资源限制，这意味着公司没有无限的开发资源，通常需要优先考虑创收功能和产品增强，而不是安全活动。资源限制增加了风险，这应是所有软件消费者的考虑，无论他们是消费 OSS 还是专有代码。通过模糊性实现安全的陈旧模式也基本被淘汰，许多专家同意模糊性对对手的帮助远大于对社区的帮助。尽管如此，这并不阻止一些组织试图隐藏在模糊性后面，要么是真正相信这会带来更好的安全结果，要么是因为害怕暴露他们知道但不愿披露的低效和漏洞。
OSS 代码和专有代码之间的另一个显著差异是 OSS 的工作方式，任何人都可以消费和使用它，公开披露是通知潜在受影响消费者和各方的唯一有效方法。没有统一的 OSS 组件用户列表，公开披露允许消费者采取行动，但也要求 OSS 消费者意识到这些披露，并最重要的是，理解其 OSS 消费，以便能够采取任何措施应对风险。在专有方面，组织可以通知其客户和消费者，因为通常有协议和合同，如合同、服务级协议等。
尽管 OSS 带来了一个繁荣的创新软件解决方案生态系统，这些解决方案节省了组织的时间、资源和麻烦，但它也带来了一个复杂的现代软件供应链，具有指数级的依赖关系。研究表明，平均应用程序和项目基于使用的编程语言有近 70 个依赖关系，平均应用程序也有至少 5 个关键漏洞。许多软件消费者不了解其依赖项的全部范围，从而不了解与这些依赖项相关的漏洞。这些研究表明，尽管广泛使用 OSS，受调查的一半组织没有管理 OSS 使用的安全策略。像国家标准与技术研究院（NIST）这样的组织建议采用最佳实践，如建立管理 OSS 使用的政策，并进一步建立已知可信 OSS 组件的内部存储库供开发人员使用，而不是允许不受限制地使用外部 OSS 组件。

第五章软件透明度的挑战

5.3 用户软件

用户软件与设备固件或用于管理网络和安全的企业级产品相比，往往带来截然不同的视角。通常情况下，这些软件被认为不是关键性的，因此常常未能引起足够的关注。然而，用户软件和常见工具却经常成为攻击的目标。考虑到任何软件都在用户许可下运行，并且许多组织仍然允许用户以本地管理员权限运行软件，这就表明，即使软件本身不需要管理员功能，也可以具备管理员权限。

作为行政命令14028的一部分，NIST提出了关键软件的定义，旨在确保新的软件物料清单（SBOM）要求仅限于最关键的应用程序。这在表面上是合理的，直到你意识到，软件本身并不关键，但其使用方式可能是关键的。NIST将关键软件定义为：

■设计为以提升的权限运行或管理权限的软件

■具有对网络或计算资源直接或特权访问的软件

■设计为控制对数据或操作技术访问的软件

■执行对信任至关重要功能的软件（来源：www.nist.gov/itl/executive-order-improving-nations-cybersecurity/critical-software-definition-faqs#Ref_FAQ3）

■在具有特权访问的情况下操作超出正常信任边界的软件

像Adobe Reader或Notepad++这样的用户软件实际上不符合上述任何一个标准，但在特定的威胁场景下，比如用户经常解析和查看来自不可信来源的外部文档，这些软件可能引入风险或成为攻击向量。特别是Adobe经常在钓鱼攻击方案中被妥协，尽管它可能不符合关键软件的要求，但同样提供了攻击的可信路径。

对这些用户软件而言，最大的挑战可能在于应对这些威胁所需的巨大范围和可扩展性。2021年12月Log4j漏洞披露后，本书的一位作者收到了一份包含超过一百万个CPE（通用产品版本）的列表，并被问及“其中有多少个容易受到log4shell漏洞的影响？”这个机构意识到，无论软件用于何种用途，只要存在这种漏洞，就像log4shell漏洞利用所展示的那样，可能轻易扩展到更为关键的目标上。

这个例子很好地展示了供应链攻击如何以复杂的方式突破边界。这些攻击并不是直接的，而是通过信任内部用户并未正确验证其行为、宽松的访问特性等方式，即使是最无害的软件也可能为攻击开辟一条通道。我们该如何应对这些挑战呢？在达到这个目标之前，我们需要时间来广泛采用本书中提出的指导。我们希望有一天，软件供应链的最佳实践能像食品检查员确保超市内所有食品安全消费一样普遍。然而，从现实角度来看，我们也明白在行业和社会层面，我们还有很长的路要走。

第五章软件透明度的挑战

5.4 遗留软件

如果我们看看开源生态系统中为解决供应链问题而推出的所有优秀项目，包括现代应用开发框架和工具，这无疑展现了一个特别乐观的前景。但是，这对于遗留软件意味着什么呢？

特别是在关键基础设施或国防领域——这些地方的系统使用寿命经常是20到30年，甚至更长——以及在没有使用包管理器的情况下生产的软件，源代码可能已经不再可用，原开发人员也许已经退休，或者更糟的是，已经不在人世了。我们面对的是一套截然不同的问题。在某些情况下，软件已经不再得到支持，或者只能定期应用定制补丁。在这些情况下，逆向工程可能是确定软件构成的唯一可行选项。不过，让我们再来探讨一下处理专有软件的另一个挑战，在遗留软件的背景下，这变得尤为有趣。

很久以前，几乎所有的软件都是专有的。虽然有时与学术界分享，或出于其他信息共享的原因，但总体来说，当我们思考当前开源软件（OSS）的定义时，带有明确定义的许可证的这种结构化概念，仅在过去大约25年左右才逐渐形成。当然也有一些例外，例如glibc（GNU C库）和GNU编译器集合（GCC），其中C编译器可以追溯到1987年。然而，当比较30多年前构建的软件和今天构建的软件时，我们会发现现代软件中有更多的组件是可以识别和理解的。

为什么开源概念如此重要呢？因为大多数应用安全工具今天并不考虑专有软件的生产过程。当前市场上绝大多数的软件物料清单（SBOM）工具只会告知您，基于已知的开源组件，您的软件是否存在漏洞。对于几乎没有或没有任何开源组件的遗留软件来说，这是一个巨大的盲点。事实上，许多SBOM工具只有在您的软件构建过程中使用了包管理器时才能发挥作用。虽然Linux已经使用包管理超过20年，但像Python和Node.js这样的现代语言的包管理工具只有大约10年左右的历史。现代的SBOM工具是根据当前的使用情况开发的，而不是几十年前在许多环境中仍然广泛使用的技术。例如，Python的包安装器pip是在2014年随Python 2.7.9引入的。

如果源代码不可用，静态分析工具就无法评估它。如果没有运行时环境进行仪表化，使用现代交互式应用安全测试（IAST）工具进行验证将变得非常具有挑战性。而且如果研究人员无法访问源代码，那么几乎可以肯定，没有公开的CVE（公共漏洞披露）能够帮助理解那些专有代码何时极为脆弱。事实上，在许多情况下，理解软件的构建方式几乎是一个黑盒子。唯一的救赎是，如果软件存在漏洞，且这不是一个新的风险。不利的一面是，这些软件往往是地球上一些最关键的软件，例如运行导弹发射井、核反应堆、水处理厂等设施的软件。

第五章软件透明度的挑战

5.5 安全传输

在供应链风险管理的核心是信任的概念，或信任的验证。这包括对软件来源或出处的信任，相信它不包含超出我们风险容忍度的组件或库，相信在到达我们之前没有发生变化，相信我们即将安装的是我们所预期的产品。

安全传输机制可以有多种类型，但我们常谈的是传输层安全性（TLS），它是安全套接字层（SSL）的后继者。TLS的任务是将数据从点A安全地传输到点B，并确保高度的信任，以保证内容保持机密性和完整性没有受到损害——信任信息的发送和接收方是我们所认为的那些终端，而且数据在传输过程中未经修改。虽然TLS也用于加密和保护数据流的保密性，使得透明性的任务更加困难，但它也使得操纵数据流变得更加困难。这是一个在透明性和安全性之间有意识的权衡领域。虽然你不能再直接查看数据流中的活动，但如果你信任源头并且数据没有发生变化——也无法发生变化——那么你就可以信任到达目的地的内容。

不幸的是，这些信任决策的根源是证书颁发机构（CA）基础设施。这种机制建立了一个支撑互联网运行的信任网络。它是一个相对集中的生态系统，因为如果CA被破坏，他们签发的TLS证书或代码签名证书也可能被破坏。然而，CA机制提供了一个合理的保障，即执行这些攻击所需的难度对于大多数组织的威胁模型来说是足够的，因此基于TLS的决策通常被认为是安全的。

如前所述，对手通常会滥用加密通道来隐藏他们的恶意流量。然而，由于现代TLS协议的特性，特别是使用完美前向保密等技术，使得解密和重新加密传输变得困难，甚至对防御者来说也是如此。这将潜在的风险限制在点A和点B之间，而消除了中间30多个网络跳点作为潜在的攻击点。

同样，我们需要能够信任用于风险决策的声明。我们如何知道软件物料清单（SBOM）或构建声明是合法的？透明日志和区块链技术提供了在交易起点（例如点A）上的透明性和信任，一些实现甚至可以实现端到端的透明性和信任。但是，我们如何确保通过网络传输的数据保持不变呢？幸运的是，利用TLS隧道可以帮助回答这些问题。

那么，如果软件和声明没有通过这种方式进行保护呢？这是否意味着它们是不安全的？即使在今天，许多现代的Linux发行版也并未通过TLS来保护其软件仓库的流量，而是依赖于GNU隐私卫士（GPG）签名来确保软件的完整性。在这种情况下，你需要根据自身的风险承受能力做出判断。不过，可以说，即使在2023年，如果你要求所有软件都通过TLS进行传输，很多企业软件的使用也会受到影响。

在TLS使用更加普及之前，我们认为这可能只是针对除了最关键软件以外的一种“可选项”。尽管实施TLS存在一些挑战，但像零信任（Zero Trust）这样的运动正在推动端到端加密，作为组织应采用的最佳实践和实施方式。

此外，越来越多的组织正在努力采用双向TLS（mTLS），它使用与TLS相同的协议，但进行双向验证而非单向验证。这意味着，在建立连接和进行数据交换之前，服务器和客户端的身份都需要得到验证。

第五章软件透明度的挑战

5.6 总结

总结起来，尽管推动软件透明度背后有着巨大的动力，但仍然有几个问题需要解决，而这些问题的解决可能具有挑战性。在本章中，我们讨论了一些问题，如嵌入式和遗留软件、开源软件及其各种许可类型，以及数据传输安全的需求。尽管如此，社区和生态系统中的供应商也在各自领域内不断创新和开发解决方案。持续解决这些挑战将有助于弥合软件透明度的差距，无论软件位于何处。在接下来的章节中，我们将讨论诸如云、容器和Kubernetes等技术在软件供应链和透明度讨论中的角色，以及它们所面临的一些挑战。

第六章云和容器化

虽然在传统的本地基础架构中追求软件物料清单（SBOM）和软件透明度具有挑战性，但在使用云服务和云原生架构时，挑战就大不相同了。在本章中，我们将讨论围绕云和容器化增长的一些指标，以及云计算背景下的软件透明度和供应链安全问题。在讨论技术时，拥有一个共享的词汇表通常会有所帮助。话虽如此，云计算最常用的定义来自 NIST 800-145 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf)，其中指出：云计算是一种模型，用于实现对可配置计算资源（例如网络、服务器、存储、应用程序和服务）共享池的无处不在、便捷、按需的网络访问，这些资源可以快速配置和发布，且管理工作或服务提供商交互最少。此云模型由五个基本特征、三个服务模型和四个部署模型组成。进一步扩展，这些特征包括按需自助服务、广泛的网络访问、资源池、快速弹性和可衡量的服务。云还具有三种服务模式：基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。每种服务模式都有自己独特的共享责任模式，以及对软件如何到达下游消费者的相关影响。云计算有四种主要部署模式：私有云、社区云、公共云和混合云，每种模式都对多租户和安全等主题有影响。与云计算相关的每一种独特模型仍然以某种形式涉及软件，并要求下游消费者对他们所消费的服务和相关软件的安全性有一定程度的保证。

第六章云和容器化

6.1 共担责任模型

如果不涉及共享责任模型 (SRM)，关于云的安全性和风险的讨论就不完整。许多企业领导者仍然会问“云安全吗？”，这是一个错误的问题。更合适的问题是“作为安全团队和组织，我们是否确保了我们在云消费中的份额？”

绝大多数云数据泄露和泄漏都是由于客户造成的，IT 研究和咨询公司 Gartner 预测，到 2025 年，大约 99% 的云安全故障将是客户的错误 (www.gartner.com/smarterwithgartner/is-the-cloud-secure)。因此，所有安全从业人员都必须了解自己的责任.

共担责任模型的细分

SRM 描述了您（云客户）负责什么以及您的云服务提供商 (CSP) 负责什么。在 IaaS 模型中，CSP 负责云的安全性 — 比如物理设施、公用设施、电缆、硬件等。客户负责云的安全性 — 即网络控制、身份和访问管理、应用程序配置和数据安全。

共担责任模式的职责

也就是说，这种责任划分可能会根据您使用的服务模型而改变。从基本层面上讲，NIST 对云计算的定义解释了三种主要的云服务模型：

■ 基础设施即服务 (IaaS)：在 IaaS 模型下，CSP 负责物理数据中心、物理网络和物理服务器/托管
■ 平台即服务 (PaaS)：在 PaaS 模型中，CSP 承担更多责任，例如修补（客户过去在这方面做得很差，并且是导致安全事件的主要途径）和维护操作系统。
■ 软件即服务 (SaaS)：在 SaaS 中，客户只能在应用程序的配置设置中进行更改，其他所有控制权都留给 CSP。（Gmail 是一个基本示例。）值得注意的是，即使在 SaaS 环境中，在 SaaS 治理和安全方面也有很多工作要做，我们将在本章后面深入讨论。

每种方式都有其代价，客户放弃控制权，以换取更多的交钥匙管理体验，而 CSP 则处理更多的运营活动，让客户专注于自己的核心竞争力。许多组织发现这种模式很有吸引力，因为管理计算和基础设施通常不是他们的核心业务，而是他们为提供核心服务和产品而必须执行的活动。

每个 CSP 都有不同版本的 SRM。图 6.1 是 Microsoft Azure SRM 的一个示例（https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility）

虽然 SRM 涉及合同和财务影响等非安全问题，但它也包括一些安全考虑因素。安全从业人员必须根据他们所使用的服务以及组织的实施和架构了解他们在 SRM 中的责任。

还记得几乎所有云数据事件都发生在 SRM 的客户端吗？这是了解 SRM 并确保您正在履行模型职责的主要原因。另一件我们再怎么强调也不为过的是，虽然可能存在责任分担，但您不能将责任外包。作为一个组织，您最终仍然是数据所有者，并对这些数据及其所属的利益相关者负责，即使您决定在向客户或利益相关者提供服务和业务时使用第三方（例如 CSP）。虽然涉及客户数据泄露的 CSP 可能会产生合同后果，但客户将承受声誉、品牌和监管后果方面的后果。

您的职责取决于您拥有两种主要安全角色中的哪一种：技术安全从业者或安全主管。技术安全从业者（例如云安全工程师或云安全架构师）必须了解您的组织使用哪些云服务；如何安全地构建这些解决方案；以及哪些配置、设置和控制属于您的职权范围，您可以影响这些配置、设置和控制并实现更强大的安全态势。一个明显的例子是，云原生供应商 SysDig 在其 2023 年的“云原生安全和使用情况报告”中发现，云环境中 90% 的授予权限未被使用。这与行业对零信任的推动相矛盾，并为攻击者滥用受损帐户留下了很多机会（https://sysdig.com/press-releases/sysdig-2023-usage-report）。

技术安全专业人员应该非常熟悉其组织使用的平台和服务，并了解如何安全地实施它们。云安全工程师/架构师经常与工程和开发团队合作。如果您无法引导他们找到安全的解决方案或发现有风险的配置（请记住，这些配置是大多数云数据事件的根源），您的组织可能会面临巨大的风险。

向您的 CSP 寻求安全资源。例如，Amazon Web Services (AWS) 提供了一个令人难以置信的安全文档数据库，按类别（例如，计算、存储、安全、身份和合规性）细分，您可以在其中找到与您的组织使用的每项服务相关的具体信息。这包括广泛的信息，从如何安全地配置服务，到您可以操作哪些配置，再到故障排除指南。

安全主管需要考虑的关键因素包括清点服务使用情况（你必须知道组织内正在使用什么，否则你就无法保护它）、确保所使用的服务符合适用的监管框架，以及了解合同/法律方面的问题，如 CSP 服务级别协议 (SLA)，尤其是涉及事件响应计划等方面的问题。其中一位作者贡献的一种资源是云安全联盟的云事件响应框架（https:// cloudsecurityalliance.org/artifacts/cloud-incident-response-framework）。

许多组织与 CSP 建立合作伙伴关系并分担责任。这包括确保您使用的服务符合您必须遵守的监管框架。超大规模 CSP 使这些信息易于查找，AWS 和 Microsoft Azure 提供了“范围内的服务”页面，您可以在其中确定哪些服务符合哪些框架，哪些服务仍在审批流程中或尚未评估和评估。这有助于确保您的团队不仅在云中构建强大且安全的架构和工作负载，而且还使用符合适用框架的服务，以避免合规性或法规问题，并使用他们有保证的服务。

各级安全从业人员都应努力在其云环境中实施安全标准和最佳实践。这可能意味着从各自的 CSP 实施安全最佳实践，或者为各自的云环境实施诸如 Internet 安全中心（CIS）基准测试之类的内容（www.cisecurity.org/blog/ foundational-cloud-security-with-cis-benchmarks）。

处理 SRM 时的一个基本工件是客户责任矩阵（CRM），它列出了 CSP 提供哪些控制以及哪些责任留给云消费者。查找 CRM 模板并了解有关它们的更多信息的一个地方是联邦风险和授权管理计划（FedRAMP）。FedRAMP 是一个程序，用于处理美国联邦政府（www.fedramp.gov/updated-Control-implementation-summarycis-and-customer-responsibility-matrix-crm-templates）使用的云服务产品/服务的授权。

CRM是安全从业人员使用的关键工具。在 SRM 中，安全控制完全由 CSP 提供，混合控制（责任由云客户承担），或完全留给客户。安全从业人员可以利用CRM来清楚地了解这种安全控制描述。这些通常分别是指完全、部分或不可继承的安全控制。

使用云服务可以将某些安全控制和活动的责任转移到 CSP，并让组织专注于其核心竞争力。它创造了一种责任关系，安全专业人员必须理解并适当地处理。请记住，大多数云数据泄露将发生在 SRM 的客户端，归根结底，您对组织的声誉负有全部责任，而 CSP 代表了另一个第三方提供商，在推动软件透明度和软件供应链安全方面必须考虑该提供商。

第六章云和容器化

6.2 云原生安全的4C

将云原生生态系统情境化的一种有用方法是通过 Kubernetes 文档中描述的“云原生安全 4C”，此处讨论的图 6.2 中所示的容器编排器。

图6.2

在此特定于容器及其编排的上下文中，您拥有云、集群、容器和代码，每一层本质上都依赖于其上层（或之前层）的各种形式的基础设施和部署到其上的代码。

如前所述，云范式具有 NIST 定义的三种商定的服务模型。云消费的主要方法之一是 IaaS，组织利用 CSP 的物理设施、实用程序、人员和基础设施来部署操作系统和应用程序。在这种模式中，CSP 负责底层基础设施、公用事业、设施、人员和一般资本支出（CapEx）成本。领先的 CSP 为网络、计算和存储等关键领域的使用提供强大的云服务。然而，这些服务仍然由软件提供支持，就像大多数现代基础设施一样。这意味着它们仍然容易受到与软件相关的漏洞和漏洞的攻击。虽然云消费者是从 IaaS 模型中的底层基础设施中抽象出来的，但这并不意味着他们完全不受可能影响它的风险和威胁的影响。这正是 Log4j 漏洞中发生的情况。主要的 CSP（AWS （https://aws.amazon.com/security/ security-bulletins/AWS-2021-006）、Azure （https://msrc-blog.microsoft .com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2）和 Google Cloud （https://cloud.google.com/log4j2-security-advisory）都发布了与 Log4j 对其云服务产品的影响相关的公告。

这些 CSP 与更广泛的 IT 行业非常相似，使用无数的开源库和组件来支持其多样化的云服务组合。从上述 CSP 的公告来看，这种单一的开源软件供应链妥协对其云原生服务组合产生了影响，而且并不止于此。这些 CSP 的收入高达数十亿美元，为数千个组织和数百万个人提供支持。当组织在这些 CSP 产品/服务之上构建和交付应用程序和服务时，基础服务产品中的软件供应链泄露或漏洞不仅会影响使用型组织，还会影响其业务合作伙伴、客户和利益相关者。对于前面提到的超大规模 CSP，这些客户甚至包括美国最关键和最敏感的工作负载，因为 CSP 由国防部（DoD）、情报界和联邦民事行政部门（FCEB）机构等组织使用。

这一现实要求确保云客户正在使用的服务以及支持他们的相关软件。虽然已经制定了成熟的计划，例如 FedRAMP （www.fedramp.gov）或 SOC2 （https://us.aicpa .org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report），但他们传统上并没有从清点和了解为现代云原生服务产品提供支持的底层软件供应链以及与该软件相关的风险的角度来看待软件。这些计划着眼于更传统的风险评估方法，例如 CSP 策略和流程、基础计算实例的漏洞扫描结果以及渗透测试。随着软件供应链日益成为 IT 和网络安全领导者关注的焦点，我们可能会看到一种转变，即 FedRAMP 等授权计划开始要求 CSP 为其面向软件的托管服务产品提供 SBOM 等项目。美国联邦政府已经通过发布管理和预算办公室（OMB）备忘录 22-18 （www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf）表明了这一意图，该备忘录将让各机构可能要求工件，包括第三方软件生产商向联邦政府销售软件的 SBOM，其中当然包括云提供商。它还要求第三方软件供应商提供自我证明，证明他们遵循安全的软件开发实践，例如NIST的安全软件开发框架（SSDF）和其他NIST软件供应链安全指南。

然而，考虑到AWS、Azure和谷歌等超大规模CSP的广度和规模，这是具有挑战性的，他们无疑拥有大量的软件库存来支持他们的云服务产品。它也与目前的方法主要基于第三方评估组织（3PAO），其中第三方评估服务提供商并提供与提供商的内部实践和安全流程相关的工件和证明。云和托管服务产品通常努力从消费者那里抽象出一些潜在的复杂性，以换取消费者体验和便利性。值得注意的是，在前面提到的 OMB 22-18 备忘录中，它允许软件生产者自我证明他们使用了安全开发实践。但是，如果机构认为有必要，它确实允许机构要求提供 3PAO。然而，考虑到当前的环境、工具和组织能力，如何为每个云服务大规模发挥作用是不切实际的。

虽然 IaaS 不可避免地涉及软件，但围绕软件供应链安全的对话在云原生架构的其他方面要成熟得多，例如容器、Kubernetes、代码和越来越多的 SaaS。

第六章云和容器化

6.3 容器

云原生生态系统延续了物理服务器和虚拟机（VM）等传统计算模型，广泛使用容器。因此，当涉及到容器及其相关的编排系统（如 Kubernetes）时，我们必须讨论容器和相关的软件供应链问题。

随着计算抽象的成熟，我们已经看到了从虚拟机（VM）到容器的转变。根据行业领导者 Docker 的定义，容器是“打包代码及其所有依赖项的标准软件单元，因此应用程序可以快速可靠地从一个计算环境运行到另一个计算环境。容器比 VM 更轻量级、更动态、更可移植，后者需要每个 VM 都有一个来宾操作系统（参见图 6.3）。

图6.3

容器的主要好处之一是它们允许开发人员将他们的软件代码、相关库和依赖项打包到一个轻量级的工件中。此项目是可移植的，能够在支持基于容器的部署的各种托管环境和基础结构中运行。

虽然这种捆绑对可移植性和效率等活动非常有益，但它也为不安全或易受攻击的依赖项打开了大门，这些依赖项可以包含在容器中，然后大规模复制。这种情况也经常发生，在公共容器映像存储库（如 DockerHub、Google Container Registry 等）中，任何人都可以使用容器映像来使用和重用。

事实上，帕洛阿尔托的 Unit 42 威胁研究小组 2021 年的一项研究发现，在对 1,500 多个公开可用的容器映像的研究中，96% 的映像中存在已知漏洞，并且 91% 的映像至少存在一个严重或高度漏洞，具体取决于 CVSS 等来源的严重性评分（www.paloaltonetworks.com/content/dam/pan/en_US/assets/ pdf/reports/Unit_42/unit-42-cloud-threat-report-2h-2021.pdf）。

这项研究还指出，图像的依赖关系越多，平均而言，它就越有可能具有更高的漏洞计数。因此，诸如减少攻击面或将依赖项和代码的数量最小化到仅容器和应用程序运行所需的依赖项和代码数等工作被广泛认为是安全最佳实践。

与其他形式的应用程序和软件交付非常相似，部署容器也保证了透明度。通过对容器使用 SBOM，您可以查看容器映像中的每个项目，这有助于识别软件供应链中的漏洞并在整个软件开发生命周期中进行修复。这包括从源、生成、暂存、部署和运行时阶段。漏洞可以在整个开发周期的任何阶段引入，因此在整个过程和阶段生成 SBOM 可以允许在整个生命周期中查看映像以及引入风险的任何更改。

尽管易受攻击的图像普遍存在，但创新工具正在出现，以帮助提供容器及其所需的软件组件和依赖项的透明度。Anchore 等领先供应商已经开发了允许组织生成 SBOM 的 OSS 工具。Anchore 的 SBOM 工具被称为 Syft，拥有一组强大的功能和语言支持。功能包括为容器映像、文件系统等生成 SBOM;支持开放容器计划（OCI）和 Docker 映像格式;以及使用 in-toto 框架支持已签名的 SBOM 证明的能力。（证明是我们将在本书的其他领域讨论的一个概念，例如第 11 章“消费者实用指南”。

Syft 支持领先的 SBOM 格式，如 CycloneDX 和 SPDX，如第 4 章“软件物料清单的兴起”中所述。另一个广受欢迎的 OSS 扫描仪是 Trivy，来自 Aqua Security 的团队。它支持以容器映像、文件系统、Git 存储库和 Kubernetes 资源为目标，以识别 CVE、OS 包和依赖项，以支持 SBOM 和声明性基础结构即代码中的错误配置。

容器领导者 Docker 甚至添加了原生 SBOM 功能。2022 年初，Docker 宣布能够简单地从 Docker Desktop 的 CLI 运行 docker sbom 并为任何 Docker 映像生成 SBOM （www.docker .com/blog/announcing-docker-sbom-a-step-towards-more-visibility-intodocker-images）。此功能是在开源社区和 Anchore 团队的协作下开发的，使用我们之前讨论过的 Syft 项目。Docker 团队解释说，这个附加功能旨在提高对供应链的信任，以查看映像中包含的内容，并使开发人员轻松完成该过程，以免妨碍生产力或速度。

从软件供应链的角度来看，容器及其相关生态系统存在广泛的潜在攻击媒介和需要考虑的风险。虽然很难列举每个攻击媒介，但我们肯定会在这里看到一些主要的攻击媒介，包括基础镜像、操作系统、Git 存储库、应用程序代码和依赖项以及 OSS 组件。由于云原生环境中涉及开发、安全和运营的团队数量众多，再加上保护容器的各种安全层，容器安全也变得更加复杂。这些涉及容器映像及其包含的软件、容器和主机操作系统之间的交互，以及在编排平台上运行的其他容器。此外，还存在与容器网络和存储以及容器在生产环境中部署到的运行时环境相关的攻击媒介和风险，该环境通常位于 Kubernetes 集群之上。

在讨论基础映像时，就像软件供应链中的任何上游组件一样，所有下游消费者和用户都可能受到供应链上游引入的风险的影响。基础映像是容器软件供应链中的关键步骤，因为在容器上运行的软件应用程序会继承构建应用程序的基础映像中包含的任何安全债务和漏洞。多个容器安全指南来源推荐的一个关键最佳做法是使用强化的基础映像。通常，这意味着基础映像已经过强化以减少漏洞，并且还被剥离为仅包含功能所需的基本要素。这通常称为攻击面减少，即删除不必要的组件，这些组件可以被利用来破坏容器及其上的应用程序。一些最受欢迎的基础映像包括 Alpine、Ubuntu 和 Debian。

在最小化容器攻击面的推动力中，出现了所谓的“无发行版”容器映像。无发行版容器映像仅包含应用程序及其运行时依赖项，从而删除了通常伴随常见 Linux 发行版的组件，例如包管理器、shell 或其他程序。NIST等来源在其“应用程序容器安全指南”（https://csrc.nist.gov/publications/detail/sp/800-190/final）以及行业领导者（如Liz Rice）的《容器安全》（O'Reilly Media，2020）一书中经常将最小化容器的攻击面作为最佳实践，该书讨论了减少攻击面以及其他容器安全建议。除了减少攻击面之外，无发行版图像还具有多种好处，例如最大限度地减少由于虚假 CVE 引起的扫描程序噪音、减少出处负担以及在大小方面更有效率，正如 Google 的容器工具无发行版 GitHub 页面（https://github.com/ GoogleContainerTools/distroless）中所引用的那样。

软件供应链安全初创公司 Chainguard 推出了 Wolfi，这是一套无发行版映像，在 CVE 方面比大多数传统容器映像（www.chainguard.dev/unchained/introducingwolfi-the-first-linux-un-distro）更安全。Chainguard 还开始引入对内存安全容器镜像的追求，这与 NSA 等来源关于将行业转向更安全的内存安全语言和生态系统的更广泛建议一致。

与其他 OSS 组件非常相似，组织通常从开放的 Internet 获取容器映像，当涉及到容器时，最受欢迎的来源之一是 Docker Hub （https://hub.docker.com）。顾名思义，Docker Hub 由 Docker 运行，用于查找容器映像并与团队和组织共享。为了正确看待 Docker Hub 及其托管的相关映像的受欢迎程度，在撰写本文时，该站点上有 20 张映像已被下载至少 10 亿次。也就是说，与任何其他软件组件一样，这些容器映像在映像文件中通常存在多个漏洞，组织可以通过在使用它们之前不进行尽职调查来继承这些漏洞和技术债务。如前所述，研究已经确定，Docker Hub 上公开提供的映像中，超过 90% 包含已知漏洞，其中极高比例的映像包含至少一个严重或高漏洞。再加上数十亿的下载量，您可以想象有多少易受攻击的容器在世界各地的企业环境中运行。

软件供应链供应商 Chainguard 等组织的进一步研究使用容器漏洞扫描工具 Trivy、Snyk 和 Grype 通过 Docker Hub （https://uploads-ssl.webflow.com/6228fdbc6c97145dad2a9c2b/624e233 7f70386ed568d7e7e_chainguard-all-about-that-base-image.pdf）上的下载量来评估一些最流行的基础映像。Chainguard 发现，Node、Debian、Ubuntu 和 Red Hat UBI 等领先镜像都融入了大量的技术债务。这些图像的漏洞计数从 28 个到高达 800 个不等，具体取决于图像和使用的扫描程序。漏洞严重程度从低到严重不等，在所使用的三个漏洞扫描程序中，只有 Alpine： 3.15.0 映像不包含已知漏洞。正如该研究指出的那样，与其他产品相比，Alpine之所以得分如此之高，是因为它是一个面向安全的基础映像，包含不到10个软件包。这是一个减少攻击面和创建基础映像的示例，这些映像考虑了安全性，以降低组织风险。显然，容器化应用程序的每一层都可能增加风险状况，但建议从适当安全且最小的基础映像开始。

不仅基础映像是一个值得关注的话题，而且组织越来越多地采用建立强化容器的内部存储库的做法，这些容器已经过攻击面减少和强化，并由受信任的实体签名。这降低了团队从公共源拉取容器映像的可能性，因此他们可能会改用内部批准和存储的映像，以满足组织的安全性和合规性要求。最明显和被引用的例子之一是国防部（DoD）的 Iron Bank （https://p1.dso.mil/products/iron-bank），这是一个容器存储库，其中包含经过强化、批准和授权的容器映像，供美国空军（USAF）和更广泛的国防部使用。美国联邦民事机构也利用了这些强化映像，并紧随其后，建立了自己的内部安全容器映像存储库，以供使用和部署。

公共 Git 存储库代表了另一种可以在容器软件供应链中引入风险的途径。虽然与映像关联的 CVE 是衡量容器安全性的重要指标，但了解它们来源的存储库是另一个衡量标准，可告知组织对固有或潜在风险的理解。一个流行的项目，着眼于与公共GitHub项目及其存储库相关的配置和活动，是OpenSSF记分卡计划，我们将在第7章中讨论，标题为“现有和新兴的商业指南”。

应用程序代码、依赖项和 OSS 组件都存在风险，这些风险也可能导致容器镜像的漏洞配置文件。因此，在将容器引入运行时环境之前，使用应用程序安全最佳实践非常重要，例如对通过持续集成/持续交付（CI/CD）管道的容器实施静态应用程序安全测试（SAST）和软件组合分析（SCA）扫描。这些工具可以帮助识别容器内代码中的漏洞，这些漏洞可以在引入生产环境之前进行修正，恶意参与者可能会利用这些漏洞。

也就是说，尽管在生产之前将安全性向左转移并识别管道中或在构建期间的漏洞是很好的做法，但它们并不能减轻对运行时容器分析和监视的需求。管道中可能遗漏了漏洞，或者部署后可能出现了新的漏洞，因此除了管道可见性之外，组织还需要对容器运行时进行监视。正如云原生所提到的Computing Foundation （CNCF）的云原生安全最佳实践白皮书（https://cncf.io/blog/2022/05/18/announcing-the-refreshedcloud-native-security-whitepaper），云原生工作负载需要安全性控件贯穿其整个生命周期，包括运行时。如果正确的工具和可见性已到位，安全团队可以了解运行时环境中的漏洞，更新容器映像并重新部署不再脆弱的映像。

需要指出的是，现代应用程序也绝大多数由开源代码和组件组成。安全领导者 Snyk 等组织发现 80% 的应用程序代码由 OSS （https://snyk.io/wp-content/uploads/Snyk-Docker-ContainerSecurity.pdf）组成。当然，这种开源代码包含直接依赖关系和传递依赖关系，每个依赖关系都包含各自的漏洞。除了OSS代码和组件之外，容器镜像也是分层创建的，每一层的工具、库和附加组件都代表了引入风险的可能性。通过管理和控制添加到容器文件的其他代码和层，组织可以控制引入的风险。

使用容器时的另一个关键问题是主机基础结构本身。如前所述，这意味着 Kubernetes 集群作为业务流程协调程序运行，但也存在诸如底层 VM 之类的问题。这些问题包括 VM 的强化、其选择的操作系统以及与主机实例关联的网络控制。我们将在下一节中对此进行更多探讨。

第六章云和容器化

6.4 Kubernetes

容器编排通常被定义为自动执行操作工作以运行容器化工作负载和服务。虽然有几种潜在的容器编排工具可供选择，但 Kubernetes 在采用和使用方面无疑是行业领导者（https://kubernetes.io）。

Kubernetes 起源于 Google 的一个容器编排项目，并在采用和使用方面迅速增长。CNCF 2021 年的一项调查发现，96% 的受访者表示使用 Kubernetes，其中 70% 的受访者表示他们在生产中使用 Kubernetes（www.cncf.io/wp-content/ uploads/2022/02/CNCF-AR_FINAL-edits-15.2.21.pdf）。据估计，全球有 390 万 Kubernetes 开发人员，同比（YoY）大幅增长。在一项类似的红帽调查（www.redhat.com/en/enterpriseopen-source-report/2022?intcmp=701f2000000tjyaAAA）中，85% 的 IT 领导者认为 Kubernetes 对他们的云原生应用程序战略极其重要或非常重要。

如前所述，Kubernetes 的起源可以追溯到 Google 的早期内部项目，最著名的是 2003 年左右的 Borg 系统。这个项目发展成为一个名为 Omega 的项目，这是谷歌在 2013 年推出的另一个集群管理系统。最后，在 2014 年，Google 开源了 Borg，并将其作为 Kubernetes 引入。从那时起，Kubernetes 的采用和增长才得以加速，推出了额外的版本和功能以及强大的爱好者生态系统。相关的行业活动，如 KubeCon，一个面向 Kubernetes 和云原生生态系统的会议，吸引了来自行业领导者的参与者，并重点介绍了该领域的一些新兴功能和创新。

尽管 Kubernetes 发展迅速，但一些软件供应链组织仍然与 Kubernetes 及其相关技术的使用和实施有关。Kubernetes 在架构上由 Kubernetes 集群中的多个组件组成。这些组件包括 Kubernetes API 服务器。Kubernetes API 服务器验证和配置 Kubernetes 对象的数据，包括 Pod、服务、复制控制器和其他 Kubernetes 实体。

2022 年，每天积极扫描整个互联网 IPv4 空间的 Shadow Server 组织能够找到 380,000 个公开暴露的 Kubernetes API 服务器（www.shadowserver.org/news/over-380-000-open-kubernetesapi-servers）。他们的研究指出，他们能找到的已知 Kubernetes 实例中有 84% 是公开的，并返回 HTTP 200 OK 响应。许多安全和 Kubernetes 专家指出，这并不意味着这些集群不安全或易受攻击，因为它们的存在通常是由于 CSP 托管 Kubernetes 服务的默认配置。但是，它确实显示了轻微的错误配置如何暴露集群、容器和在其上运行的代码。真正的错误配置可能允许恶意参与者破坏群集及其工作负载，并可能横向转向其他组织资产。

与 Kubernetes 供应链威胁相关的另一个促成因素是 Kubernetes 是通过清单文件实现的。这些是声明性 YAML 或 JavaScript 对象表示法（JSON）配置文件，用于描述 Kubernetes 集群的运行方式，定义各种 Kubernetes API 对象的所需状态。这意味着它们是用代码编写的，并且能够像其他形式的传统代码和配置文件一样保存、存储和共享。
使用各种资源管理复杂的 Kubernetes 部署可能是一项复杂的任务。通常，组织将使用 Helm 图表，这是一种用于描述一组相关 Kubernetes 资源的文件集合的打包格式。Helm 图表与 Kubernetes 资源非常相似，通常以 YAML 格式进行描述。它们被存储、共享和可用在诸如 Artifact Hub 之类的地方，Artifact Hub 是一个基于 Web 的应用程序，可用于查找、安装和发布各种 CNCF 项目（包括 Kubernetes）的包和配置。

虽然使用现存的Helm图表和配置文件可以加快实现和部署的时间，但这样做也会带来传统软件代码存在的风险，如恶意或易受攻击的代码或配置。例如， Palo Alto的研究小组Unit 42在他们的“2H 2021”白皮书中研究了Kubernetes和Helm（https://paloaltonetworks.com/prisma/unit42-cloud-threat-research-2h21.html）。研究人员使用一种名为“helm-scanner”的工具来评估Artifact Hub上的Helm图表和YAML文件，发现超过99%的图表容器有不安全的配置，近10%的容器至少有一个关键或高度不安全的配置。

研究人员还指出，与代码类似，Helm图表通常依赖于其他图表，他们在图表中识别的62%的错误配置是由于依赖图表。他们还指出，依赖项计数越高，平均错误配置计数就越高。这些错误的配置包括诸如过度特权的容器和不安全的网络配置等项。因此，尽管现代应用程序和工作负载经常被部署在 Kubernetes的容器上，但 Kubernetes的配置文件和图表经常被复制和共享固有的漏洞和错误配置本身，潜在地威胁到驻留在这些集群上的所有工作负载。

在 Kubernetes的背景中，配置和声明性显示构成了自己的风险，但恶意行为者通常是在 Kubernetes工作负载并使用容器图像的生命周期渗透 Kubernetes供应链之后。这些攻击向量可能包括基本映像、应用程序代码和依赖关系、存储库、OSS组件和其他相关资源。如果邪恶的参与者可以让恶意代码在容器化的工作负载上运行，特别是没有适当的Kubernetes安全配置，它们不仅会影响单一的工作负载，还可以影响集群中其他潜在的工作负载，或者更广泛的说，影响组织的企业系统，这取决于适当的架构和配置。在Kubernetes的背景下确保适当的供应链安全将意味着确保您有一个安全的 Kubernetes的体系结构和配置。

对于想从这方面着手的组织团体的建议当然是Kubernetes文档和最佳实践，但也要利用行业指导的形式下的来源，如 Kubernetes CIS Benchmark（www.cisecurity.org/benchmark/kubernetes）或Kubernetes Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG)。这些指导源集中于核心活动，如保护Kubernetes 体系结构的控制平面组件，包括主节点、控制器管理器、调度器等。它们还包括与正确实施安全策略和基于角色的访问控制（RBAC）、网络策略和秘密管理相关的控制和配置。未能实现这些安全实践和配置可能会影响节点和集群内的工作负载，并可能允许到它们所连接的企业环境中的其他系统的横向移动。

组织也经常使用CSP的管理Kubernetes服务，如谷歌的Kubernetes Engine（GKE）或亚马逊的Elastic Kubernetes（EKS）。使用这些管理的Kubernetes产品可以通过“rolling your own”Kubernetes来减轻一些管理开销（例如，拥有整个控制平面的活动和配置）。然而，使用托管的Kubernetes产品并不是没有它自己的问题。在CSP环境中仍然需要安全的配置，如身份和访问管理（IAM）、加密和密钥管理、网络和运行工作负载的节点的元数据服务，再加上信任和依赖云提供者的固有特性。

了解保护Kubernetes集群的最佳资源之一是Kubernetes文档页面 (https://kubernetes.io/docs/tasks/ administer-cluster/securing-a-cluster)。 CIS Kubernetes Benchmark， DISA Kubernetes STIG和NSA Kubernetes Security Guide也是优质资源，但用户还应该更广泛地确保，如果他们所使用的云平台的云本地安全最佳实践也会得到解决。

组织可以使用工具来确保Kubernetes的集群和部署，以及Kubernetes的安全最佳实践。一些例子包括来自Aqua Security（https://github.com/aquasecurity/kube-bench）的kube-bench，一个OSS工具，检查部署的Kubernetes配置是否与 CIS Kubernetes Benchmark一致。与Kubernetes本身类似，kube-bench使用了用YAML编写的测试，它可以随着基准测试的发展而进行修改。Aqua的另一个著名工具是kube-hunter，它寻找Kubernetes集群中的安全弱点。kube-hunter可以在机器或端点上运行，并使用IP进行远程扫描。此外，它可以在集群中的机器上运行，甚至可以作为集群中的pod运行。kube-hunter的一个独特方面是，它不仅支持审计/评估模式，还支持主动搜索模式，这可以改变集群的状态，利用被发现的漏洞。特别是由于后一种原因，kube-hunter文档特别指出，该工具不应该用于您不拥有的集群，其中包括使用受管理的Kubernetes产品。

想要了解与Kubernetes相关的各种攻击策略和技术的组织也可以利用资源，如微软对Kubernetes的Threat Matrix（www.microsoft.com/en-us/ security/blog/2020/04/02/attack-matrix-kubernetes），如图6.4所示。

就像MITRE ATT&CK一样，这个资源可以帮助组织了解其环境的攻击表面，以及恶意行为者所使用的各种策略。微软在他们的Threat Matrix中采取了类似的方法，但针对Kubernetes进行了定制，包括揭露Kubernetes的秘密和利用集群内部网络等活动，如图6.4所示。这些战术范围从初始访问阶段到影响，很像MITRE ATT&CK。

另一个类似的资源是由Weaveworks传播的MITRE ATT&CK Matrix for Kubernetes（www .weave.works/blog/mitre-attack-matrix-for-kubernetes），它使用类似于微软的Threat Matrix，还包括一个收集阶段，它专注于对手用于收集信息的技术，特别是从私人注册中心收集图像。尽管Weaveworks和微软的Threat Matrix之间存在差异和相似之处，但这两种资源都可以帮助组织理解以Kubernetes为中心的攻击的各个阶段，以及恶意行为者可能用来利用Kubernetes环境和协调的工作负载的相关策略。除了前面讨论过的资源，如 CIS Benchmarks，DoD STIGs，和Kubernetes Threat Matrices，组织还应该寻求采用新兴的框架，如Supply Chain Levels for Software Artifacts (SLSA)，我们会在下一章中讨论。

Kubernetes还支持各种多租赁模型，这些模型使用其集群和名称空间的构造，以促进云本地工作负载的效率、成本节约和可伸缩性（www.weave.works/blog/mitre-attack-matrix-forkubernetes）。对于部署工作负载到Kubernetes的组织来说，理解他们正在使用的租赁模型和潜在的安全和合规考虑事项是很重要的，特别是如果发生了安全事件或数据泄露，如果安全卫生和爆炸半径控制不良，可能会对租户产生级联影响。为了详细了解云原生环境中多租户的风险，云安全领导者Wiz发布了他们所谓的“PEACH Framework”，这是一个助记符，包括特权、加密、身份验证、连接硬化以及卫生等因素。该框架可以应用于Kubernetes的部署以及更广泛的多租户云环境（www.datocms-assets.com/75231/1671033753-peach_whitepaper_ver1-1.pdf）。

在Kubernetes生态系统中也支持SBOM。最值得注意的是，这包括OSS Kubernetes的bom实用程序，它利用为Kubernetes编写的代码为他们的项目生成SBOMs（https://github.com/kubernetes-sigs/bom）。Kubernetes bom工具支持从文件、图像和Docker图像中创建SBOMs，并将一组文件打包到单个文件中。您还可以从注册表中提取图像，并使用bom工具分析它们。它以 Software Package Data Exchange (SPDX) SBOM格式生成这些工件，并可以导出到一个in-toto的来源证明。In-toto是一个”超越最后一英里“或最终工件焦点的框架，旨在确保软件产品从启动到最终用户安装的完整性，使其透明地执行了什么步骤、由谁以及以什么顺序执行（https://in-toto.io/in-toto）。这些in-toto的来源证明都允许生成关于一个软件是如何生产的任何方面的可验证声明。可以利用Kubernetes的bom工具使用一个简单的”bom generate“命令创建SPDX清单。

第六章云和容器化

6.5 无服务器模型

在VMs和容器的计算抽象和演化的基础上，一些组织根据它们的用例进一步采取了他们的采用过程，并已经开始使用所谓的无服务器模型。更高级的说法是，无服务器模型允许开发团队构建和运行云本地的应用程序，而不需要管理底层服务器。云范式如IaaS，PaaS和SaaS，有一些相似之处PaaS和SaaS不需要管理基础设施和服务器，但主要区别在于应用了无服务器模型，而不是消耗一个SaaS提供商的应用程序，开发人员部署代码到云平台并且由云提供商后续托管和执行。云提供商处理底层基础设施，包括管理开销，如扩展和修补托管运行代码的服务器和实例的补丁。

最流行的一个例子之一是AWS的Lambda服务，它允许您运行代码，而不需要提供或管理服务器。该代码在一个高度可用的计算基础结构模型中运行，并处理实例的底层日志记录。其他云提供商，如谷歌和微软Azure也提供类似的无服务器功能。

在软件供应链安全方面，即使是在无服务器模式中，忧虑也仍然存在。在无服务器模型函数中运行的代码仍然可能包含OSS组件或易受攻击的代码，这可能会给在无服务器体系结构中运行的组织带来风险。此外，如前面讨论的，基础的functions-asa-service (FaaS)和云中的基础设施也由软件提供动力，每个软件都包含各种软件组件也可能包括OSS。

第六章云和容器化

6.6 SaaSBOM及API复杂度

为所包含的实体创建一个SBOM可能会很复杂，例如在本地交付的软件或容器映像。为具有云和SaaS等无数相互关系的动态且快速变化的环境创建SBOM可能是另一个级别的难度。

关于SaaS的SBOM的概念已经出现了讨论，它被称为SaaSBOM。云和SaaS引入了供应商管理的部署模型，而在这些模型中，消费者不拥有或控制底层的物理基础设施、托管环境、操作系统，甚至不是应用程序。应用程序仅仅是作为服务使用，即”as-a-Service“，而消费者对应用程序的配置和修改仅有有限的控制权。

一个更正式的定义是 NIST的800-145 Definition of Cloud Computing： ———————————————————————————————————————————————————— 提供给消费者的功能是使用运行在云基础设施上的提供商的应用程序。这些应用程序可以通过瘦客户机接口，如web浏览器（例如，基于web的电子邮件）从各种客户端设备或程序接口访问这些应用程序。消费者不管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储，甚至是单个应用程序功能，可能有有限的用户特定的应用程序配置设置除外。 ————————————————————————————————————————————————————

2021年初，SBOMs快速流行起来，该行业的许多从业者开始提出疑问，是什么推动SBOMs在高度动态和复杂的环境中工作，比如SaaS（用于应用程序的另一种方法，不像传统的软件交付和消费）。这本书的作者之一在2021年9月共同发表了一篇题为《The Case for a SaaS Bill of Materials》的文章（www.csoonline.com/article/3632149/the-casefor-a-saas-bill-of-material.html）。正如文章所指出的，在SaaS环境中定义什么是软件是具有挑战性的。现代SaaS通常建立在现有的IaaS和PaaS环境上，这些环境通常由其他CSPs拥有。底层的IaaS和PaaS通常被定义为“as-code”，并包括物理组件和虚拟组件，所有这些组件都包括它们自己的软件。这在SaaS环境中定义软件时造成了一种复杂的情况，因为涉及到无数的代码和软件组件，以及包含的各种关系和所有权实体。也就是说，许多业内人士都是在服务和数据流的背景下，围绕着SaaSBOMs作为焦点。CISA的SBOM Working Group包括一个Cloud Working Group，那里的许多专业人士都主张采取这个立场。Cloud Security Alliance（CSA）的出版物《SaaS Governance Best Practices for Cloud Customers》也引用了在SaaS中使用SBOMs，本书的其中一位作者领导了该出版物（https://cloudsecurityalliance.org/artifacts/saas-governance-best-practices-for-cloud-customers）。

为了进一步增加挑战，供应商经常使用工具来维护和操作底层云环境以及驻留在它们之上的SaaS。其中最值得注意的是 Ansible、Chef和Terraform，所有这些都有助于配置、部署和管理SaaS所依赖的云基础设施。当然，为了促进SaaS的交付，还涉及到其他的系统和软件，如CI/CD管道和IAM软件。

所有这些实体都是由软件组成的，并且经常动态和快速地变化，这使得定义它们确切的软件组件组成具有挑战性。建议的方法包括让SaaS供应商在他们的控制范围内尽可能确定整个技术组件，SaaS应用程序依赖这些组件能够向应用程序消费者提供SaaSBOM。尽管具有挑战性，但这种方法仍具有可能性，因为SaaS提供商至少应该能够访问并在其直接控制下理解应用程序交付中使用的组件。

正如我们所提到的，这并不能解决向SaaS应用程序消费者提供底层IaaS和PaaS提供商的软件和系统的详细SBOM的挑战，所有这些都是SaaS应用程序的关键依赖关系。

CycloneDX SaaSBOM

我们并不是唯一认识到SBOM采用性和成熟度是具有挑战性的人。作为行业领先的SBOM格式之一的CycloneDX，它是一个由 Open Worldwide Application Security Project (OWASP)管理的项目，已经提出了SaaSBOM模型，如图6.5所示。

CycloneDX SaaSBOM信息认识到，现代软件依赖于许多外部服务，甚至可以完全由服务组成。出于这个原因，他们致力于使CycloneDX能够代表各种服务类型，包括微服务、FaaS、systems of systems（SoS），当然还有SaaS。CycloneDX指出，SaaSBOMs可以作为infrastructure-as-code (IaC)的补充，IaC还提供了复杂系统的逻辑表示。在IaC的情况下，这包括云架构组件，如网络、计算和访问控制，所有这些都在一个as-code模型中定义。

CycloneDX指出，SaaSBOMs可以提供类似的逻辑表示，包括所有服务、服务依赖关系、相关的URL，甚至是服务和系统之间的数据方向流。

如前所述，SaaS由每个体系结构中的一组独立的应用程序和服务组成，用于向消费者交付应用程序。CycloneDX的SaaSBOM功能允许将服务和软件组件库存成单个BOM或独立的BOMs。CycloneDX建议将大型系统的SaaSBOMs与SBOM脱钩，因为云和SaaS涉及动态服务和部署场景。SaaSBOM可以表示为一个单一实体，其中有许多与之关联的SBOMs，SBOMs表示协同交付SaaS应用程序的相关服务。

因为每个独立的服务显然都有自己独特的漏洞，所以CycloneDX还支持来自其他系统和BOMs的BOM中的能力引用组件、服务和漏洞。这被称为BOM-Link（https://cyclonedx.org/capabilities/bomlink），它支持两种通用场景，即从另一个BOM引用一个BOM，并从一个BOM到另一个BOM引用一个特定的组件或服务。

CycloneDX还建议解耦Vulnerability Exploitability eXchange（VEX）和BOMs，因为BOM可能直到系统清单完成后才能更改，但VEX可以更频繁地更改，因为可能出现与现有和正在使用的软件组件相关的新漏洞。

工具和新兴讨论

从我们的讨论中可以明显看出，实现一个SaaSBOM，或者是一个普通的SBOM，因为它与云的复杂和动态的世界有关，并不是一件容易的事。它将不可避免地需要新的流程和工具来促进它的广泛采用，因为人类要跟上软件组件库存和相关漏洞的快速变化速度是不现实的。

因此，越来越多的人呼吁进一步讨论工具和功能的主题，以帮助解决针对SBOMs的云和SaaS环境中的这些差距。2022年7月，CISA就几个主题举行了一系列的会议，其中包括“Cloud & Online Applications”（www.federalregister .gov/documents/2022/06/01/2022-11733/public-listening-sessions-onadvancing-sbom-technology-processes-and-practices）。这些事件并不是为了寻求共识，但这些对话被用来促进关于SaaS和云应用程序的SBOMs主题的公开对话。

此外，Department of Homeland Security (DHS) Science & Technology (S&T) Directorate正在鼓励技术公司帮助开发自动化的SBOM工具。这是由于DHS S&T意识到大规模管理SBOMs的复杂性，包括SaaS。在他们的声明中，S&T承认，试图利用软件漏洞的攻击可能会导致安全和社会所依赖的关键系统的中断和损害。有关更多信息，请参见“DHS S&T Seeks Solutions to Software Vulnerabilities”：

https://dhs.gov/science-and-technology/news/2022/07/11/st-seeks-solutions-software-vulnerabilities

第六章云和容器化

6.7 在DevOps和DevSecOps中的应用

随着云和云原生架构的出现并继续流行，另一个趋势发生了：从传统的瀑布式软件开发到DevOps时代，或者最近的DevSecOps时代的转变。在不进行哲学辩论的情况下，DevOps可以概括为一套弥合软件开发和操作之间鸿沟的实践，或者在DevSecOps、软件开发、安全和IT操作的情况下。这场运动可以追溯到21世纪初，比如 Patrick Debois，Andrew Shafer，Gene Kim和Jez Humble，他们对生态系统做出了贡献。这与云计算的发展相吻合，组织也越来越多地使用云原生技术，通过敏捷和DevOps方法来促进业务结果。为了更好地理解DevOps，我们推荐诸如《DevOps Handbook (2nd edition, IT Revolution Press, 2021) 》或《 The Phoenix Project (5th Anniversary edition, IT Revolution Press, 2018)》。

本章其他章节中提到的许多技术，如cloud、SaaS、CI/CD、Kubernetes、containers和infrastructure as code，都在DevSecOps的成功旅程和实现中发挥了作用。在软件供应链安全和DevSecOps的背景下，一个健壮的工具生态系统已经出现。快速浏览一下CNCF场景（https:// landscape.cncf.io）就可以看到在CI/CD、自动化和配置、调度和编排等领域的蓬勃发展，所有这些都在现代DevSecOps环境中扮演着重要的角色。值得强调的是，尽管工具和技术促进了成功的DevOps转换，但DevOps不是工具或技术；它是一种方法和一套实践。已经采用了许多工具来支持DevOps，而一些常见的方法，如CI/CD，已经允许集成工具来应对软件供应链的挑战。

Syft和Grype等工具通常用于工具链中，以便创建SBOMs，并扫描这些SBOMs，以寻找与在部署到生产环境之前通过工具链的软件组件相关的漏洞。DevOps使用源代码管理（SCM）和Git存储库、CI/CD管道、声明性部署的GitOps风格等等。所有这些工具和方法都已经融合起来，以支持从源代码到运行时的迭代软件交付。它们还使团队和组织能够利用工具获得源代码、容器映像、不安全的IaC或Kubernetes配置中涉及的组件，最终形成了云本地部署架构，每个组件都有自己的软件供应链问题。

像NIST这样的组织已经开始请求DevSecOps的实践可以帮助识别、评估和减轻软件供应链的风险(www.nccoe.nist.gov/sites/default/files/2022-07/dev-sec-ops-projectdescription-draft.pdf)。如白皮书《Software Supply Chain and DevOps Security Practices》中所述，该观点旨在为安全的DevOps环境提供基于风险的建议。它还寻求与其他NIST的指导方针相一致，如SSDF和800-161/C-SCRM。本指南采用了一种非常以CI/CD管道为中心的方法，将软件供应链安全集成到DevSecOps环境中。

敏捷和DevOps的一个基本方面是远离传统的瀑布式软件开发，而是专注于更多的迭代和增量的软件交付。有些人可能会认为，敏捷的增量性质和DevOps可能会促进管理软件供应链的安全问题。随着组织逐步生产和发布软件，工具链可用于识别软件组件、关联漏洞、聚合这些指标，并授权组织做出与软件供应链问题相关的了解风险的决策。使用DevSecOps工具和在SDLC中强调左移安全或更早的安全性，可以在引入运行时环境之前识别出易受攻击的软件组件。许多人声称，从成本的角度来看，这种方法更有效，但它也降低了利用的可能性，因为如果该漏洞及早被捕获并补救，就不能在生产过程中被恶意行为者利用。

DevSecOps不仅提供了捕获SDLC早期脆弱软件组件的机会，并提供了更好的透明度，而且高能力的DevSecOps团队能够更好地应对软件供应链问题和事件。研究支持这些说法，最著名的是由谷歌运营的DevOps Research and Assessment (DORA) 团队。在《2022 Accelerate State of DevOps Report》中，DORA团队发现，部署前安全扫描等实践在发现脆弱的依赖关系方面是有效的，这导致生产应用程序中的漏洞更少（https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf）。

由于DORA团队多年来进行了他们的研究，他们创建了特定的指标，现在被认为是DORA指标。他们用于衡量软件开发团队绩效的四个关键指标如下：

部署频率：一个组织成功地发布到生产环境中的频率
变更提前期：一个承诺投入生产所需的时间
变更失败率：导致生产过程中失败的部署的百分比
服务恢复时间：一个组织从生产失败中恢复过来需要多长时间，这也通常被称为平均恢复时间（MTTR）

这四个指标支持两个关键主题：部署频率的速度和更改的提前时间、故障率的稳定性和恢复服务的时间。这些指标有助于衡量团队以业务/任务需求的速度发布软件的能力，同时也能确保这些发布不会影响系统的弹性。一开始认为快速移动的团队是稳定的似乎是违反直觉的，但正如行业专家指出的那样，在不影响稳定性的情况下，正是软件开发和交付的实践帮助这些团队能够做到这一点。那些在生产中不频繁发布软件的队伍往往而且需要更长的时间完成产品，并且经常难以应对变化以及无法从故障中恢复系统。在这种情况下，高表现力的DevOps团队可以被认为是已经将上述经验内化成了肌肉记忆。

第六章云和容器化

6.8 小结

总之在《2022年DevOps状态报告》中、DORA团队的软件工件供应链水平（SLSA）和NIST的SSDF确定了与保护软件供应链相关的流程和实践。我们探讨了DevOps和DevSecOps为何不仅仅是工具——它们是文化实践和方法的集合。DevSecOps方法使团队能够缓解软件供应链问题，最近的研究已经开始支持这一观点。

在本章中，我们讨论了云原生范式中与软件透明度相关的一些复杂性和细微差别。这包括与云相关的基本服务模型、云原生的4C，以及SaaS环境中的SBOM。我们还讨论了使用成熟DevSecOps实践的高绩效团队如何实现更安全的软件供应链结果。

第七章现有和新兴商业指南

随着围绕软件供应链安全的对话日趋成熟，许多组织已开始为行业提供强大的指导、框架和资源，以加强其针对此类攻击的安全态势。在接下来的章节中，我们将讨论其中一些资源以及提供这些资源的组织，其中包括云原生计算基金会（CNCF）、国家安全局（NSA）和美国国家标准与技术研究院（NIST）等

第七章现有和新兴商业指南

7.1 软件制品的供应链等级

随着软件供应链攻击的增加，很明显，需要一个全面的端到端框架来定义软件供应链袭击和缓解方法。2021年6月，谷歌开源安全团队推出了软件工件（SLSA）工作该工作的目标是确保软件工件的完整性在整个软件供应链生命周期中得到维护。
SLSA包括四个级别，每个级别都提供更高级别的完整性保证，但实施者的成熟度和严格性水平相一致。组织根据其特定的行业和监管或安全要求，有各种需求来指导其追求的SLSA级别。与其他安全工作一样，SLSA是一个需要时间和精力才能实现的过程。图7.1显示了四个级别，并对每个级别进行了描述。
SLSA提供了一个框架，涵盖了从原始开发者到下游消费者和用户的整个软件路径，包括软件与源代码存储库、构建系统、包存储库的交互，以及其间的所有步骤。图7.2显示了软件供应链，恶意行为者可能会损害消费者在生产环境中使用的下游软件工件的完整性。
如果恶意者可以在源代码存储库中提交错误代码，则可能会在整个构建过程中执行的下游活动中引入漏洞。引入错误代码并不是与源代码管理相关的唯一问题，因为源代码管理（SCM）系统本身可能会受到攻击和破坏，从而影响存储在其中的代码以及它所促进的下游构建和分发活动。
这种威胁既适用于自托管SCM，也适用于云提供的SCM。在自托管场景中，自托管SCM的组织从基础设施和托管的角度负责其安全性，而在基于云的场景中，如果作为软件即服务（SaaS）交付，则云服务提供商（CSP）拥有底层基础设施和平台的责任，在一定程度上还负起应用程序本身的责任。
研究人员François Proulx在其文章《SLSA Dip-At The Source of The Problem！》中描述了与SCM折衷相关的攻击树(https://medium.com/boostsecurity/slsa-dip-source-of-the-problema1dac46a976)。图7.3显示了恶意行为者的示例攻击向量可以用于危害SCM存储库，如GitHub。
持续潜在的软件供应链威胁模型，恶意行为者可能使用批准的构建过程和基础设施，但引入的代码与SCM本应使用的代码不匹配。这是一个代码来源信息对于确保所使用的代码来自预期来源并且没有受到篡改或完整性攻击至关重要的例子。SLSA将出处定义为“关于软件工件的可验证信息，描述在何处、何时以及如何生产。”SLSA级别越高，对出处的要求就越严格。
构建平台是软件供应链的另一个关键部分，是攻击者的另一个主要目标。这个攻击向量被用于Solar-Winds事件，导致构建系统和恶意软件被插入SolarWinds Orion IT管理产品的软件构建中。随后，SolarWinds的下游客户下载并安装了它，其中包括18000多个组织，其中许多是政府实体，这一事实无疑促成了我们在我们在第一章“背景软件供应链威胁。”提到的网络安全行政命令。
另一种潜在的攻击途径是，恶意行为者可以注入良性依赖，随后可以对其进行修改以产生恶意行为。一个真实的例子是事件流npm包，其中有人自愿承担项目的维护职责，但最终添加了一个名为flatmap流的恶意依赖项。这尤其有影响力，因为事件流包每周下载量超过190万次！
恶意行为者还利用机会上传会让下游消费者下载并受到影响的恶意软件包。最引人注目的例子是Codecov事件，该事件涉及恶意行为者使用泄露的凭据将恶意软件包上传到Codecov的云存储中。从那时起，Codecov漏洞也影响了数百个客户网络，因为恶意行为者使用Codecov攻击下游客户网络。如果消费者一直在使用出处验证方法，他们可能会发现下载的工件与源代码存储库中预期的不一样。
LSA还强调软件证明，他们将其定义为“关于软件工件或软件工件集合的经过验证的声明（元数据）”(https://slsa.dev/attestation-model)。
SLSA列出了一个表示软件验证的通用模型，如图7.4所示。
2023年初，SLSA推出了他们的候选版本（RC）规范，这是自2021年6月SLSA首次发布以来的首次重大更新。重大变化包括将SLSA划分为多个SLSA轨道，以衡量软件供应链的特定方面。RC规范还简化和澄清了原始规范的各个方面，并为原产地验证提供了新的指导。也就是说，截至本文撰写之时，每个拟议曲目的具体内容尚未完全定义，将在SLSA的未来版本中解决。如果您有兴趣了解有关1.0候选版本的更多信息，请访问（https://slsa.dev/blog/2023/02/slsa-v1-rc）

第七章现有和新兴商业指南

7.2 用Google Graph理解制品组合

在SLSA框架的一个巧妙命名的后续行动中，谷歌与花旗和普渡大学等合作伙伴还宣布了一项名为“理解工件组成图”（GUAC）的开源软件（OSS）工作，如图7.5所示。根据他们的声明，“GUAC解决了整个生态系统中生成软件构建、安全性和依赖性元数据的快速发展所带来的需求”(https://security.googleblog.com/2022/10/announcing-guac-great-pairing-with-slsa.html).
该公告承认，OpenSSF等组织领导的大量开放源码软件工作，以及软件材料清单（SBOM）格式的软件供应链工作，为保护数字供应链的对话做出了贡献。也就是说，许多信息需要整理和理解。从SBOM格式（如软件包数据交换（SPDX）和CycloneDX），到SLSA等框架和我们讨论过的各种漏洞数据库（如国家漏洞数据库（NVD）、全球安全数据库（GSD）和开源漏洞（OSV））的证明，组织发现自己正试图理解所有数据。
虽然所有信息都是有用的，但GUAC的工作指出，需要将所有信息结合起来，综合起来，全面了解软件供应链风险。GUAC将各种元数据源整合到图形数据库和关系中，这在审计和风险管理以及开发人员授权等用例中都有好处。
根据谷歌的公告，GUAC专注于四个关键领域：

收集
摄入
整理
查询

集合包括OSV和GSD等来源，甚至包括内部存储库。Ingestion允许接收上游数据源，如工件、项目和资源。排序从各种来源获取原始元数据，并将其组装成一个标准化的图，以显示项目/开发人员、漏洞和软件版本等实体之间的关系。最后，查询功能支持对组装的图和相关元数据进行搜索，查询SBOM、项目记分卡、漏洞等工件。见图7.6。
如图7.6所示，收集、摄入、整理和查询支持各种角色和用例，如治理、风险和合规（GRC）和政策专业人员、首席信息安全官（CISO），甚至开发人员。正如公告所提到的，了解特定OSS漏洞的影响需要在企业和更广泛的生态系统中聚合和分析大量数据。GUAC旨在使所有这些信息都可操作，重点是让用户能够回答以下三个基本问题：

我们如何防止供应链妥协？
是否有适当的保障措施？
如果事件发生，我们的组织是否受到影响？

这三个问题有三个主题领域，如图7.7所示：

积极主动的
预防性的
被动的

积极主动主题旨在了解软件供应链中最关键的组件以及您的主要弱点和风险敞口。预防措施主题重点是确保部署的应用程序与组织的策略和要求保持一致。被动主题使您的组织能够了解漏洞出现时受到的影响。

第七章现有和新兴商业指南

7.3 CIS软件供应链安全指南

随着行业不断成熟的软件供应链实践，我们看到了NIST、开源安全基金会（OpenSSF）和互联网安全中心（CIS）等组织的指导。在本节中，我们将讨论最近发布的CIS软件供应链安全指南（https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-SoftwareSupply-Chain-Security-Guide-v1.0.pdf）。本指南是与Aqua Security合作创建的，Aqua Security创建了一个名为chain bench的开源工具，以帮助您审核软件供应链堆栈是否符合CIS指南（https://github.com/aquasecurity/chain-bench）。

《软件供应链安全指南》的CIS基准旨在提供一套与平台无关的高级最佳实践，随后可用于为GitHub、GitLab等平台构建特定于平台的指南。

该指南由五个核心领域组成：

源代码
构建管道
依赖项
工件
部署

它还涵盖了软件供应链的各个阶段，从源代码到部署，并涉及整个过程中存在的各种潜在威胁载体。如图 7.8 所示，它让人想起另一个新兴框架 SLSA，以及现有的开放全球应用安全项目 (OWASP) 软件组件验证标准 (SCVS) 框架。

总体而言，该指南涵盖了所讨论的五个类别中的 100 多项建议。让我们逐一介绍这五个类别，重点介绍该领域的重要性以及其中包含的一些值得注意的建议。

源代码

如前所述，该指南遵循软件供应链生命周期，因此源代码不可避免地位于列表的顶部，因为它是该生命周期的第一阶段。由指南得出源代码是其余流程/阶段的真实来源。

在处理保护源代码时，您将寻求保护代码以及源代码管理系统，恶意行为者可能会利用这些系统来破坏源代码本身。指南表示保护源代码涉及开发人员、代码中的敏感数据以及源代码管理平台本身等方方面面。

源代码类别本身分为以下几个小节：

■ 代码变更
■ 存储库管理
■ 贡献访问
■ 第三方
■ 代码风险

这些小节包括关键建议，所有这些建议都与源代码安全有关。在“代码变更”小节中，一些值得注意的示例包括确保在版本控制中跟踪代码更改、扫描代码合并以查找风险以及确保代码更改需要两个经过严格身份验证的用户的批准。这些控制措施试图确保跟踪更改、在允许代码更改之前降低风险，以及由具有适当身份验证措施的用户进行同行/双人代码审查。

在“存储库管理”小节中，建议使用安全控制措施，例如确保将 SECURITY.md 文件发布在公共存储库中并清理不活动的存储库。这些措施有助于保护存储库的完整性、指导安全和/或漏洞反馈，并防止存储库蔓延和缺乏治理。

控制贡献访问是用于验证代码完整性是否得到解决的另一项基本措施。在贡献访问子部分中，建议的控制措施包括要求对代码贡献进行多因素身份验证 (MFA)、实施对存储库的最低许可访问控制以及将 Git 访问限制在特定的允许列表 IP 地址。采取这些措施可提高代码贡献流程和源代码的安全性，仅向获得授权、经过适当身份验证且来自获准 IP 地址的用户授予访问权限。

代码存储库中的第三方应用程序对组织构成风险。包括与第三方工具的集成，以实现增强的功能或能力以及开发人员的工作效率。采取措施，例如确保管理员批准已安装的应用程序、删除过时的应用程序以及实施最低许可控制，可以大有裨益。第三方子部分中的这些基本控制措施可最大限度地减少组织的攻击面，并限制第三方应用程序受到攻击时的爆炸半径。

降低代码风险是组织在处理其源代码安全时必须执行的一项关键活动。在代码风险小节中，建议采用风险控制措施，例如扫描代码中的敏感数据（如机密和机密蔓延），特别是在云原生 DevOps 环境中。还包括需要通过静态应用程序安全测试 (SAST) 扫描代码中的漏洞，以及使用软件组合分析 (SCA) 和新兴的 SBOM 工具和实践来查找 OSS 组件中的漏洞。

构建管道

根据 CIS 指南的定义，构建管道用于获取源代码的原始文件并运行一系列任务以获得最终的工件作为输出。这相当于存储并最终部署的软件/应用程序的最新版本。构建管道部分包括构建环境、构建工作者、管道说明和管道完整性。该指南强调，许多建议与自托管构建平台有关，而不是即服务 SaaS 产品。也就是说，即服务产品（例如基于 SaaS 的产品）有其独特的风险，我们在第 6 章“云和容器化”中提到过。

对于构建环境，该指南建议采取一些控制措施，例如将管道专用于单个存储库、使用不可变的管道基础设施和配置，以及确保记录构建环境的活动。这些控制措施可确保组织避免诸如漂移和配置偏差、出现问题时缺乏可见性/日志记录等问题，并在创建构建环境期间促进自动化，从而最大限度地降低手动活动的风险。这些控制有助于避免诸如人为错误之类的问题，这些问题可能导致数据泄露和配置错误，而恶意行为者可以利用这些错误。

构建工作者，称为运行者，是管道操作基础设施的核心组件，也是那些试图造成破坏的人的目标。工作者可以签出代码、执行测试，甚至将代码推送到注册表，所有这些都可以用于邪恶的目的。这里的安全控制包括一次性构建工作者、构建工作者之间的职责分离以及运行时安全性的实施。这些活动试图确保监视运行时事件是否存在恶意行为模式，将构建工作者的潜在攻击限制在其分配的职责而不是更广泛的环境中，并最大限度地降低数据被盗的风险。

管道指令用于将源代码转换为最终工件。当被篡改时，指令可用于执行恶意活动。安全控制包括将构建步骤定义为代码、明确定义输入和输出以及自动扫描管道以查找配置错误。这些控制确保构建步骤不可变且可重复，并具有预期的输入/输出，并且扫描可以识别错误配置以避免后门或妥协。

维护管道完整性是一项关键控制，包括验证管道、必要的依赖项及其生成的工件是否符合要求且未经更改。此领域的关键控制包括尝试确保工件在发布时签名、依赖项在使用前经过验证以及管道生成可重现的工件。这些控制可验证工件是否由受信任的实体签名、依赖项在使用前经过审查以及管道是否持续生成工件以确保未发生篡改。该指南还建议不仅为软件或构建过程的每个组件生成 SBOM，还建议确保对 SBOM 进行签名以进一步证明其有效性。这些建议与 NIST 和 OpenSSF 的指导一致，并利用 Sigstore 等技术，我们在第 4 章“软件物料清单的兴起”中关于 SBOM 和软件签名的讨论中介绍了这些技术。

依赖项

CIS 指南认识到依赖关系在软件供应链中发挥的基本作用。它强调依赖关系通常来自第三方来源（例如 Log4j），一旦被利用，可能会造成巨大损失。事实上，Sonatype 和 EndorLabs 等研究表明，七分之六的漏洞来自传递依赖关系。

第三方软件包需要适当的管理和使用，包括努力建立信任并适当管理其使用。第三方软件包不仅会影响您的软件，还会影响您软件的下游消费者，Log4j 及其相关的受影响软件供应商的大量通知就是明证。此处的安全控制包括验证第三方工件和开源库、要求第三方供应商提供 SBOM 以及要求/验证构建过程的签名元数据。这些步骤有助于降低使用恶意或高风险第三方组件的风险，从而了解供应商/供应商的软件内部情况，并确保工件在构建过程中没有受到损害。

该指南要求验证软件包以了解如何以及是否使用它们，它包括政策和技术控制的组合，例如建立组织范围内的依赖项使用指南、扫描软件包中的已知漏洞以及保持对所有权变化的认识。这些控制有助于管理软件包的使用，同时确保现有软件包不易受攻击，并跟踪可能导致新所有者进行恶意活动的所有权影响。

工件

根据 CIS 指南的定义，工件是存储在软件包注册表中的软件的打包版本。该指南强调需要在整个生命周期内保护工件，从创建到部署到环境中。

进行验证控制是必要的，例如确保工件由管道签名，然后在分发之前加密，以及控制谁可以执行解密。此类控制可确保工件具有完整性和机密性，仅限于有权查看工件解密副本的人员。

必须实施工件的基本访问控制也是必须的。此领域通常涉及存储工件的注册表，确保在交付给客户之前，工件没有通过各种攻击媒介被篡改。控制包括控制可以上传新工件的允许用户数量，并为用户访问实施 MFA。这追求将用户管理从软件包注册表分离到外部身份验证机制/服务器的目标。

软件包注册表是攻击面的另一个组成部分，也是组织工件的存储位置。虽然目标是保护工件，但如果不保护存储它们的注册表，您就无法做到这一点。控制措施包括审核软件包注册表的配置更改以及以加密方式验证软件包注册表中的工件。

来源可追溯性或代码出处是另一种越来越受关注的最佳实践。它是确保组织及其客户都了解工件的来源以及工件来自可信来源的过程。必须通过 SBOM 和元数据等方法确保工件包含有关其来源的信息。组织还应使用代理注册表来代理来自公共注册表的内部软件包请求。此建议与 NIST 800-161r1 附录 F（https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf）相一致，该附录要求建立已知验证组件的内部注册表。NIST 800-161 附录 F 有自己的网页（www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains）。

部署

最后，我们进入开发阶段——软件供应链的最后阶段，在此阶段，工件被部署到运行时环境。此阶段的控制包括部署配置和部署环境。

对于部署配置，建议您将部署配置文件与源代码分开，跟踪部署配置更改，并使用扫描器来保护基础设施即代码 (IaC) 清单。部署配置中的错误配置或漏洞会使部署环境变得脆弱。

部署环境建议包括使部署自动化和可重复，并限制对需要它的人的访问。这些建议确保部署不可变，避免配置偏差，并限制访问以最大限度地减少威胁。

虽然软件供应链安全仍然是一个不断发展的领域，但 CIS 指南以及本书中提到的其他组织的指导，成为历史上网络安全阴暗领域的一盏明灯。软件供应链是一个极其复杂和脆弱的生态系统，由于它影响到无数的组织、消费者、供应商和行业，它存在系统性风险。请务必留意后续特定于平台的 CIS 基准，这些基准建立在《CIS 软件供应链指南》中引用的控制和建议的基础上.

第七章现有和新兴商业指南

7.4 CNCF的软件供应链最佳实践

在有关软件供应链安全的讨论中经常引用的另一个行业指导来源是 CNCF 的软件供应链最佳实践白皮书 https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)。该白皮书于 2021 年发布，涵盖了保护源代码、物料、管道、工件和部署。它引用了 SolarWinds 事件作为引起人们对软件供应链关注的关键问题，并围绕四个基本原则构建：

■ 供应链中的每一步都必须值得信赖。
■ 供应链中的每一步都必须使用自动化。
■ 必须正确定义和保护构建环境。
■ 供应链环境中的所有实体都必须进行相互身份验证。

白皮书还认识到，不同组织和行业存在各种保证角色和风险偏好。并非所有组织都有相同的保证要求；国防部 (DoD) 运营的武器系统的安全要求比不处理敏感数据的简单 Web 应用程序要严格得多。组织可以根据其特定的风险承受能力和保障要求使用白皮书中的建议来降低软件供应链风险。

白皮书采用了低、中、高三个保证级别。低保证环境是指在开发过程中投入很少时间来保护产品的完整性（或安全性）的环境。中等保证包括合理的保证要求，与大多数部署相一致，并作为本文的基准。最后，高保证环境要求产品不被篡改、抵制未经授权的更改，并采用高保真证明和验证流程。

如图 7.9 所示，白皮书将其与与原材料、产品和制造相关的传统供应链进行了类比。它指出，就像技术如何从精益制造中采用敏捷和 DevOps 实践一样，软件供应链可以利用制造业的洞察力

尽管如此，尽管与制造业供应链有相似之处，白皮书也强调了一些关键差异。首先，现实情况是软件供应链是无形的，包括虚拟和数字组件，这些组件不像物理领域的组件那样可见。其他关键差异包括软件供应链确实并将继续以更快的速度发展，因为它们以技术为中心。最后是重用的存在和数字供应链的复杂性。许多人经常使用短语“一路向下的乌龟”，这意味着在大多数情况下它是一个无限的回归，具有多个级别的直接和传递依赖关系。许多产品和供应链是其他产品或供应链的一部分或组件。这种现实可能会带来一些挑战，特别是因为数据显示大多数漏洞普遍存在于传递依赖关系而非直接依赖关系中，但大多数组织并不了解其传递依赖关系的全部范围。

与物理供应链非常相似，数字和软件驱动供应链中的每一步都有可能引入风险——因此，出现了诸如 SLSA 之类的框架，以及相关的最佳实践，以减轻软件供应链生命周期每一步的风险。与更广泛的网络安全和技术非常相似，软件供应链的强度取决于其最薄弱的环节，因此供应链某一环节的漏洞可能会对供应链的其余部分以及所有下游消费者和利益相关者产生连锁影响，正如我们在供应商和 OSS 组件中多次看到的那样。

CNCF 的指南强调了一些关键主题，例如验证、自动化、受控环境中的授权和安全身份验证。这些主题对于确保整个软件供应链生命周期的强大保证至关重要，并贯穿整个文档的各种建议和推荐控制。

验证是确保从一个阶段到下一个阶段的完整性的关键，而自动化有助于促进可重复和不可变的流程。对机器和人类实体的权限进行适当调整可确保每个实体和阶段只能进行明确定义和要求的活动。虽然这是一种长期存在的安全最佳实践，但这种最不宽松的方法也在行业推动零信任的过程中得到强调，因此在这方面有相似之处。

最后，安全身份验证可确保供应链中实体之间的相互身份验证，使用与环境和所涉及组织的保证级别相一致的身份验证方法。该指南涵盖了供应链的五个阶段——保护源代码、保护材料、保护构建管道、保护工件和保护部署——我们将在以下章节中讨论每个阶段

确保源代码安全

软件供应链起源于源代码。创建和保护这些源代码是一项基础活动，有可能影响整个下游供应链的完整性。CNCF 的指南指出，身份访问管理（IAM）是任何平台或供应商在这方面最关键的攻击媒介，它适用于有权访问源代码存储库的人类和机器实体。Verizon 的 2022 年数据泄露调查报告（DBIR; www.verizon.com/business/resources/reports/dbir）等报告证实了这一说法，该报告显示，超过 60% 的数据泄露涉及泄露的凭据。

源代码安全建议涵盖了前面提到的五个主题。这些包括验证活动，例如实施签名提交以确保源提交或修改的完整性和不可否认性。有更传统的方法，例如 GNI 隐私保护 (GPG) 密钥或安全/多用途互联网邮件扩展 (S/MIME) 证书，但也有创新的新兴解决方案，例如 GitSign (https://github.com/sigstore/gitsign)，它使用 Sigstore 来促进“无密钥”签名。由于与传统签名和密钥管理活动相关的开销减少，这是一种越来越有吸引力的签名工件和元数据的方法。

自动化还可用于保护源代码和相关存储库。其中一个领域是暴露秘密的问题。在这种情况下，秘密是诸如凭证文件、安全 Shell (SSH) 密钥、访问令牌和应用程序编程接口 (API) 密钥之类的项目。机密蔓延，即敏感凭证的传播和分发，是一个严重的问题，尤其是在包含声明式方法和在各种清单和配置文件中提交机密的机会的云原生 DevSecOps 环境中。

GitGuardian 是一家专注于机密管理的公司，它制作了高度翔实的报告，例如《2022 年机密蔓延状况报告》（www.gitguardian.com/state-of-secrets-sprawl-report-2022），该报告深入探讨了这一问题。一些令人震惊的指标包括 2021 年每位应用程序安全工程师检测到的机密事件超过 3,000 次，2021 年公开暴露的机密超过 600 万个，是 2020 年的两倍。本书的一位作者撰写了一篇文章，介绍了机密管理的现状以及不良做法可能产生的影响（www.csoonline.com/article/3655688/keeping-secrets-in-a-devsecops-cloud-native-world.html）。这些暴露的机密可能会授予恶意行为者的访问权限并在整个环境中造成严重破坏。 GitGuardian 发布的《2023 年机密蔓延状况》报告发现，在公共 GitHub 存储库中暴露了超过 1000 万个新机密，而问题似乎也没有改善。2022 年，机密也以某种形式或方式卷入了安全事件，影响了业内一些最著名的组织，例如 Uber、NVIDIA、Microsoft 和 Slack (www.gitguardian.com/state-of-secrets-sprawl-report-2023)。

为源代码存储库实施受控环境提供了一个机会，可以通过相应的控制来减轻多种风险，包括建立和遵守管理代码贡献的贡献政策。根据先前关于适当调整权限的建议，也有机会协调角色并将权限与组织内的职能职责相关联。组织可以采取更进一步的措施通过使用基于上下文的访问控制机制，检查一天中的时间和设备姿势等因素，以提供动态的、基于时间的访问，这在零信任环境中很常见。网络安全的许多领域经常提出的另一项基本建议是强制职责分离，以便请求的作者不能同时是其批准者。

身份验证是一种帮助授予实体（无论是人还是机器）对源代码存储库的初始访问权限的活动。这里的一些建议包括强制执行 MFA 以访问存储库和使用 SSH 密钥来促进开发人员访问等活动。这些密钥应该有一个相关的轮换策略，以确保如果密钥被泄露，它们在恶意访问和活动方面产生负面影响的能力是有限的。对于机器或服务实体，组织应该采用短期和短暂凭证。这些凭证可以允许机器和服务（例如管道代理）访问，但也可以减轻凭证泄露的影响，因为密钥不断被生成、使用和丢弃。如前所述，被盗用的凭证是恶意行为者最常见的攻击媒介之一，因此使用短期凭证可以减轻这种影响。

确保物料安全

在软件供应链的背景下，CNCF 的指南将材料作为依赖关系和库进行讨论，无论它们是直接的还是可传递的。这一部分与本书的总体概念密切相关，该概念侧重于软件供应链的透明度和安全性。该指南提到，某些高可靠性环境可能需要仅使用受信任的存储库，同时阻止对其他存储库的访问。值得一提的是，NIST 800-161r1 指南建议建立已知可信组件的内部存储库以供开发使用，我们将在第 8 章“现有和新兴政府指南”中讨论，该指南涵盖了 NIST 的 800-161r1 指南。

CNCF 指南强调，当涉及到他们正在使用的第二方和第三方软件时，组织应该使用风险管理方法。虽然组织和开源项目都习惯于发布易受攻击代码的常见漏洞和暴露（CVE），但该指南指出，CVE 也是一个尾随指标，这意味着一旦发现并发布漏洞，它们就会通知消费者;他们使用的代码已经很脆弱。对于组织来说，利用其他指标也很重要，这些指标可以告知使用者与与运营运行状况等指标相关的项目和代码相关的风险。其中一个项目是OpenSSF的记分卡项目，我们将在即将到来的 “OpenSSF记分卡”一节中讨论。

组织使用来自外部实体的软件组件，因此验证这些第三方库和组件至关重要，包括使用校验和和验证签名等方法。组织还可以（并且应该）使用 SCA 和 SBOM 生成等方法来确定他们正在使用的软件中是否存在任何易受攻击的开源组件。一旦组织使用了 SCA 和 SBOM，他们就可以开始跟踪其使用的 OSS 组件与其所属系统之间的依赖关系，作为其更广泛的软件资产清单工作的一部分。组织可以开始生成供应链清单，该清单不仅包括 OSS 组件，还包括整个组织使用的软件供应商、供应商和来源。

该指南警告的另一个风险是，恶意代码可能包含在编译软件中，例如二进制文件或压缩包，这些软件是编译的，而不是源代码或文本格式。因此，该指南建议组织从源代码构建其库，而不是使用已编译的软件，因为这些软件可能已被恶意行为者破坏。与创建软件供应链清单的建议非常相似，该指南建议组织拥有受信任的包管理器和存储库的清单，并控制其访问权限，以限制从未经批准的来源引入代码。
组织还应利用自动化手段来确保从外部获取的材料的安全性。这方面包括扫描软件以发现漏洞、许可影响，并识别与所引入软件相关的直接和传递依赖项。

保护构建管道

CNCF的SSCP指南将制造业装配线与软件供应链生态系统中的构建流水线进行了类比，甚至将构建流水线称为“软件工厂的核心”。这条流水线汇集了前文讨论过的许多材料，来自诸如源代码控制仓库和第三方提供者等来源。这些构建流水线由多个组件组成，包括构建步骤、工作器、工具和流水线编排器，我们稍后在“安全软件工厂参考架构”章节也将对这些组件进行讨论。
确保构建流水线的安全性需要加固构建步骤及其相关输出，以确保既不会危害构建流水线本身，也不会危害其过程。恶意行为者知道，如果他们能够入侵构建流水线，他们可以向下游消费者分发恶意软件，而这些消费者可能并不知道上游构建过程已经被入侵。

CNCF 建议采取一些关键步骤来保护构建管道： ■ 使用单个存储库来存储所有构建组件
■ 记录步骤和相关输入/输出
■ 使用签名工件和元数据等方法来确保构建过程的完整性

组织还应对其构建流水线和基础设施进行威胁建模和自动化安全测试，就像对其他生产系统和环境进行的操作一样。简而言之，从安全的角度来看，您的构建系统应该像生产系统一样对待，因为它们的输出最终会进入运行时环境。如果这些输出受到威胁，生产运行时环境也将受到威胁。
虽然CNCF的出版物没有具体提到，但关于这个主题的一个优秀的指南来源是新成立的OWASP Top 10 CI/CD安全风险项目。正如该项目所言，CI/CD环境、流程和系统是现代软件交付的核心。该项目指出，滥用CI/CD环境已导致了几起显著的安全事件，如SolarWinds、Codecov等，影响了成千上万的下游消费者和组织（链接：https://owasp.org/www-project-top-10-ci-cd-security-risks）。
该指南指出了现代构建环境的核心组件，例如流水线编排器、构建工作器以及从安全的工件存储库获取（见图7.10）。这些实体协作执行诸如构建和链接依赖项、构建应用程序、测试并发布到安全存储库等步骤，最终部署应用程序。如果这些过程和实体受到威胁，将对部署环境产生下游影响。
验证是指南强调的另一个关键活动。这个领域包括使用加密来验证策略的遵从性、在使用前验证环境和依赖关系，以及验证构建工作器的运行时安全性，如图7.10所示。指南提到，产生端到端的加密保证是其中一种选项。
另一个重点是在高保证和高风险环境中使用可重现构建。简而言之，可重现构建能够使用特定输入生成可以进行加密证明的输出。这意味着可以识别和应对恶意或无意的修改。这种实践在其他指南来源中也有体现，如SLSA所指出的，但众所周知，这并非一项简单的工作，可能在时间和资源上成本高昂。因此，这是一种为高保证环境保留的实践。

其他值得注意的实践和功能包括：

■ 自动创建构建环境
■ 在不同基础设施环境中分发构建
■ 使用自动化来标准化跨团队和项目的管道
■ 配置安全的编排环境以托管软件工厂（请参阅即将到来的部分“CNCF 的安全软件工厂参考架构”

保护工件

在完成构建阶段后，会生成软件和制品，以及与它们相关联的元数据。为了确保这些制品的完整性，可以采用多种方法进行保护，例如签名。CNCF建议在制品的每个生命周期阶段都进行签名，以确保其完整性。签名是一种通过使用加密密钥对制品进行数字签名的方法，以证明制品在特定时间点由特定实体生成，并且在传输或存储过程中没有被篡改。通过在每个重要阶段对制品进行签名，可以确保制品在整个生命周期内都可以追溯到其源头，并防止未经授权的更改或操纵。
CNCF的指南建议组织在构建过程中的每个步骤都进行签名，并验证生成的这些签名。他们引用了更新框架（The Update Framework，TUF）、SPIFFE和SPIRE作为可以用来支持整个过程所需证明的项目示例。SPIFFE和SPIRE旨在为现代和异构基础设施提供统一的身份控制平面。SPIFFE和SPIRE的支持包括保护微服务通信、实现安全认证以及用于零信任安全模型的跨服务认证（链接：https://spiffe.io）。通过使用TUF和Notary来自动化管理制品的签名、存储相关元数据和输出，组织可以采纳自动化方法。
组织还应采取措施限制特定方能够签名的制品，并将这些能力与时间绑定，定期进行审查。时间绑定涉及在凭证和访问有效性上设置时间限制。制品生成后，在分发之前，组织应对其进行加密，并以只有授权平台和消费者能够解密的格式进行加密。遵循这些步骤确保了制品在其各个生命周期阶段内的完整性，并确保最终消费者或接收方（无论是个人还是非个人实体）拥有适当范围的权限和访问控制。这些措施有助于防止未经授权的篡改或访问，从而保护制品的安全性和可信度。

保护部署过程

在CNCF SSCP白皮书的结尾部分是“Securing Deployments”（保护部署）部分。CNCF再次强调了在这一活动中TUF的重要性，并且有必要能够检测和防止恶意活动。
验证被提出作为一个关键活动，一旦软件制品被部署，客户端接收到软件制品后可以验证其完整性，还可以验证相关的元数据。这意味着他们可以验证一个软件构建物清单（SBOM）的签名（如果有的话），并验证其是否由授权方签名。

第七章现有和新兴商业指南

7.5 CNCF的安全软件工厂参考架构

对许多人来说，将软件生产与工厂这一术语联系起来可能看起来有些奇怪。大多数人仍将工厂与收集、处理和制造物理材料如钢铁、汽车或消费电子产品联系在一起。然而，讽刺的是，现代大多数工厂环境的运作依赖软件，而软件的生产方式越来越具有与工厂类似之处。术语“软件工厂”通常指为了以高效、可重复和安全的方式生产软件而必需的工具、资源和流程的集合。
这个术语在公共和私营部门都得到了广泛应用，并且得到了包括MITRE和VMware在内的组织的认可。美国国防部（DoD）拥有29个软件工厂的强大生态系统，其中最著名的包括Kessel Run、Platform One和陆军软件工厂。软件工厂的概念也正在扩展到美国联邦民用机构，例如医疗保险与医疗补助中心（CMS）的batCAVE项目。这个术语还得到了行业领先组织如CNCF的认可，他们发布了他们的安全软件工厂参考架构。让我们来更详细地了解一下。

安全软件工厂参考架构

CNCF定义软件供应链为“在编写、测试、打包和分发应用软件给最终消费者时执行的一系列步骤。” 软件工厂是在总体上促进软件交付的逻辑构造，在正确实施时确保安全性是应用交付过程的关键组成部分。
CNCF安全软件工厂（SSF）参考架构（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/securesoftware-factory/Secure_Software_Factory_Whitepaper.pdf）建立在先前的CNCF出版物基础上，如云原生安全最佳实践（链接：https://github.com/cncf/tag-security/tree/main/security-whitepaper）和软件供应链最佳实践（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf）。该参考架构强调现有的开源工具，重点放在安全性上。它还围绕着《软件供应链最佳实践》白皮书中的四个总体原则展开：

深度防御
签名和验证
制品元数据分析
自动化

每个原则都是确保从软件的起源和代码到生产环境安全交付的必要条件。
该参考架构还明确指出，它并不专注于像代码扫描和签名这样的关注点，而是更深入地关注代码来源和构建活动。这种关注的理由在于，下游活动，如静态应用安全测试/动态应用安全测试（SAST/DAST），依赖于验证来源以及您从中接收某些内容的方当的身份是否是受信任的实体。这些身份可以是与人类用户相关联的身份，也可以是与机器身份相关联的身份。签名的结合以及验证其来自可信源的事实对于保证来源的可靠性至关重要。
安全软件工厂（SSF）中的每个实体都有依赖关系，无论这些依赖关系是与更广泛的组织IAM系统相关、源代码管理相关，还是下游消费者依赖于SSF本身来证明和签名他们正在使用的制品。
SSF具有多个组件，其中一些被认为是核心组件、管理组件和分发组件。核心组件负责接收输入并使用它们来创建输出制品。管理组件专注于确保SSF与您的策略保持一致运行。最后，分发组件将工厂的产品安全地移动到下游进行消费。

核心组件

这些核心组件包括您的调度和编排平台、流水线框架与工具，以及构建环境。所有SSF组件都使用平台及其相关的编排来执行它们的活动。流水线及其相关工具能够促进构建软件制品的工作流程。指南强调，流水线应该符合与您的工作负载相同的要求。这旨在指出流水线是您攻击面的一部分，并且可以被利用来影响下游消费者，就像SolarWinds事件中的情况一样。这种强调也得到了像SLSA等新兴框架的支持。
最后，您有构建环境，这是将您的源代码转换为机器可读软件产品（称为制品）的地方。成熟的构建环境正在努力提供关于构建过程中使用的输入、操作和工具的自动证明，以验证构建过程及相关输出/制品的完整性。
像TestifySec（www.testifysec.com）这样的组织正在进行创新，以确保组织能够检测流程篡改或构建受损。一个显著的例子是Witness项目，旨在防止构建材料的篡改，并验证从源到目标的构建过程的完整性（链接：https://github.com/testifysec/witness）。

管理组件

管理组件包括策略管理框架、证明者和观察者。在SSF的背景下，您的策略管理框架是帮助编码组织和安全需求的核心，例如IAM（身份和访问管理）、分配的工作节点和授权的容器镜像。由于不同的风险容忍度和多种适用的监管框架，这些策略在每个组织中可能会有所不同。随着零信任模型的推广，策略管理框架尤为关键。
确定谁有权做什么及在何种上下文中进行是执行零信任原则（如最低权限访问控制）的关键。您不希望部署由未经授权的个人推送的容器，甚至不希望使用您不信任或未经您信任来源签名的容器等。鉴于云原生环境通常意味着您使用容器和像Kubernetes这样的编排器，您将拥有节点证明者、工作负载证明者和流水线观察者等实体。它们验证节点和工作负载的身份和真实性，以及与流水线过程相关的可验证元数据。

分发组件

在SSF中识别的关键组件中，还包括分发组件，包括制品库和准入控制器。您的流水线过程的输出产生制品，这些制品存储在您的制品库中。这些制品可以包括容器镜像、Kubernetes清单、SBOM（软件供应链安全性清单）以及相关签名。越来越多地，我们看到使用诸如Sigstore之类的解决方案来签署不仅仅是代码，还有SBOM和证明。这在之前讨论过的Linux Foundation/OpenSSF开源软件安全动员计划中得到了强调（链接：www.csoonline.com/article/3661631/the-open-source-software-security-mobilization-plan-takeaways-for-security-leaders.html）。在制品库之后，您有准入控制器，负责确保只有授权的工作负载可以由调度和编排组件运行。这些控制器可以执行策略，例如允许哪些来源进入构建，允许哪些组件进入节点主机，并且使用的组件是可信且可验证的。

变量和功能

SSF指南理解到，SSF的输入和输出会有所不同。输入包括源代码、软件依赖、用户凭据、加密材料和流水线定义等。输出包括软件制品、公共签名密钥和元数据文档等。白皮书还讨论了SSF的功能，例如项目在SSF中的流动过程，最终提供经验证和具有一定保证水平的安全输出和制品，以建立与下游消费者的信任关系。

小结

初看起来，SSF参考架构似乎很复杂，而实际上确实如此。在现代云原生环境中交付软件涉及许多组成部分和相关流程，以确保所消耗和生产的内容能够以符合组织风险容忍度的保证水平完成。
这种复杂性还强调了将所有要素整合在一起的挑战性，以及系统中可能存在的错误和配置错误的机会，这些可能会对整个生态系统中的消费者产生连锁反应的影响，而现代经济中的所有这些都由软件驱动。人们常说，防御者必须始终正确，而恶意行为者只需一次正确。在充满人员挑战和认知负荷的复杂云原生环境中，这就像在一堆针中寻找特定的针，而不是在一堆草垛中寻找。

第七章现有和新兴商业指南

7.6 微软的安全供应链消费框架

作为开源软件（OSS）的主要贡献者和消费者之一，微软推出了一个名为安全供应链消费框架（Secure Supply Chain Consumption Framework，S2C2F）的软件供应链安全框架并不奇怪。微软于2022年8月正式宣布了S2C2F，但他们早在2019年就已经开始在内部使用该框架来保护他们自己的开发实践。更进一步，微软于2022年11月将S2C2F贡献给了开源社区，通过让行业开源软件安全基金会（OpenSSF）正式采纳（链接：www.microsoft.com/en-us/security/blog/2022/11/16/microsoft-contributes-s2c2f-to-openssf-to-improve-supply-chain-security）。
把我们深入了解一下这个框架，看看它涵盖了哪些内容并旨在实现什么目标。微软表示，该框架的目标是阐明安全消费开源软件依赖的核心概念，并实施安全开源软件消费的核心实践。与类似的框架一样，该框架强调了开源软件在软件生态系统以及更广泛的行业中的关键作用，无论是在推动生产力还是创新方面。微软指出，该指导分为两个部分：

面向解决方案无关和成熟度导向的部分，旨在针对安全高管等个人。
实施部分，专注于实际的软件开发人员及其安全同行，这使得在组织层面具有信息性的同时，在战术层面上也是可操作的。

S2C2F具有三个高层次的目标：

为建立一个强大的开源软件（OSS）治理程序
提升解决已知开源软件漏洞的平均修复时间（MTTR）
预防使用受损和恶意的开源软件包

这三个框架目标与以下三个核心概念相辅相成：

规模化
持续过程改进
控制所有工件输入

图7.11展示了这些目标和核心概念。
尽管核心概念表面上听起来简单，但在开发软件的大型企业环境中，它们可能非常复杂和令人畏惧。正如S2C2F指出的那样，现代软件开发人员以多种方式消费开源软件。开发标准化的开源软件消费方式，并让开发人员坚持这些方式，有助于确保开源软件的安全性。
整个组织的所有开发团队中引入一种受控和结构化的开源软件（OSS）消费方法至关重要。与大多数安全框架类似，S2C2F是组织踏上的一段旅程，因此它被构建为一个专注于持续过程改进的成熟度模型。组织可以优先考虑早期实施的特定要求，并在新的威胁和风险出现时进行调整。
最后，单独实施的做法和成熟度并不高效，也无法应对现代企业广泛的攻击和风险面。因此，S2C2F以规模化作为一个核心概念。指南特别提到的一个具体例子是倡导开发人员使用集中式内部注册表，这也是NIST软件供应链指南800-161 r1等来源的建议之一。
正如框架指出的，一旦单个开发人员决定从内部注册表之外的任何地方拉取开源软件组件，这种模型就会崩溃，而内部注册表本身需要额外的开销和管理，这带来了相关的负担和成本。正如他们所言，S2C2F的设计旨在在不采用其他指南中提倡的集中化方法的情况下，规模化地确保开源软件的消费安全性。这种思维方式对于倡导或采取更为分散化方法的组织应该是有共鸣的。
S2C2F是一个结合工具和要求的能力成熟度路线图，专注于通过治理确保安全的开源软件摄入。S2C2F指南讨论了常见的开源软件供应链威胁，不仅涵盖威胁本身，还包括现实世界中发生的攻击实例，并将它们映射到具体的S2C2F要求上。S2C2F提供的示例涵盖了从开源软件代码或容器中的意外漏洞到仓库和软件包中的有意后门和恶意活动。该指南借鉴了诸如Google的《软件供应链威胁》等来源，其中涵盖了源头、构建、部署/运行时和依赖项等方面的威胁（链接：https://cloud.google.com/software-supply-chain-security/docs/attack-vectors）。列出的威胁还包括了更为温和的来源，如已经停止更新并且不再修复漏洞的开源软件组件，以及维护者未能在消费者期望的时间内修复漏洞。

第七章现有和新兴商业指南

7.7 S2C2F 实践

如前所述，S2C2F包括一系列解决方案和供应商无关的实践，这些实践可以帮助组织确保其开源软件供应链的安全使用。合规、安全、工程管理人员以及首席信息安全官（CISO）等领导者可以参考这些实践，以识别其组织在安全使用和治理开源软件方面存在的差距。现在让我们逐步了解这些实践，以理解它们包含了哪些内容。
第一个被引用的实践是摄入（Ingestion）。正如S2C2F指出的那样，安全保障软件供应链的第一步是控制工件输入，包括打包和源代码工件。这里的实践旨在使组织能够在外部开源软件源可能被 compromised 或不可用的情况下仍能够交付资产。打包工件包括诸如Linux软件包仓库或Open Container Initiative（OCI）注册表等内容。组织需要代理这些外部来源并保存所需的副本。在源代码工件方面，该实践提倡在内部镜像外部源代码仓库，并在本地缓存软件包，以使组织能够在不利情况下继续运作，从而展示业务连续性。这还允许组织进行安全扫描，甚至在需要时向上游贡献修复程序，或在本地修复代码而不是向上游贡献。
在摄入（Ingestion）之后，下一个实践是扫描（Scanning），其目标是确保消费组织和个人能够看到与开源软件组件相关的漏洞。正如S2C2F所述，通过扫描摄入的开源软件组件，组织可以识别配置错误、易受攻击的代码、已知漏洞或增加潜在攻击面的额外代码，从而建立对组件安全状况的可见性，进而构建信任。组织可以利用众多开源软件和专有的扫描工具来执行这一实践。一旦组织摄入并扫描了开源软件组件，它们需要对其进行清单管理，以便了解这些开源软件组件存在于生产环境中的位置。S2C2F使用的一个完美例子是Log4J事件。那些准确记录开源软件组件清单的组织，比那些缺乏这种清单的组织在应对事件时表现得更加从容。随着其他重要漏洞在开源软件组件中的出现，有清单的组织可以通过修复或优先处理易受攻击或已被入侵的组件和系统来快速响应。
经过扫描和编制清单的开源软件组件是一个很好的开始，但众所周知，软件像牛奶一样会老化——这意味着生产环境中的组件必然需要更新和修补。因此，接下来的实践是具备根据需要更新组件的能力。众所周知，当漏洞被公开披露时，通常是组织修补或处理漏洞与恶意行为者利用漏洞之间的竞赛。
因此，跨企业的开源软件覆盖面，对于在规模上更新和修补易受攻击组件的能力至关重要。另一个考虑因素是，开源软件组件通常由志愿者维护，并没有与漏洞处理相关的服务级别协议（SLA）。因此，如果开源软件维护者未直接提供补救措施，消费者必须准备实施虚拟修补和其他缓解控制措施。
拥有围绕开源软件摄入和使用制定的标准化流程是一回事，但你必须能够审计你的环境，以识别那些偏离流程或对你的组织构成风险的组件。
因此，指南中的下一个做法是审计。这意味着组织可以对其开放源码软件组件进行审计，并验证它们是否经过了摄取、扫描和清点的标准化流程；否则，治理就会开始崩溃。
审计固然重要，但组织必须能够对发现的不受治理的开放源码软件组件采取措施。因此，执行是指南中的下一个实践。如果开发人员绕过既定流程，从不受信任的来源引入不受管理的开放源码软件组件，那么组织必须能够纠正这种偏差。指导意见提供的例子是，如果引入未经验证的开放源码软件组件，则强制执行 DNS 流量重路由或在构建流程中建立关卡，以中断构建。越来越多的恶意行为者试图破坏构建流程或基础架构，从而导致二进制文件和工件受损。
指南中的下一项内容是，能够从源代码中重建部署的每个开放源码软件工件。如果恶意行为者能够插入带有后门的恶意开放源码软件包，或在构建过程中对生成的二进制文件进行未经授权的更改，这一点就变得非常关键。
S2C2F 强调，对于关键工件或关键业务的高价值资产，可能有必要为用于创建生产服务或应用程序版本的每个工件创建从原始源代码开始的监管链。本实践的重点是使依赖于关键开放源码软件组件的开发人员能够获取源代码、重建源代码、在需要时修改源代码（如通过签名），然后缓存重建后的工件供内部使用。
这种做法直接指向可重现构建，即软件开发中创建从源代码到二进制代码的独立可验证路径的做法 (https://reproducible-builds.org/docs/definition)。这将导致所有相关工件的比特位完全相同的副本。您会注意到这一实践在其他新兴指南（如 SLSA）中也很普遍，尤其是在成熟度较高的情况下。
S2C2F 的最后一项实践是能够修复问题并向上游反馈。S2C2F 规定："我可以在接到危害通知后 3 天内私下修补、构建和部署任何外部工件，并将修复结果秘密贡献给上游维护者。这是一种非常成熟的做法，因为它将责任从严格依赖维护者转移到了软件消费者作为开放源码软件项目或组件的积极贡献者。这正是我们在文中其他部分提到的研究人员所倡导的行为类型，例如 Chinmayi Sharma 题为 "数字公共资源的悲剧 "的研究。
尽管如此，该指南指出，这仅适用于极端情况，以及上游维护者无法在贵组织可接受的风险窗口内提供公共修复时的临时风险缓解。这体现了对允许维护者采取适当行动的认可，同时也愿意在适当的时候提供帮助，这正是开放源码软件社区的精神所在。S2C2F 还提倡组织为开放源码软件社区做出贡献的几种方式，如直接或通过基金会提供财政支持、参与赏金计划、倡导最佳实践，以及积极参与重要的开放源码软件项目。

第七章现有和新兴商业指南

7.8 S2C2F 实施指南

如图 7.12 所示，与 SLSA 等其他框架一样，S2C2F 也围绕四个成熟度级别展开，从最基本的开放源码软件治理一直到高级威胁防御，每个级别都有自己的相关活动。

第1 级包括基本活动，如内部缓存软件包、进行基本清查和基本扫描，以及更新环境中的开放源码软件。第 2 级在此基础上，缩短修补易受攻击组件和执行事件响应的平均恢复时间（MTTR）。第 3 级包括创建一个已知恶意或不可靠组件和来源的否认列表，扫描开放源码软件组件中的恶意软件，并强制执行出处。最后，第 4 级被认为是理想级，这意味着除了行业内资源最丰富、最敏感的组织外，大多数组织都无法达到这一成熟度级别。这一级别的活动包括在可信的构建基础架构上重建开放源码软件，以及为重建的开放源码软件组件创建和数字签名 SBOM。

虽然这四个成熟度级别和相关的能力或要求很有帮助，但组织需要了解如何根据这些级别来评估自己或他人。S2C2F 提供了两个高级步骤：准备评估和实际执行评估。准备工作包括确保组织能够自如地与开发和工程团队接触，以了解指南中讨论的工具、能力和工作流程。指南还提供了一系列可用于评估的示例问题。这些问题涉及了解项目中目前如何使用开放源码软件、其来源以及现有的治理和安全实践，正如前面的核心概念、目标和框架的成熟度级别中所讨论的那样。

评估结束后，各组织应能更好地了解其目前在框架建议的能力和实践方面的成熟度。有了这种认识，组织就有能力制定改进计划，以解决评估过程中发现的不足或薄弱环节。然后，各组织可以根据各自的目标和风险承受能力，有针对性地进行投资和采取举措，以提高他们认为最关键的能力和做法。

S2C2F 以矩阵表的形式列出了框架的要求，其中包括实践、要求 ID、成熟度级别、要求标题以及实施该实践给组织带来的相关收益。由于工具是一个核心组件，并符合各种要求和成熟度级别，指南还提供了工具的可用性和建议，其中包括现有的免费工具、微软提供的工具以及微软正在开发的拟议工具。

S2C2F 指南是对供应链安全对话的有益补充，微软对 OpenSSF 框架的贡献表明了微软对开放源码软件社区和帮助业界解决这一问题的承诺。

第七章现有和新兴商业指南

7.9 OWASP 软件组件验证标准

与 NIST 的安全软件开发框架（SSDF）等由政府组织创建的框架不同，OWASP 的软件组件验证标准（SCVS）是一项由社区推动的工作，重点关注软件供应链。它主要通过确定可在整个软件供应链生命周期中实施的相关活动、控制措施和最佳实践来降低软件供应链中的风险。OWASP 的SCVS 在 NIST SSDF 指南中也有引用，这将在第 8 章中讨论。SCVS 1.0版于 2020 年发布，由 Steve Springett 及其他几位贡献者和审核者领导。

SCVS 分成六个控制系列，每个系列包含多个控制，用于软件组件验证和流程的各个方面：

■ 库存
■ SBOM
■ 构建环境
■ 软件包管理
■ 成分分析
■ 来源和出处

SCVS 级别

与 SLSA 相似，SCVS 也使用级别，级别越高，与之相关的控制越多。SCVS有三个级别。1 级适用于低保证要求和基本控制。第 2 级适用于中度敏感软件和需要额外严格控制的情况。第 3 级适用于因数据敏感性或任务关键性而需要最高保证的环境。让我们深入了解一下这些级别，以了解与之相关的一些基本控制措施。

1 级

正如 SCVS 指南所述，1 级为所有后续级别和更高级别保证奠定了基础。与其他框架一样，第 1 级包括一些基本活动，其中最重要的是建立准确的清单。在软件领域，这越来越多地涉及创建 SBOM，以了解应用程序中涉及的软件组件。第 1 级还包括使用持续集成（CI）来实现可重复的构建。流行的 CI 平台包括 CircleCI、Jenkins、GitLab 和 GitHub 等。持续集成涉及开发人员将所有代码工作副本合并到共享的主仓库。CI既涉及技术，也涉及实践，如 CI 或构建服务，还涉及开发人员学习频繁集成代码变更的文化方面。最后，第 1 级要求利用公开可用的工具和情报对第三方组件进行分析。各种工具可以帮助分析和识别与第三方软件组件相关的公开披露漏洞，我们将在下面的章节中对此进行更深入的探讨。SCVS 还包括第 2 级和第 3 级，每一级都在基线第 1 级的基础上增加了额外的严格性或要求。

2 级

如 OWASP 所述，SCVS 的第 2 级主要针对软件密集型组织，这些组织在其环境中的风险管理已达到一定的成熟度。第 2 级以第 1 级中确定的控制措施为基础，引入更多利益相关者和相关方，例如可能涉及合同和采购等领域的非技术专业人员。

3 级

第 3 级是 SCVS 中最严格的级别，重点关注整个软件供应链的可审计性和端到端透明度。这一级别通常只适用于监管最严格、最敏感的行业以及最成熟的组织。
OWASP 建议企业使用 SCVS 来逐步提高软件供应链的安全性。他们还建议组织定制 SCVS，以适应与使用该标准的组织最相关的安全性和合规性要求。这是一个独特的视角，它提倡灵活性，而不是其他安全标准和框架通常采用的统一基线。
说到这里，让我们来了解一下 SCVS 所定义的控制族和相关控制。

库存

正如 SANS 和随后的 CIS 关键安全控制框架等资料所引用的那样，拥有准确的库存长期以来一直是一项关键安全控制。尽管已被引用，但长期以来，这也是各组织努力应对的一项挑战，因此，将 "库存 "作为 SCVS标准中列出的首个控制系列也就不足为奇了。在 SCVS 的背景下，重点在于对创建软件过程中使用的所有组件进行清查，并提倡控制措施应覆盖单个应用程序、整个组织范围内的清查，以及提高与软件获取相关的软件透明度。SCVS 与更广泛地推动软件透明化一样，主张建立全组织范围的软件清单，其中包括第一方和第三方软件组件，包括开放源码软件代码。

清单系列中的第 1 级侧重于关键活动，如在构建时了解直接组件和传递组件，以及使用软件包管理器管理第三方二进制组件。第 1 级还包括以机器可读格式编制第三方组件的综合清单，并为公开和商业应用程序生成 SBOM。第 2 级在这些控制措施的基础上，还要求为新采购的软件提供 SBOM。这是一个控制措施的例子，它超越了网络从业人员，并开始让其他非技术利益相关者参与进来，如采购专业人员，他们可以开始要求将这些工件作为采购的一部分。

库存系列中的第 3 级开始增加更严格的控制措施，如持续维护所有系统的 SBOM 和了解整个库存的组件类型。第 3 级不仅要求了解组件类型，还要求了解组件的功能，更重要的是了解所有组件的来源。这通常被称为与软件供应链相关的出处。

软件物料清单

软件物料清单（SBOM）是 SCVS 框架中的一个关键组件和安全控制系列。SCVS 指出，拥有成熟开发实践的组织正在创建 SBOM，作为其构建流水线活动的一部分，并以机器可读的格式进行创建。SCVS 认识到有多种 SBOM 格式，如 CycloneDX 和 SPDX，企业需要与最适合其使用案例的格式保持一致，甚至可能需要一种以上的格式，以满足功能和合同要求等方面的需要，并能够与多样化的供应商生态系统合作。

SBOM 系列的第 1 级规定了一些基本控制措施，如提供结构化和机器可读的 SBOM、为 SBOM 分配唯一标识符以及使用时间戳等元数据。在这些控制措施的基础上，SCVS 要求为 SBOM 所描述的所有组件提供完整准确的 SBOM 清单，并分析 SBOM 中与组件相关的任何漏洞。最后，还要求确保组件标识符在可能的情况下来自本地生态系统，并为 SBOM中包含的组件提供准确的许可信息。

在第 1 级要求的基础上，SBOM 系列的第 2 级增加了一些控制措施，如不仅要由发布者、供应商或认证机构签署 SBOM，还要执行签名验证活动。第 2 级还要求 SBOM 具备应用程序所有测试组件的准确清单，以及SBOM 所描述的资产或软件的元数据。最后，还要求 SBOM 中定义的组件具有有效的 SPDX 许可证 ID 或表达式（如适用）。

第 3 级为 SBOM 系列活动增加了更多控制措施。其中包括以机器可读格式（如 PURL）标识组件的来源点，以及为 SBOM 中定义的软件组件提供有效的版权声明。此外，第 3 级还要求为 SBOM 中定义的组件提供详细的出处和血统信息，并为 SBOM 中定义的组件使用 SHA-256 等文件哈希值。

构建环境

SCVS 认识到现代构建环境的复杂性，包括源代码和软件包库、CI/CD流程、测试活动以及支持软件构建和交付的网络基础设施和服务。正如SCVS 所述，构建环境和管道中的每一个实体和活动都为恶意行为者提供了可能的攻击载体，也为传统故障和错误配置的发生提供了机会。其他框架（如 SLSA）或许最能说明这一点，它们说明了现代管道和构建流程中的各种攻击载体和潜在弱点。

构建环境控制系列是 SCVS 标准中最大的控制系列，与之相关的控制有 20 多项。第 1 级涉及基本控制措施，如拥有可重复的构建流程、与构建说明相关的文档以及使用 CI 管道。它还涉及一些控制措施，如确保应用程序构建管道只能从版本控制系统中的源代码执行构建，并确保在构建时对源代码和二进制文件进行已知和定义的更改。最后，第 1 级要求为每次构建记录所有第一和第三方软件组件的校验和。

构建环境控制的第 2 级开始增加一些活动，如构建管道不允许在执行构建的作业之外修改构建，或更改软件包管理设置，或在作业构建脚本的上下文之外执行代码。第 2 级还要求在构建管道上执行身份验证和授权以及默认拒绝设置。鉴于构建管道本身可能会因系统和软件过时而受到威胁，第 2 级要求为构建管道技术栈制定维护计划。最后，第 2 级要求对所有组件进行校验，并在打包或分发组件时进行带外交付。

第 3 级的最终要求包括要求在构建管道中修改系统设置时分清关注点/职责，以及保留所有系统变更和构建作业变更的可验证审计日志。此外，还要求监控编译器、版本控制系统 (VCS)、开发工具和软件开发工具包 (SDK)，以防篡改和恶意代码。控制措施要求确保未使用的直接和传递组件已被识别并从应用程序中移除，这有助于减少攻击面和最大限度地减少恶意行为者的潜在攻击载体。

软件包管理

SCVS 指出，现代开放源码软件组件通常会发布到特定于生态系统的软件包资源库中，如 Maven、.NET 和NPM。SCVS 指出，现代开放源码软件组件通常发布到生态系统特定的软件包库中，如 Maven、.NET 和 NPM。越来越多的组织被引导建立内部存储库，不仅包含第一方组件，还包含可信的第三方组件，NIST 800-161r1 和《美国国家安全局开发人员安全指南》等指南都建议采用这种方法。SCVS 指出，在构建过程中经常会调用软件包管理器，使用软件包管理器在业务和技术上有很多好处，但同时也要考虑到安全问题。

软件包管理系列的 1 级控制包括确保从软件包资源库检索二进制组件，并确保其内容与开放源码软件组件的权威来源一致。软件包库还必须支持在更新这些组件时进行审计/记录，并在从远程软件包库或文件系统检索软件包时验证其完整性。软件包管理器还应为数据交换执行传输层安全（TLS）等加密措施，并确保 TLS 证书链经过验证，或在无法验证时安全失效。安全失效是指当 TLS 证书链无法验证时，系统会默认为安全状态，而不是允许进行中的功能和活动。软件包管理器也不得执行组件代码，软件包安装数据应以机器可读格式提供。

软件包管理系列中的第 2 级将控制措施从第 1 级提升到第 2 级，要求对软件包存储库进行强身份验证，包括使用 MFA。企业可能需要特别关注防网络钓鱼的 MFA (www.yubico.com/resources/glossary/phishing-resistant-mfa/?gclid=Cj0KCQjwj7CZBhDHARIsAPPWv3fXCG329UPlV7Oz3WZvIvcdHfJeDqo60tPOHaa9KsNcXZ2BZK5N_voaAvhqEALw_wcB)，因为最近发生的事件涉及 MFA 被泄露或滥用（www.malwarebytes.com/blog/news/2022/08/twilio-data-breach-turns-out-to-be-more-elaborate-than-suspected#:~:text=Earlier%20this%20month%20%2C%20messaging%20service,more%20elaborate%20than%20originally%20assumed）。除强身份验证外，第 2 级还要求确保软件包库支持进行安全事件报告和向发布者通报安全问题的能力。还有一些控制措施要求软件包资源库能够将组件版本与 VCS 中的源代码进行可验证的关联，并要求在将软件包发布到生产资源库时进行代码签名。

最后，软件包管理系列中的第 3 级增加了一些额外的控制。这些控制措施包括确保软件包存储库的组件已通过 MFA 和自动安全事件报告发布，包括通知用户安全问题。此外，还要求软件包存储库在发布组件之前执行SCA，然后将这些结果提供给软件组件消费者，并进行分析和保证。

成分分析

SCVS 的第五个控制系列是 "组件分析"，即识别使用开放源码软件和第三方组件（不仅包括直接组件，还包括传递组件）的潜在风险领域的过程。各组织需要了解与开放源码软件及其应用程序和系统中使用的第三方组件相关的任何固有风险。开放源码软件和第三方软件的使用非常普遍，绝大多数现代应用程序都由开放源码软件和第三方软件组件组成。企业必须了解他们正在使用的组件以及与这些组件相关的任何漏洞和风险。

为了了解漏洞，组织通常会参考 NIST 国家漏洞数据库 (NVD) 等来源来查找已知漏洞。除已知漏洞外，组织还应熟悉其他数据，包括组件版本货币、组件类型、功能和数量等术语。这意味着要了解组件是否过期或报废，是否可能存在漏洞，还要了解组件类型及其升级和风险的相关影响。各组织应了解组件的功能，以识别重复组件，并只使用质量较高的组件，从而将风险降至最低。企业还应该了解其库存中的组件数量，因为管理组件蔓延变得越来越困难。最后，企业必须了解与正在使用的组件相关的许可证类型，因为可能存在会带来业务风险的分配要求、限制和冲突。

组件分析系列第 1 级涉及的活动包括能够使用衬砌器和静态分析对组件进行分析。重点是自动化活动，如识别与组件相关的公开披露漏洞，识别使用中的非指定组件版本或过时组件。各组织还必须有自动流程来识别使用中的组件数量和与组件相关的许可。

第 2 级在此基础上更进一步，确保组件通过内衬和静态分析（包括组件的每次升级）进行分析，并自动识别使用中的组件类型。

第 3 级的主要区别在于自动识别已确认的可利用性、组件的使用寿命/支持以及组件功能。

来源和出处

最后一个控制系列是 "来源和出处"，这一点至关重要，因为如果不了解所消费软件的质量、来源和交付过程中的监管链，就很难信任或了解与软件消费相关的风险。

在 "来源与出处 "系列中，第 1 级涉及记录修改组件的出处，并以与未修改组件相同的严格程度分析修改组件。此外，还包括控制措施，以确保组织了解修改过的组件及其相关变体所独有的风险。

在第 1 级的基础上，第 2 级增加了控制措施，以确保组织记录了可验证的组件修改血统，并对修改后的组件进行唯一标识。

第 3 级的唯一控制措施是建立一个可对源代码和二进制组件进行审计的监管链。

开放源代码政策

虽然该指南不是 SCVS 中的正式控制系列，但它为组织更广泛地使用开放源码软件提出了建议。虽然开放源码软件的使用非常普遍，并涉及到组织生产和消费的许多现代应用程序，但许多组织在管理其消费和使用方面的安全成熟度很低。

SCVS 建议企业制定开放源码软件政策，并由跨职能利益相关者支持和执行。这些政策应涵盖与开放源码软件相关的重要考虑因素，如了解所使用组件的使用年限、设定使用旧的主要或次要修订版的要求，以及不断更新组件的自动化功能。各组织还应制定排除已知存在漏洞的组件的指导原则，或至少对可接受的风险水平做出规定。有风险的组件应有明确的 MTTR 标准，并因其固有风险而限制使用报废组件。有些组织甚至可能会因为漏洞、国家安全问题或其他因素而制定一份禁止使用的组件清单。

如前所述，虽然开放源码软件的使用非常普遍，但许多组织并没有花时间将其对开放源码软件的立场编入正式的政策和指南中。我们已经开始看到一些组织率先垂范，超越了政策的范畴，建立了开放源码项目办公室（OSPOs）（www.linuxfoundation.org/resources/open-source-guides/creating-an-open-source-program），帮助管理和推动组织在其生产的软件中使用开放源码软件，以及开放源码软件的消费者。

第七章现有和新兴商业指南

7.10 开放源码安全基金会评分卡

每个人都知道Marc Andreessen在十多年前提出的“软件正在吞噬世界”(https://a16z.com/2011/08/20/why-softw-is-eating-the-world)。软件几乎为现代社会的方方面面提供了动力，无论是个人还是职业，它对现代经济甚至国家安全都至关重要——这是毋庸置疑的。考虑到这一现实，也可以说OSS已经吞噬了软件行业。据Linux基金会等组织估计，自由和开源软件(FOSS)构成了任何现代软件解决方案或产品的70%到90% (www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-opensource-software-application-libraries-the-world-depends-on)。

现代软件不仅主要由OSS组件组成，而且IT领导者也更有可能与那些也为OSS社区做出贡献的供应商合作(www.redhat.com/en/enterprise-open-source-report/2022)。大量使用OSS的原因有很多，比如灵活性、成本节约、通过社区支持的项目进行的创新，以及通过审查代码和在代码上拥有更多“眼球”的能力而获得的更好的安全性，特别是对于大型OSS项目。也就是说，OSS并非没有自己的担忧，包括受影响代码的漏洞和cve。CVE是MITRE的一个项目，致力于“识别、定义和编目公开披露的网络安全漏洞”(cve.mitre.org)。

然而，正如CNCF软件供应链最佳实践白皮书所指出的那样，cve是一个“跟踪度量”，这意味着cve是已公开披露的漏洞的枚举。它们也是与软件相关的潜在风险和漏洞之一。出于这个原因，建议组织使用其他方法来评估他们正在使用的特定OSS项目的安全状态，其中最值得注意的是OpenSSF的Scorecard项目(http://openssf.org)，我们将在下面讨论它。

开源项目的安全记分卡

在2020年底，OpenSSF宣布了他们的项目“记分卡”，该项目旨在为OSS项目自动生成安全评分，以帮助消费者和组织对其OSS消费做出风险知情的决策。组织正在大量使用OSS依赖项，但是确定消耗这些依赖项的风险在很大程度上仍然是一项手工活动，特别是在跨软件生态系统的规模上。Scorecard项目试图使用他们的自动启发式和安全检查来减轻一些负担，评分范围为0-10(参见图7.13)。

名称	描述	风险等级
二元属性	项目是否不包含签入的二进制文件?	高
分支保护	项目是否使用分支保护?	高
CI测试	项目是否在CI中运行测试，例如GitHubActions,Prow?	低
CL-最佳实践	项目是否有CI最佳实践徽章?	低
代码复查	在合并代码之前，项目是否需要对代码进行审查?	高
贡献者	项目是否有来自至少两个不同组织的贡献者?	低
危险工作流	项目是否避免了GitHub Action工作流中的危险编码模式?	被批评的
依赖更新工具	项目是否使用工具来帮助更新其依赖项?	高
模糊	项目是否使用模糊化工具，例如OSS-Fuzz?	中等
许可证	项目是否声明许可证?	低
维护	项目是否维护了?	高
固定依赖	项目是否声明固定依赖项?	中等
包装	项目是否从CI/CD构建和发布官方软件包，例如GitHub发布?	中等
SAST	项目是否使用静态代码分析工具，例如CodeQL、LGTM、SonarCloud?	中等
安全政策	项目是否包含安全策略?	中等
符号释放	项目是否对发布进行加密签名?	高
Token允许	项目是否将GitHub工作流令牌声明为只读?	高
漏洞	项目是否存在未修复的漏洞?使用OSV服务。	高
表7.13

计分卡项目的目标也不低;他们根据直接依赖关系扫描一百万个最关键的OSS项目，并每周将结果发布到公共数据集中。除了利用这个公开可用的数据集，组织还可以通过使用GitHub Actions对自己的GitHub项目运行记分卡。然后，当存储库中有变化时，GitHub Actions会运行并向这些项目的维护者提供警报。

Scorecard项目使用Critical、High、Medium和Low的评分等级，这是许多安全从业人员所熟悉的严重级别。Scorecard项目运行一个针对所有项目的标准检查列表，无论是公共项目还是您在自己的GitHub存储库中本地使用它。对于那些感兴趣的人，你可以深入了解其中一些分支是什么。它们包括基本的安全实践，例如使用分支保护和对发布进行加密签名。

为了检测未修复漏洞的存在，计分卡项目使用OSV漏洞数据库(http://osv.dev)，采用OpenSSF OSV格式的开源软件分布式漏洞数据库。OSV的核心是图7.13中使用OSV模式的其他漏洞数据库的聚合，例如GitHub安全咨询和全球安全数据库等。

OSC还支持api和命令行界面(CLI)工具，用于扫描CycloneDX或SPDX格式的soms，我们在第3章“漏洞数据库和评分方法”中讨论过。

组织如何使用记分卡项目?

如前所述，组织正在广泛使用OSS。然而，对OSS消费进行尽职调查、治理和风险管理的实践仍处于起步阶段。我们看到了支持软件供应链弹性和成熟组织软件供应链安全实践的巨大推动，NIST的系统和组织网络安全供应链风险管理实践，NIST的SSDF, OpenSSF OSS安全动员计划，SLSA，以及许多其他最佳实践和指导来源已经出现。所有这些都涉及到管理组织对OSS的消耗，并确保这种消耗与组织的风险容忍度保持一致的需要。

虽然表面上听起来很简单，但是在整个健壮的OSS项目和组织正在使用的组件的生态系统中这样做的想法并不是那么微不足道。OpenSSF的Scorecard项目提供了一种自动化的方式来获取超过100万个领先的OSS项目的安全和风险洞察，并允许组织将该项目原生地用于他们自己的软件和项目。

组织可以通过CLI对他们不拥有的项目使用记分卡，也可以对npm、PyPi或RubyGems等项目使用包管理器。 Scorecard也可以作为Docker容器使用，也可以通过这个路径进行部署。

计分卡项目每两周开一次会，并且有一个活跃的Slack频道。它由来自谷歌、Datto和思科等公司的推动者领导。自成立以来，Scorecard越来越受欢迎，并被列为有超过3000名Stargazers或用户，他们已将该项目加入书签。随着组织继续推动其OSS消费治理实践的成熟，该项目将不可避免地越来越受欢迎。组织和个人贡献者也有机会参与项目，包括提交用于评分评估的检查。组织还可以定制他们对Scorecard的使用，并只运行可能与组织或行业特定安全需求相一致的特定检查。

Scorecard提供了一种关键的功能，可以自动执行一组健壮的评估标准，对于组织来说，无论是在他们正在使用的公共项目上，还是在他们想要评估的内部项目上，手动执行这些标准是不切实际的。众所周知，尽管开源软件带来了价值和创新，但大多数自由/开源软件项目人员不足，并且由无偿的志愿贡献者领导。

这并不是说组织不应该利用OSS项目，而是说他们应该对他们所使用的项目和这些项目所带来的风险有一些严格的要求。Scorecard项目以易于使用的方式完全满足了这种需求。它在评估OSS项目的安全问题时完成了所有这些工作，这些安全问题与最佳实践(如签名、SAST等)保持一致，这些都是公共和私人安全领导者已经提倡的。

第七章现有和新兴商业指南

7.11未来之路

虽然开源软件提供了巨大的好处，但许多关注和研究发现，自由/开源软件开发人员在很大程度上没有优先考虑安全性。Linux基金会的OpenSSF和哈佛大学创新科学实验室的一项研究发现，自由/开源软件开发人员平均只花大约2.3%的时间来提高代码的安全性(www.darkreading.com/applicationsecurity/open-source-developers-still-not-interested-in-secure-coding)。

这保证了使用OSS组件的组织采取各种措施，例如在使用之前审查OSS组件，并使用soms来了解与他们的OSS消费相关的漏洞以及这些组件在企业中的位置，因此他们能够更好地响应下一个Log4j类型的情况。

为了获得更具体的指导，组织可以参考NIST的开源软件控制推荐实践，该实践是根据网络安全行政命令(EO) 14028发布的，改善国家网络安全(www.nist.gov/itl/executive-order-14028-improvingnations-cybersecurity/software-security-supply-chains-open)。
这些包括基于组织成熟度的分层能力:基础的、持续的和增强的。在这些层中有一些功能，例如使用SCA源代码审查来识别易受攻击的组件，优先使用带有内置护栏的编程语言，以及在将OSS组件引入生产环境之前，将收集、存储和扫描OSS组件到加固的内部存储库的过程自动化。

现在应该很明显，安全使用OSS或任何软件都没有灵丹妙药或银弹。也就是说，通过人员、流程和技术的正确组合，按照这个顺序，组织可以获得OSS的好处，同时降低使用OSS的风险。

第七章现有和新兴商业指南

7.12 总结

在本章中，我们讨论了现有的和新兴的软件供应链安全指南。这包括SLSA的努力以及来自微软、CNCF和其他机构的资源。在下一章中，我们将讨论来自政府实体的现有和新出现的指导意见。

第八章现有和新兴政府指南

在本章中，我们将讨论政府和公共部门组织针对软件供应链安全的现有和新兴出版物。这些出版物建立在我们在上一章中讨论的现有商业指南的基础上，并考虑了国防部（DoD）、美国联邦民事行政部门（FCEB）机构和国家安全局（NSA）等机构的一些独特要求。

第八章现有和新兴政府指南

8.1 系统和组织的网络安全供应链风险管理实践

2020年初，美国国家标准与技术研究院(NIST)首次发布了特别出版物(SP) 800-161，“系统和组织的网络安全供应链风险管理(C-SCRM)实践”。然而，与本书中讨论的许多其他资源一样，网络安全行政命令(EO) 14028保证对原始NIST C-SCRM出版物进行更新。

《网络安全行政令》第4(b)、4(c)和4(d)条特别关注软件供应链问题，因此，NIST在800-161修订版1附录F中发布了他们的回应和指南，即“对14028号行政命令关于发布增强软件供应链安全指南的呼吁的回应”。而不是将指导嵌入到更广泛的800-161文件，NIST将其作为独立资源发布在网上(www..nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/ software-security-supply-chains)。

在深入研究NIST提供的具体指导之前，我们应该回顾一下《行政令》第4节的详细内容。第4部分要求商务部长通过NIST与政府、行业和学术界合作，确定现有的或开发新的标准、工具和最佳实践，以与《行政命令》第4部分保持一致。本节包括评估开发人员和供应商的软件和安全实践的标准。

此外，这项评估的任务是在《行政令》公布后30天内进行。除此之外，在发布后的180天内，NIST主任被要求发布主要指导方针，以增强与第4节要求一致的软件供应链安全性。

在行政令发布后的一年内，NIST的主任被要求发布额外的指导方针和程序，以定期审查和维护NIST就该主题发布的指导方针。为了制作在线发布的初步指南，NIST从SP 800-161r1中提取了见解，以及在2021年6月“增强软件供应链安全研讨会”(https://csrc.nist.gov/Events/2021/enhancement-Software-Supply-Chain-Security-Workshop)工作组，当然还有NIST EO页面本身提交给NIST的各种立场文件。

NIST的800-161r1指南致力于告知各机构作为其IT计划的一部分使用的第三方软件和服务的获取、使用和维护。该指南可以集成到他们的C-SCRM计划中，并用于帮助通知采买和采购活动。它不仅可以被联邦机构实施和使用，也可以被相关的供应商用来支持他们的软件供应链实践和过程。随着这些最佳实践和需求进入联邦合同语言，并成为向美国联邦政府出售产品的软件供应商所必需的，该指南将变得相关。

NIST还提供了一个关系图来说明他们的各种出版物(如800-37r2、800-53r5)和安全软件开发框架(SSDF)之间的关系，这将在后面的“NIST的安全软件开发框架”一节中讨论。这些文档既可以用于政府购买安全软件，也可以用于行业对这些最佳实践和需求的认证。图8.1展示了各种出版物之间的关系。

关键软件

NIST对EO的关键要求之一是定义关键软件。NIST对关键软件的定义是“具有或直接依赖于具有这些属性的一个或多个组件的任何软件”。

关键软件：

具有对网络或计算资源的直接或特权访问
用于控制对数据或操作技术的访问
执行对信任至关重要的功能
在正常信任边界之外以特权访问操作

任何阅读此列表的人都会很快同意，这是一套复杂的标准，会使大多数软件潜在地变得关键。出于这个原因，让我们打开前面列出的一些标准。首先，必须定义直接的软件依赖关系。NIST将直接软件依赖定义为其他软件组件，如库和包，这些组件直接集成到正在讨论的特定软件中或对其操作是必要的(www.nist .gov/itl/executive-order- improvement -nations-cybersecurity/ criticalsoftwaredefines-faqs #Ref_FAQ2)。

它们还指定不包括其他独立产品的接口或服务。关键的信任可能是另一个令人困惑的短语。NIST解释说，这是指用于网络控制端点安全和网络保护等安全功能的软件类别(www.nist.gov/itl/executive-order-improvingnations-cybersecurity/critical-software-definition-faqs#Ref_FAQ3)。

NIST强调，他们的定义适用于为生产环境购买和部署的任何形式的软件。这意味着，它不适用于用于研究和开发(R&D)用例的软件。NIST还建议，关键软件需求的实现阶段首先关注用于关键安全功能的独立本地软件，或者如果受到损害可能会造成重大潜在危害的软件，然后关注其他软件，如云、混合和源代码管理等。

NIST继续提供了他们认为关键的软件类别的初步列表，以及它们包含的基本原理。该列表包括身份、凭证和访问管理(ICAM)、操作系统、Web浏览器、端点安全、网络控制等类别。其基本原理是，如果易受攻击并被利用，它们的关键访问权限和功能可能会危及系统的安全性和完整性。

对于那些希望深入了解NIST定义的关键软件的人，请查看关键软件定义FAQ页面，该页面回答了www.nist.gov/itl/executive-order-improving-nations-cybersecurity/critical-software-Definition-faqs上的一些常见问题和关注点。

关键软件安全措施

除了定义关键软件之外，NIST还为他们称为eo关键软件的安全措施提供了指导。NIST使用了来自社区、虚拟研讨会的意见书，以及来自网络安全和基础设施安全局(CISA)和管理和预算办公室(OMB)的意见，以及其他来源，以确定适用于关键软件的安全措施。

NIST为安全措施定义的主要范围是关键软件的使用，而不是它的开发和获取。也就是说，还有其他的指导来源，比如处理软件开发的SSDF，以及800-161r1本身，它更广泛地涵盖了C-SCRM和软件的获取。NIST的关键软件安全措施的目标包括保护软件和相关平台免受未经授权的访问和使用。它还努力防止被利用，并保护软件和平台使用的数据的机密性、完整性和可用性。

NIST承认事故会发生，因此组织必须能够快速检测、响应并从事故中恢复。此外，组织必须努力改进可能影响关键软件和平台的人类行为和行为。考虑到Verizon的2022年数据泄露调查报告(DBIR)等来源，这种承认是至关重要的，该报告指出，超过60%的数据泄露涉及人为因素，但组织仅将3%的安全预算用于人为方面。

NIST的指南进一步定义了一组可用于保护关键软件的健壮的安全实践和过程。它也承认，这份清单并非详尽无遗或无所不包，随着风险形势的变化，它将随着时间的推移而增长和演变。

现在，让我们深入了解NIST的一些安全措施，看看NIST为关键软件定义了哪些基本安全措施。值得注意的是，NIST关于关键软件安全措施的讨论来自许多来源，例如其他NIST出版物，以及来自CISA、OMB、NSA等的资源。

多因素身份验证(MFA)是最早列出的建议之一。认证因素通常包括以下内容:

你知道的东西
你拥有的东西
你是什么，比如用户名和密码
物理标记
生物识别来源

MFA是公共和私营部门组织经常引用的安全最佳实践。这种身份验证类型超越了用户名和密码等基本身份验证措施，它添加了身份验证因素，包括SMS文本代码、电话呼叫、通过移动设备上的身份验证应用程序进行批准，甚至还有个人身份验证(PIV)或通用访问卡(cac)等形式因素，以及YubiKeys等流行示例。(有关YubiKeys的更多信息，请访问 www.yubico.com。)根据辅助身份验证源的不同，添加这些因素会大大增加恶意行为者破坏凭据的难度。

然而，值得注意的是，即使是MFA也不是绝对可靠的，并且可能被SMS网络钓鱼等方法所破坏(https://thehackernews.com/2022/08/twilio-suffers-data-breach-after.html)。因此，NIST的指南要求MFA的使用不仅对所有管理员，而且对所有用户都是防模拟的。这有时也被称为防网络钓鱼MFA，通常身份验证方法(如密码、SMS和安全问题)不被认为是防网络钓鱼的。抵制网络钓鱼的一些核心原则是MFA包括身份验证者和用户身份之间的强绑定，消除共享秘密，并确保响应仅发送给受信任的方。

抗网络钓鱼的MFA示例包括FIDO2和PIV智能选项(www.yubico.com/resources/glossary/phishing-resistant-mfa)。基于MFA对所有用户的建议，NIST还建议对每个服务进行唯一标识和身份验证，并遵循最小特权访问管理原则。这些控制确保了适当的访问控制，并可以限制恶意网络活动的爆炸半径。正如NIST在其800-207出版物《零信任架构》(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800207.pdf)中所定义的那样，最少特权访问控制也是更广泛地推动零信任的基本原则。

虽然最低权限访问控制可以限制恶意活动的影响，但NIST的下一个建议也是如此，即采用边界保护，例如网络分段，并使用软件定义的边界。周界描述的工作原理是确保系统和环境的一个区域中的事件不会对整个系统甚至它所连接的外部系统产生级联影响。

为了实现第二个目标，即保护关键软件和软件平台使用的数据的机密性、完整性和可用性，NIST提供了一系列组织可以遵守的关键控制和实践，包括建立和维护数据清单。如果没有适当的数据清单，组织是不可能保护其数据的。网络安全领域有句流行的说法:“你无法捍卫你不知道存在的东西。”与前面讨论的网络级访问控制非常相似，也应该通过使用细粒度访问控制来保护组织的数据和资源。

NIST建议通过使用符合NIST加密标准的加密来保护静态数据(https://nvlpubs.nist.gov/ nistpubs/SpecialPublications/NIST. sp .800- 175br1 .pdf)。传输中的数据也是如此;NIST的建议是，在可能的情况下，不仅要使用加密，还要使用相互身份验证。

相互认证是指双方同时对彼此进行认证，并使用支持的认证协议(如IKE (Internet Key Exchange)、SSH (Secure Shell)和TLS (Transport Layer Security))进行认证。这样做可以确保数据在传输过程中被加密，以便数据不会暴露给可能访问它的未经授权的各方，以及他们可以减轻某些类型的攻击，例如路径攻击、重播和欺骗。

这些类型的攻击包括恶意行为者试图捕获传输中的数据、复制数据或模仿交换中的有效实体。为此，NIST的最后一条建议是，不仅要备份数据，还要执行备份恢复以准备好恢复数据。它承认，尽管存在诸如加密和相互身份验证之类的控制，事件仍然可能而且确实会发生，从而损害组织数据，并且当这些事件发生时，组织必须能够从有效的备份中恢复数据。

根据 NIST 的定义，关键软件安全的第三个目标是需要识别和维护关键软件平台和软件驻留在这些平台上的软件，以防止其被利用。这方面的控制措施包括建立和维护软件资产清单。软件资产软件资产清单也是互联网安全中心（Center for Internet Security (CIS) 在其 CIS 关键安全控制指南 (www.cisecurity.org/control) 中也推荐了软件资产清单）。

对软件进行清查和管理可以更好地进行软件治理和控制确保只有经过授权的软件才能被执行。控制，确保只有经过授权的软件才能在系统上安装和执行。当然，软件库存不仅仅是广义上的软件产品库存，还包括组件级库存。当然，软件库存不仅包括广义的软件产品库存，还包括组件级库存，即软件物料清单（SBOM本书中广泛讨论的软件物料清单 (SBOM)。除了软件库存之外，企业还应确保使用补丁管理最佳实践，确保识别、记录和缓解已知的漏洞，并采取以下措施在文档化的变更控制流程中进行。流程。软件平台以及更广泛的一般软件也需要配置管理最佳实践。这些最佳实践包括实施加固的安全配置和监控这些最佳实践包括实施加固的安全配置以及监控平台和软件是否存在未经授权的更改等活动。

如前所述，NIST 认识到，尽管实施了这些最佳实践和安全控制的最佳实践和安全控制措施，事件仍有可能发生。因此因此，第四个目标包括能够快速检测、响应和恢复影响关键软件的威胁和事故。因此，第四个目标包括能够快速检测、响应和恢复影响关键软件和平台的威胁和事件。

为实现所需的响应和恢复能力，组织必须正确记录任何安全事件的所有必要信息。要实施日志记录最佳实践，企业应利用 NIST 的《计算机安全日志管理指南》等指南以及针对其产品和平台的特定供应商指南 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf)。必须持续监控关键软件，这可以结合使用端点安全保护产品或服务（通常称为端点检测和响应 (EDR) 工具）来实现。EDR 工具有助于识别、审查和最小化攻击面以及已知威胁的暴露程度，控制软件的执行内容，并在发生事故时协助恢复。

企业必须对关键软件和平台实施网络安全保护，以检测堆栈各层的威胁，帮助预防威胁，并向安全操作人员和其他应对事件的人员提供必要的遥测数据。为了有效地进行事件响应，NIST 建议根据所有安全操作和事件响应团队成员的具体角色和职责对他们进行培训最后一个目标侧重于加强对有助于关键软件和平台安全的人类行动的理解和执行，是一个以人为本的目标。该目标包括根据关键软件和平台用户的角色和职责对其进行培训等活动，其中包括那些通常拥有较高权限的管理员。最后，它建议对关键软件和平台的所有用户和管理员进行广泛的安全意识培训，并衡量培训的效果，以推动改进和取得更好的成果。

最后一个目标的重点是加强对有助于关键软件和平台安全的人类行动的理解和执行，这是一个以人为本的目标。这一目标包括根据关键软件和平台用户的角色和职责对其进行培训等活动，其中包括那些通常拥有较高权限的管理员。最后，它建议对关键软件和平台的所有用户和管理员进行广泛的安全意识培训，并衡量培训的效果，以推动改进和取得更好的成果。

第八章现有和新兴政府指南

8.2 软件验证

NIST 网络行政命令第 4 部分指南的另一个关键组成部分是发布指南，为供应商测试其源代码推荐最低标准。它包括手动和自动测试，例如代码审查工具、静态应用程序安全测试 (SAST)、动态应用程序安全测试 (DAST) 和渗透测试。与行政命令第 4 部分指南中的其他部分非常相似，NIST 采取了从社区收集立场文件 (www.nist.gov/itl/executive-order-improving-nations-cybersecurity/enhancing-software supply-chain-security) 和举办研讨会 (www.nist.gov/itl/executive-order-improving-nations-cybersecurity/enhancing-software-supply-chain-security) 的方法。

在深入探讨所提出的验证测试方法的细节之前，值得注意的是，NIST 指出，虽然网络 EO 使用供应商一词来表示测试，但开发人员经常从外部来源获取软件，因此，如果使用来自其他来源的软件，他们也会进行自己的验证。在已发布的指南中，NIST 推荐了 11 种类型的测试和方法以及我们将很快讨论的补充技术（https:// nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf）。从高层次上讲，NIST 的指南讨论了确保开发的软件能够按照开发人员的意图运行，同时在整个生命周期中没有漏洞的必要性。获得这种保证涉及各种活动，例如威胁建模、自动化测试 (SAST/DAST)、动态分析、纠正不可接受的错误或发现，以及对任何相关库、包和服务使用类似的技术。虽然上一章涉及商业指导时已经涉及了许多此类活动，但我们将从 NIST 定义的角度简要介绍这些活动，这些活动与他们的网络安全 EO 指导相关。

威胁建模

NIST 建议在 SDLC 早期使用威胁建模来识别设计级安全问题。您将获得对系统的概念理解和可视化，并开始分析潜在攻击，以及其相关目标和潜在威胁中实现的利用方法。通过威胁建模，组织正在尝试识别潜在威胁、弱点和漏洞，然后定义与这些威胁相一致的缓解计划。NIST 指出国防部 (DoD) DevSecOps 参考架构图（如图 8.2 所示）作为威胁建模如何作为系统开发和规划活动的一部分融入 DevSecOps 方法论的一个例子。
DevSecOps 不是线性活动（例如瀑布），威胁建模也不应该是线性活动。它应该作为频繁和迭代系统和软件交付的一部分来完成。

自动化测试

NIST 在其指南中明确指出，自动化测试可以像脚本一样简单，用于自动化静态分析，也可以像创建整个环境一样复杂和自动化，包括运行测试和验证测试成功。组织可以使用简单的工具来测试支持 Web 的应用程序和字段，也可以使用涉及模块和子系统的更复杂的工具。建议包括自动验证，以确保静态分析不会报告新的弱点，测试以迭代方式运行，结果准确，并且使用自动化可以减少对人工分析和工作量的需求，而人工分析和工作量既耗费资源又容易出错。使用 Git 和 CI/CD 管道等现代开发系统的组织可以使验证过程在提交和拉取请求时自动化和可重复

基于代码或静态分析和动态测试

NIST 区分了两种方法：基于代码或静态分析和基于执行的测试，它们分别提供了 SAST 和 DAST 等示例。基于代码的静态分析推理以原生格式编写的代码，而动态分析涉及基于执行的动态测试和分析，这需要程序执行。与前面提到的用于自动化测试的 DevSecOps 方法一样，NIST 建议在编写代码后立即以迭代小块的形式进行静态代码分析。这种方法比等待对最终产品执行 SAST 更有效，因为可以在 SDLC 中尽早解决缺陷和漏洞

评论硬解码密码

NIST 建议使用启发式工具查找应用程序代码中的硬编码密码。这些密码可能涉及凭证、加密密钥、API 密钥和访问令牌等。由于 API、令牌和凭证的广泛使用，这在云原生环境中尤其具有挑战性，本书的一位作者在一篇题为 "在 DevSecOps 云原生世界中保守秘密"（www.csoonline.com/article/3655688/keeping-secrets-in-a-devsecops-cloud-native-world.html）的文章中谈到了这个话题。研究表明，相当一部分数据泄露事件都与凭证泄露有关，因此企业应加强机密管理能力，以消除这些风险。

通过语言提供的检查和保护运行

在指南中，NIST 还建议使用各种编程语言（包括编译型和解释型）提供的预构建检查。NIST 还强调，有些语言不具备内存安全性，即防止程序员引入与应用程序中内存使用方式相关的特定类型的错误，并建议强制执行内存安全性。除了使用内置的强制执行功能外，企业还可以使用静态分析器或 "精简器 "等措施来查找危险的函数和参数。值得注意的是，其他指南（如上一章讨论的 OpenSSF 开源安全动员计划）也建议业界转向内存安全语言，摒弃与内存安全相关的固有风险增加的传统语言。

黑盒测试用例

与前面讨论过的测试类型不同，黑盒测试并不与特定的代码片段挂钩，而是侧重于功能需求，并验证软件不应该做什么。这些测试包括拒绝服务和输入边界等内容，在进行测试时不需要源代码分析和威胁建模所需的内部知识和假设。

历史测试案例

当 NIST 指南使用 "历史测试用例 "一词时，它指的是通常所说的回归测试。回归测试在成熟的安全团队中非常普遍，他们实施测试来验证先前发现并修复的漏洞是否存在。这种类型的测试非常重要，因为在配置和卫生偏移等情况下，不安全的配置和系统状态可能会再次出现。回归测试有助于验证情况并非如此。

模糊测试

NIST 推荐的另一种软件验证方法是模糊或模糊测试，这是一种自动测试方法，通过向软件中注入无效、畸形或意外输入来识别缺陷和漏洞。一旦这些输入被注入系统，模糊测试工具就会观察系统的反应，如死机或泄露本不应该泄露的信息。开放式全球应用安全项目（OWASP）为希望了解更多信息的用户提供了一个全面的模糊页面，网址是 https://owasp.org/www-community/Fuzzing。

网络应用扫描

网络应用扫描通常被称为动态应用安全测试（DAST）或交互式应用安全测试（IAST），适用于软件提供网络服务的情况。这两种工具执行的活动与模糊测试类似，但它们都是针对网络应用程序执行的，因为它们都在寻找异常或故障。世界上最流行的网络应用扫描工具是 OWASP Zed Attack Proxy (ZAP；(www.zaproxy.org))。

检查随附的软件组件

NIST 最后建议的开发人员测试清单最低标准是检查包含的软件组件。NIST 指出，这项活动的目标是确保所包含的代码至少与本地开发的代码一样安全。正如我们在本书中所讨论的，软件组成分析（SCA）等工具可以帮助识别软件正在使用的开放源码软件库、软件包和依赖项。这些工具可查询漏洞数据库，如 NIST 的国家漏洞数据库 (NVD)，以查找这些组件中的已知漏洞。鉴于大多数现代软件都是由开放源码软件组件组成的，因此这项工作尤为重要。 NIST 还提供了有关我们讨论的所有技术的其他背景和补充信息，如果您想了解有关此类测试技术的更多详情以及如何成功实施这些技术，这些信息值得您深入了解。

第八章现有和新兴政府指南

8.3 NIST 的安全软件开发框架

正如本书的几个部分所讨论的那样，网络安全行政命令 (EO) 14028 对零信任、云计算以及软件供应链安全等领域产生了广泛影响。作为网络安全行政命令的一部分，政府必须“只购买安全开发的软件”。行政命令指示 NIST 发布指南，确定增强软件供应链安全性的做法。NIST 正是这么做的。与业界合作，NIST 发布了安全软件开发框架 (SSDF) 版本 1.1，以及其他软件供应链安全指南。本节深入讨论了 SSDF、它是什么以及它为什么重要。

SSDF 指出，很少有 SDLC 模型明确解决软件安全问题。谈到网络安全，业内许多人都熟悉的一个常用短语是“固定的，而不是固定的”。网络安全通常是数字系统开发中的事后考虑，通常在 SDLC 的后期解决，而不是更早，因为安全最佳实践和要求可以从一开始就集成到软件和系统中。值得注意的是，2022 年发布的 SSDF 1.1 版建立在 2020 年 4 月的原始 SSDF 版本之上。为了促进 SSDF 的更新，NIST 与来自公共和私营部门的参与者举行了一个研讨会，并收到了 150 多份立场文件，供 SSDF 更新考虑。

SSDF 的目标受众包括软件生产商（例如产品供应商、政府软件开发商和内部开发团队）和软件采购方或消费者。虽然 SSDF 是专门为联邦机构使用而创建的，但它包含的最佳实践和任务适用于所有行业的软件开发团队，并且可以被许多不同的组织使用。还值得注意的是，SSDF 不是规定性的，而是描述性的；它没有具体说明如何实施每项实践，而是侧重于安全软件成果，并允许组织实施实践以促进这些成果。这是合乎逻辑的，因为保护软件的方法无穷无尽，而且每个生产和使用软件的组织都有独特的人员、流程和技术。该指南还澄清，在确定使用哪些实践以及为实现上述实践而投入的资源时，应考虑组织的风险承受能力等因素。

NIST 为从生产商和供应商处采购软件或包含软件的产品的联邦机构制定了最低建议。这些建议包括几项关键条款，有助于确保政府不会采购不安全的软件和产品。在机构采购软件时，NIST 建议他们使用 SSDF 术语或有关安全软件开发要求的沟通方式。NIST 还建议供应商在整个 SDLC 期间证明 SSDF 开发实践。一个经常引起争议的话题是证明，即某事的证据或证明。通常，从流程角度来看，证明可以由亲自完成，也称为自我证明，也可以由独立的第三方（例如第三方评估组织 (3PAO)）完成。

使用 3PAO 增加了认证的保证，因为它是由理论上的第三方而不是被评估方进行的。也就是说，3PAO 合规制度在时间和成本方面也会带来额外的开销，以配合其潜在的严格性。例如，FedRAMP 是希望在联邦市场提供服务的云服务提供商 (CSP) 的授权流程，要求 CSP 接受第三方评估。然而，截至本文撰写时，尽管该计划已经存在 10 年，但只有大约 250 个 FedRAMP 授权的云服务产品。如果在 SSDF 下对软件生产商采取 3PAO 方法，它无疑会在限制获准向政府销售软件的合格供应商数量方面产生类似的影响。

然而，NIST 在其指导意见中指出，根据机构和软件消费者的风险承受能力，在某些情况下可能需要第三方认证。批评者敦促政府机构不要采取这种方法，因为这会对 SSDF 的采用产生影响，并指出了其他类似计划延迟的例子，例如国防部的网络安全成熟度模型认证 (CMMC)，该计划经历了几次挫折 (https://insidedefense.com/daily-news/delay-publicly-releasing-cmmc-process guide-attributed-potential-national-security)，其中一些与为新合规认证实施 3PAO 流程的复杂性有关

SSDF 详情

如前所述，NIST SSDF 旨在倡导使用基本的、公认的安全软件开发最佳实践。SSDF 的独特之处在于，它没有完全从零开始创建指南，而是使用了许多已知的、已实施的既定指南来源，如 Synopsys 的 "成熟度模型中的构建安全性"（BSIMM）和 OWASP 的 "软件保证成熟度模型"（SAMM）等。

SSDF 稳健的安全软件开发实践分为四组：

准备组织 (PO)
保护软件 (PS)
制作安全可靠的软件 (PW)
应对漏洞 (RV)

在这些实践中，有定义实践的元素，如实践、任务、名义实施示例和参考（将实践映射到任务）。如前所述，SSDF 的最新版本涉及《网络安全电子法令》的要求，因此还包括与《电子法令》第 4e 条具体要求的映射。使用 SSDF 实践的预期目标是减少软件发布中包含的漏洞数量，以及这些漏洞在未被发现或未被处理的情况下被利用的影响。

准备组织 (PO)

对于任何希望开发安全软件的组织来说，为安全软件开发做好准备是合乎逻辑的第一步。这组实践包括定义软件开发的安全要求，其中包括对组织软件开发基础架构的要求以及组织开发的软件必须满足的安全要求。当然，这些要求也必须传达给所有向组织提供商业软件组件以供重用的第三方。

定义角色和职责是组织必须采取的另一个基本步骤。它包括 SDLC 所有环节的角色，并为担任这些角色的人员提供适当的培训。指南强调，需要获得上层管理人员或授权官员对安全开发的承诺，并确保参与流程的个人了解这一承诺。这通常被称为 "行政买入"。

现代软件交付涉及到支持工具链，这些工具链利用自动化最大程度地减少了与软件开发相关的人力，并带来了更加一致、准确和可重现的结果。这方面的任务包括指定必须用于降低风险的工具和工具类型，以及它们如何相互集成。各组织还应定义使用工具链的推荐安全实践，并确保正确配置工具以支持安全软件开发实践。

各组织还应定义和使用软件安全检查标准。这包括实施流程和工具，在整个 SDLC 过程中保护信息安全。工具链可用于自动为安全决策提供信息，并生成有关漏洞管理的指标。

最后，组织应为软件开发提供安全的环境。这通常表现为创建不同的环境，如开发、测试、暂存和生产环境。这些环境被分割开来，以限制危害影响其他环境的爆炸半径，并根据不同的环境满足不同的安全要求，同时改进配置管理，控制配置漂移，即实际配置与期望配置不一致的情况。

可以通过 MFA、有条件访问控制或最小许可访问控制等方法来保护这些环境，并确保记录和监控各种开发环境中的所有活动，以便更好地检测、响应和恢复。确保环境安全还意味着对开发人员和其他与环境交互的人员所使用的端点进行加固，以确保它们不会带来风险。您会发现，这些建议与当前的零信任指导和最佳实践有几处相似之处。

保护软件 (PS)

在保护组织的基础上，还要保护软件（PS）本身。这一组的做法包括保护代码免遭未经授权的更改、验证代码的完整性以及保护每个软件版本。

保护所有形式的代码免遭未经授权的更改和篡改，对于确保代码不会被有意或无意地修改而损害其完整性至关重要。代码应根据其安全要求，采用符合最小许可访问控制的方法进行存储，这与开放源码软件代码或专有代码不同。企业可以采取一些措施，如使用支持版本控制和提交签名的代码库，并由代码所有者和维护者进行审查，以防止未经授权的更改和篡改。还可以使用加密哈希值等方法对代码进行签名，以确保其完整性。

不仅需要维护代码的完整性，还必须为软件消费者提供验证这种完整性的方法。这就是在安全良好的网站上发布哈希值等做法的作用所在。代码签名应得到可信证书颁发机构的支持，软件用户可将其作为签名的保证或信任措施。

最后，每个软件版本都应得到保护和保存。它还有助于回滚软件和应用程序（在版本被破坏的情况下）并恢复到 "已知良好 "状态。保护和保存软件版本可以让消费者了解代码的出处以及代码出处的相关完整性。

制作安全可靠的软件 (PW)

既然需求已经编纂，开发环境和访问这些环境的端点已经解决，组织就可以专注于生产安全可靠的软件。这并不是说这些实践不会在组织或项目的整个生命周期中同时进行，但它们确实是相互依存的，同时也需要在必要时重新审视和修订。

您会注意到，在 SSDF 的 PO 部分，已定义并记录了安全要求。现在，软件的设计必须满足这些安全要求。这时，组织可以使用威胁建模和攻击面映射等风险建模方法来评估所开发软件的安全风险。企业可以对开发团队进行威胁建模等方法的培训，以提高开发团队的能力，使其能够了解所开发系统和软件面临的威胁以及降低这些风险的措施。通过使用数据分类方法，企业可以优先对高敏感性和高风险领域进行更严格的评估，以降低风险并采取补救措施。组织还应定期审查软件设计，确保其符合组织定义的安全和合规要求。这不仅包括内部开发的软件，还包括从第三方采购或使用的软件。根据所使用软件的性质，组织或许可以与软件设计者合作，纠正不符合安全要求的情况，但这不适用于开放源码软件等情况，因为这些软件没有合同或相关协议（如服务水平协议）。

我们鼓励各组织重复使用现有的、安全可靠的软件，而不是重复功能。这种重复使用有很多好处，如降低开发成本、加快能力交付、减少在环境中引入新漏洞的可能性。大型企业组织普遍存在代码蔓延的问题，即代码无节制地增长，尤其是在 "代码化 "时代，云原生环境中的基础设施甚至安全都可以定义为代码。这种 "作为代码 "的方法支持模块化、重用、配置即代码、加固代码模板和清单等概念，这些概念可以安全地用于组织内的其他地方，甚至更多地方。尽管如此，正如第 6 章 "云和容器化 "中讨论的 Palo Alto Unit 42 研究中提到的，如果这些清单和代码模板包含漏洞，它们现在也会被大规模复制，因此需要适当的治理和严格的安全性。

重用现有软件和代码的组织，甚至是组织内的团队，应确保审查和评估代码的安全性和错误配置问题，并了解与重用代码相关的出处信息。SSDF 提出的一项类似建议是，在内部创建并维护安全性能良好的软件组件和存储库，以供开发人员重复使用，这与 NIST 800-161r1 提出的建议如出一辙。

组织创建的源代码应符合组织采用的安全编码实践和行业指导所倡导的安全编码实践。这些实践包括验证所有输入、避免不安全的函数和调用，以及使用工具识别代码中的漏洞等步骤。

应对漏洞 (RV)

虽然企业可能已经定义了安全要求，准备好了环境，甚至努力制作安全软件，但漏洞还是不可避免地会出现。现实情况是，在开发过程中识别所有漏洞是根本不可能的，而且随着时间的推移，漏洞还会被发现。正如我们所讨论的，软件存在的时间越长，漏洞就越有可能被研究人员、恶意行为者和/或其他人发现。

各组织应不断努力识别和确认漏洞。这包括监控漏洞数据库、使用威胁情报馈送，以及自动审查所有软件组件以识别任何新漏洞。这些做法非常关键，因为在最初扫描和检查代码时，难免会出现新的漏洞。企业还应制定以漏洞披露和修复为中心的政策，并如前所述，定义必要的角色和责任，以便在漏洞出现时加以解决。关于漏洞披露，团队通常会努力建立产品安全事故响应团队（PSIRT），我们将在第 10 章 "供应商实用指南 "中对此进行深入讨论。

组织不仅需要识别和确认漏洞的方法，还需要根据漏洞带来的风险进行补救。这意味着要有一套评估、优先处理和修复软件漏洞的流程。利用工具和管理，企业就可以在了解风险的情况下做出决策，如补救、接受，在某些情况下还可以转移风险。生产软件的组织还需要有既定的方法来开发并向软件消费者发布安全公告，帮助他们了解软件的漏洞和对消费者的潜在影响，以及在可能的情况下解决漏洞所需的步骤。

最后，组织应采取措施，通过分析找出漏洞的根本原因，这有助于通过解决根本原因，而不仅仅是单个漏洞，来减少今后出现漏洞的频率。

从所讨论的大量安全软件开发任务和实践中可以看出，任何具有相当规模的组织都不可能总是有能力正确地完成所有这些实践。尽管如此，企业仍可采取措施，将 SSDF 作为指南，编纂其安全软件开发实践，并帮助确保在整个 SDLC 过程中采取适当步骤确保软件的安全。

第九章运营技术中的软件透明度

运营技术（OT）运行着世界上最关键的流程，从导弹平台和防御任务，到水处理厂和电力，再到关键制造、机场等。通常，这些环境使用气隙隔离网络高度隔离，并且可能有限制外部连接、云或移动功能。正因为如此，我们依赖软件验证的许多技术在这里可能没有用。例如，当无法访问互联网时，如何验证代码签名证书的证书吊销列表（CRL）与已签名的固件更新之间的匹配程度？如果它与已知的恶意软件存储库条目匹配，那么如何在软件材料清单（SBOM）中查找和识别组件哈希？当无法轻松更新信任信息时，您是否仍然认为传输层安全性（TLS）证书的过期日期过长是一个问题？此外，在考虑有关国家敌对势力的问题时，这些产品可能是在我们视为敌对的世界地区内制造或由这些地区的业务支持的。软件来源的问题尤其具有挑战性，因为《国防授权法案》（NDAA）和各项行政命令的合规要求都在寻求收回允许向关键基础设施供应产品的国家。例如，在2020年，第13920号行政命令《美国成批电力系统安全》发布，解决了从美国电网竞争对手采购方面的问题。这一命令之后又颁布了一项禁令，禁止从中华人民共和国采购用于电网的设备。这些命令后来已被撤销，并现在归属于《行政命令14017号，保护美国供应链》。尽管如此，可以明确的是，制定关于关键基础设施和国防供应链风险管理政策仍然是国家的优先任务。《行政命令14028号》促使了围绕软件透明度的大量活动，包括SBOM（软件构建材料清单）和软件标签等内容，这些内容设计三个主要利益相关者，其中之一是国家电信和信息管理局（NTIA）负责定义SBOM的属性。此任务和其他任务，例如漏洞可利用性交换（VEX）格式的定义，自那时起已转移到网络安全和基础设施安全局（CISA），其主要任务是保护关键基础设施。很明显，在可预见的未来，操作技术环境将继续处于美国软件透明运动的前列。

第九章运营技术中的软件透明度

9.1软件的动力学效应

EO 14028最引人注目的举措之一就是采取行动来界定“关键软件”。正如我们之前讨论过的，这些定义可能很难搞清楚。有人可能会认为所有的软件都有潜力成为关键软件，关键在于如何使用它。我们过去使用的一个例子是用于在互联网上显示可爱小猫图片或视频的图像渲染库。很少有人会认为这是关键软件。但是如果同样的库被用来渲染电力环境中的遥测数据呢？那就完全是另一种情况了。同一款软件，不同的使用方式，其关键性完全不同。
一个让许多从业者感到好奇的OT方面是这些系统能够超越其传统的虚拟边界，对现实世界产生实质性的影响。软件控制着保持监狱紧闭的门闸，维护消毒您饮用水的化学混合物，操作电力网，甚至运行军事防御系统的动能部分。如果那个渲染小猫图片的库被用于导弹定位系统，并且士兵的生命依赖于它，那么它也可以被认为是极其关键的。在OT领域中，软件缺陷可能导致人员生命的损失，其潜在后果是灾难性的。
在过去几年中，有多份报告称勒索软件造成医院护理延误，2020 年在德国，有报道称一名患者的死亡是由勒索软件造成的。一名病人的死亡就是由勒索软件造成的。虽然这在很大程度上没有得到证实，但皮尤慈善信托基金会（Pew Charitable Trusts）等机构的研究清楚地表明，这些事件有可能造成人员伤亡。随着我们这个由软件控制的社会和远程医疗系统为加强医疗服务创造了机会，在为我们提供了新的机遇的同时，也为攻击者提供了新的机会。
对电力网络的攻击也在增加。我们亲眼见证了俄罗斯等国家如何利用网络和动能攻击的组合策略来摧毁一个国家。例如，通过剥夺其提供安全饮用水或电力的能力，整个国家公民的健康可能会受到威胁。一个国家的战争机器，从港口、铁路、电力、水和其他附属设备，都会产生一种网络效应，使得网络破坏对于对手极具吸引力。除此之外，还有什么能从世界各地制造物理破坏？
Stuxnet 攻击可能是通过软件实现动能结果的最佳实例之一。虽然分析表明最初的攻击是由一个受感染的 USB 驱动器发起的，但恶意软件却导致了伊朗核浓缩能力的大规模延迟。一些专业人士指出，这可能导致了984台离心机的运行受阻，伊朗的核计划可能受到长达两年的发展挫折。
对 Stuxnet 攻击进行最透彻分析的可能是由Langner公司进行的。该公司是一家工业控制系统（ICS）资产管理公司，长期以来在 ICS 安全领域拥有深厚的专业知识。他们在2013年发布了题为“To Kill a Centrifuge”的论文(www.langner.com/wp-content/uploads/2017/03/to-kill-a-centrifuge.pdf），并在2017年进行了更新。该论文描述了这次袭击最终是如何实施的，以及这对伊朗的核浓缩计划以及其他行业意味着什么，特别是在我们希望防止未来针对关键基础设施的攻击的背景下。
Stuxnet被设计用来降低离心机的效率。虽然感染发生在多个地点，但人们普遍认为Natanz铀浓缩设施是最初的目标。在2010年夏季，人们发现离心机出现异常数量的故障，但并没有引起过多的怀疑。显然，这里的技术水平设计得相当微妙，因为它同样可以轻易地被设计成直接摧毁离心机。
据推测，初始感染是通过感染Windows机器实现的，很可能是控制工程师用来编程和管理西门子软件和设备的移动设备。该恶意软件直到若干年后利用了几个零日漏洞，才被反病毒软件供应商识别为恶意软件。它在初始感染时并没有传输网络，因此，分析网络流量和依靠反恶意软件解决方案来防止传播的传统措施在很大程度上是无效的。
然而，更值得注意的是，除了使用传统方法检测和预防感染所面临的挑战之外，恶意软件的设计逻辑是隐蔽地降低压力系统转子的性能，并最终使其变得脆弱。通过交替使用慢速和快速周期，它突破了系统设计的极限，测试了系统的物理限制。这种逻辑行为的变化表明，合理的代码变化如何能给系统带来重大影响

第九章运营技术中的软件透明度

9.2遗留软件风险

同样，正如我们之前所讨论的，这些软件中的很多都非常陈旧在验证传统产品时也会遇到类似的挑战。OT 系统的一个主要特点是需要有弹性。著名的 ICS 安全专家丹尼尔-艾伦瑞克（Daniel Ehrenreich）所说的那样，这些环境都是有关安全性、可靠性和生产率，而不是保密性、完整性和可用性。
那么，我们如何实现这些目标呢？我们主要通过详尽的工程设计与极强的安全工程文化相匹配、在这种情况下，系统特性会根据安全影响进行威胁建模。一些安全标准标准如 ISA84 (www.isa.org/technical-topics/safety) 等标准在这些环境中得到了广泛应用，作为设计驱动力，安全比网络安全更为普遍。对于关键基础设施公司来说，每次会议都从进行“安全时刻”练习开始，以引导员工思考安全问题，戴安全帽和防护装备是常规操作，没有其他选择的余地。此外，这些环境往往是静态的，因为变化意味着风险。一旦工程师进行了工厂验收测试（FAT）以确保系统按设计运行，并进行了现场验收测试（SAT）以对安全性和控制进行评估，系统基本上就被认为是 "锁定更改 "的，这意味着不应再进行任何更改。通常会发生一些常规变更，比如对可编程逻辑控制器（PLC）进行轻微的调整，一些非关键或冗余系统可能会进行补丁更新，新的作业可能会排队等待处理，但通常不会发生重大变更。
虽然这限制了引入安全控制的能力，但也降低了通过计划变更而导致供应链受损的可能性。缺乏变更的组合，以及可能并非真正隔离或“空气隔离”的环境感知，有时可能会导致一种虚假的安全感。但是，在有计划的变更之前，减少变更事件确实可以降低依赖性混淆攻击对 OT 系统造成影响的可能性。另一个复杂因素是，对于真正的空中封闭系统或没有互联网接入的站点，验证软件的真实性和安全性可能具有挑战性。普遍情况是，软件是通过工程师的笔记本电脑进入设备的，而不是从可信网站下载的。在一些情况下，如核设施，常常需要基于亭式终端的反恶意软件扫描能力，但正如我们在Stuxnet案例中看到的，这可能不是一种有效的方法。
尽管缺乏变更，但早在2000年代初期，传统思维认为OT系统如此复杂和专有，外界无人知晓其工作原理，攻击工具寥寥无几，文档资料几乎不存在，无法帮助对手攻击可能存在的数千种的潜在 ICS 协议。随着 OT 协议栈日益数字化和标准化，以及互联网社区内的信息共享互联网社区内的信息共享降低了这种 "隐蔽安全 "的价值。例如在Metasploit等框架中存在稳定的漏洞利用和攻击工具，或是定期举办针对ICS的黑客竞赛，如在迈阿密海滩举行的年度S4 ICS安全会议的Pwn2Own比赛，以及许多其他类似的活动。
形势正在发生变化，保护软件安全的新方法在很大程度上忽略了传统软件领域。大多数软件供应链安全解决方案都应用于软件即服务（SaaS）、容器和现代软件开发框架，但在解决遗留软件问题上，除了专注于ICS固件漏洞发现的逆向工程工具外，很少有人对解决遗留软件问题感兴趣。因此，我们面临的挑战就变成了如何为终止支持的产品--即供应商已不再经营的产品，解决这些问题？通常的选择要么是花大笔资金进行翻新和替换，要么是应用虚拟补丁或缓解控制措施，并希望我们已经在所有正确的地方减少了攻击面。

第九章运营技术中的软件透明度

9.3控制系统中的梯形逻辑和设定点

可编程逻辑控制器 (PLC)、远程终端装置 (RTU) 和类似的 OT 设备可运行基本的自动化程序。通常使用梯形逻辑、功能块图或其他方法进行编程。它们描述了一系列输入和输出，包括用于决策的逻辑或参数。这些程序可能仅仅是简单的开关控制，也可能包括条件逻辑，例如使用诸如温度、每分钟转数、电压、压力或其他传感器输入作为逻辑条件的辅助输入。这个程序通常会定义一系列可接受的数值范围，设定点的概念用于确定正常（或异常）的状态。
讨论动能软件效应时，值得注意的是讨论漏洞的定义。我们是否需要利用漏洞或 Metasploit 模块来造成破坏？如果一个简单的数据完整性条件就能引发灾难性影响呢？我们不需要 "常见漏洞和暴露"（CVE）、但也许我们可以操纵传感器数据，使其报告错误情况。或者，我们可以操纵定义正常值的设定点。如果我们知道超压事件的故障条件是每平方英寸 500 磅（PSI），而设定点安全地低于 350 PSI，但未经授权的更改却将设定点修改为 1,000 PSI，这可能比 Log4Shell 漏洞利用导致锅炉爆炸的后果更为灾难性。
可编程逻辑控制器 (PLC) 通常包括基本的安全机制，如物理按键，用于确定设备是处于运行状态还是程序状态，以便进行更改。例如，影响施耐德电气 Triconex 安全仪表系统的 Trisis 恶意软件众所周知的首次针对安全系统的攻击之一。这种攻击的部分原因是设备被设置为程序模式，因此可以进行更改，另一部分原因是组织没有完全理解正常状态是什么样的，因此忽略了故障。但作者们也见过固件更改可以实施到许多OT设备上，绕过物理键来进行编程控制的情况。虽然最佳做法是保持设备处于运行状态，但这并不能保证将来供应链中固件的联合受损不会促成类似的攻击。
在Triton案例中，攻击是通过多阶段活动交付的，这一情况由爱达荷国家实验室的运营技术环境网络安全（CyOTE）记录和文档化。CyOTE旨在处理可观察指标的分类方法，并根据这些指标采取行动。在他们对Triton的案例研究中，CyOTE建立了以下事件链：
步骤 1-IT 网络入侵：这一步骤是通过允许访问 IT 网络的配置不当的防火墙实现的。
步骤 2--从 IT 网络转向 OT 网络：工程工作站在 OT 网络内的工程工作站被入侵，并部署了有效载荷、模仿合法的 Triconex 应用程序 trilog.exe。
步骤 3-OT 攻击能力开发：攻击者随后建立控制点，确定进一步攻击的目标系统、包括确定目标安全仪表系统 (SIS) 的运行状态。
步骤 4-OT 攻击能力传送：未经授权的代码多次传输到 Triconex 设备，先是测试，然后最终注入恶意 shellcode 和新的梯形图逻辑，从而改变设备的行为。
步骤 5-支持攻击-隐藏：利用规避检测的机制，恶意软件禁用了随机存取存储器/只读存储器（RAM/ROM）检查，并且只针对处于程序模式的设备进行攻击。这种攻击发生在感染修改固件后，允许即使在运行状态下也能执行恶意指令的情况下。
步骤 6-OT 攻击的执行和影响：最终结果是系统安全控制完全被禁用，根据程序逻辑可以选择是否禁用这些控制。
虽然这次攻击采用了首先侵入信息技术（IT）再渗透到运营技术（OT）的传统方法，但是这与我们所见过的大量软件供应链攻击无异，都是固件和代码验证的缺失为这次攻击提供了便利。作者认为这是一个具有里程碑意义的案例，展示了软件和固件验证不足如何可能导致下游的安全影响，甚至可能导致人员伤亡。从这个案例中还可以得到许多其他启示，例如需要适当的分段、有效的监控和基线环境来进行异常检测和事件响应。但是，如果产品要求执行已签名的二进制文件，那么就很有可能避免这次攻击。

第九章运营技术中的软件透明度

9.4 ICS攻击面

如前所述，与企业 IT 相比，ICS 的攻击面通常最小。大多数环境都被严格分割，能源部在《2020财年国防授权法案》第5726条的指导下，通过安全能源基础设施执行任务组（Security Energy Infrastructure Executive Task Force）赞助了一项研究。这项工作产生了一系列参考架构，包括根据场地类型规定的电力推荐分割策略，其中一个例子见图 9.1。
此外，来自北美电力可靠性公司（NERC）关键基础设施保护（CIP）监管标准的建议，管理着北美大规模电力系统，并根据国际电工委员会（IEC）62443系列标准的要求，规定了分割方法，为了保护OT系统免受直接暴露于这些网络和不受这些网络所不信任的企业IT环境的侵害。
仍有成千上万的 ICS 资产暴露在互联网上，其中许多验证薄弱或根本没有验证措施。流行的攻击面浏览器网站 Shodan 有一整个页面专门用于识别这些系统(www.shodan.io/explore/category/industrial-control-systems）。从这个网站上可以看到，即使搜索特定的 ICS 产品，也会有成千上万的结果、其中很多都存在漏洞，并被用于关键流程中。随着对未连接到互联网的资产进行细分，这对关键基础设施组织意味着什么？许多攻击仍然是通过钓鱼或其他手段从对企业IT网络的一次初始入侵中扩散并随后转移的。但如果这些环境真正是隔离的，那么企业就有必要研究软件是如何通过承包商将软件引入环境，承包商可能会通过引入来自供应商的外国通用串行总线（USB）密钥或通过供应商发送的固件更新CD-ROM来进行操作。这些载体往往与物理安全紧密相连，因此必须采取整体战略控制可以引入的软件。同样，产品供应商也需要为操作员提供机制，以便在无法使用在线方法时进行离线验证的机制。

第九章运营技术中的软件透明度

9.5 智能电网

智能电网是传统电网的现代化、数字化版本，它使用先进技术来提高电力系统的效率、可靠性和灵活性。它使用传感器、通信网络和控制体系来监测和控制电力的流动，从而实现可再生能源的整合和需求管理。这使得分布式能源（DERs）如太阳能和风能得到更广泛的应用，并实施需求响应计划来在高峰时段管理能源使用。
随着拜登政府在可再生能源和基础设施改善方面做出努力，分布式能源资源（DER）正在迅速成为热门话题，因为未来几年将有数十亿美元投资于可再生能源电网。这些系统是小型能源生成和储存系统，例如屋顶太阳能电池板和像NextEra能源公司那样的大型太阳能农场，风力涡轮机和电池储存系统，它们与电网在分配层面连接。智能电网通过在电网和这些分布式资源之间实现实时通信和控制来实现这些DER的整合。这种日益增加的连通性与传统上断开和隔离的电网基础设施形成鲜明对比，这些设备在现场暴露的风险为电网运营商带来了新的网络安全挑战。
分布式能源（DER）中的逆变器技术，如太阳能电池板和风力涡轮机，正在成为智能电网中越来越重要的组成部分。这些技术将分布式能源产生的直流（DC）电力转换成电网可以使用的交流（AC）电力，并且还可以提供电压和频率控制等电网服务。逆变器和其他DER控制系统都连接到互联网上，可以被远程控制和监控。这可能会增加攻击面，为网络攻击创造潜在的漏洞。
除了分布式能源资源（DER），先进计量基础设施（AMI）被用于测量和实时向公用事业和消费者传达有关能源使用情况的详细信息，这使得更准确的计费和需求响应计划的实施成为可能。此外，先进的分析和机器学习算法被用于分析智能电网产生的海量数据，以检测模式、预测设备故障和优化电网的运行。
这种复杂性的增加带来了在检测到风险条件时动态纠正的新能力，但同时也为软件引入灾难性后果带来了新的机会。针对问题的预警时间可能会更短，特别是由于分布式能源资源具有与天气相关的特性，以及针对电池容量和放电等新攻击模式，这可能会在电网运营商未做好准备时造成能源短缺。这就是基于逻辑的攻击可能会成为寻求影响我们今天正在设计的新型和改进电网的对手的新常态的原因。
随着这种复杂性的出现，我们需要技术标准化。IEC 61850是一项国际标准，它定义了电力系统变电站自动化系统中的通信协议和数据模型。它为智能电网发挥着关键作用，为构成电网的不同设备和系统之间提供了一种通用语言和框架，进行相互通信。IEC 61850的主要好处之一是，它能够集成不同供应商的设备和系统，从而能够更高效、更经济地部署智能电网技术。IEC 61850还为不同设备和系统提供一个共同的数据模型，这使得在不同系统之间交换信息以及对收集到的数据进行高级分析变得更加容易。
当我们开始考虑构成智能电网的物联网设备的扩散时，我们的安全状况可能会开始看起来很像典型的物联网攻击表面。Gonda Lamberink在2021年的一篇文章中探讨了与物联网相关的供应链风险表面，特别是智能电网的供应链风险表面（www.power-grid.com/executive-insight/securing-smart-grid-supply-chains-with-a-zero-trust-mindset）。
在文章中，Lamberink呼吁采用零信任思维模式来降低智能电网的风险，这一点特别有趣，因为在传统的电网中，隐含的信任是常见的。大多数系统没有身份验证，没有加密通信，要求零到低延迟的网络收敛时间，而传统安全技术无法跟上。智能电网的暴露程度增加意味着传统的封闭式花园方法无法保护这一基础设施。
此外，当我们考虑与这些环境相一致的标准框架时，传统的NERC CIP和IEC 62443标准仍然适用，但许多人也在寻求NIST和其他机构的更传统的物联网框架。

第九章运营技术中的软件透明度

9.6 总结

在这一章中，我们讨论了软件的行为效应以及可能对社会产生的物理影响。我们也涉及到了与工业控制系统中的遗留软件和梯形逻辑相关的风险。我们进一步探讨了工业控制系统攻击面的性质及其对关键基础设施、国防和社会的风险，以及智能电网所发挥的作用。在接下来的章节中，我们将讨论软件供应商和消费者的一些实用指南。

第十章供应商实务指南

虽然我们已经讨论了许多来自私营和公共部门组织的新兴行业指导来源，但接下来的几章将努力为供应商和消费者提供一些实用的指导。这将包括来自我们讨论的来源的指导的综合，以及基于作者专业经验的行业最佳实践和建议。并非所有的建议、最佳实践和流程都适用于所有供应商。就像软件消费者的多样化生态系统一样，软件供应商在资源、专业知识和限制方面存在着不同的程度。根据行业、业务关系、监管要求和合同方面的情况，软件消费者和供应商之间往往存在着二分法，来达成关于何时、如何以及在什么情况下实施、提供或披露的问题。

第十章供应商实务指南

10.1 漏洞披露和响应 PSIRT

如前所述，SSDF 呼吁各组织实施合理的实践，以帮助实现安全的软件开发。它将这些实践分为四组：组织准备、保护软件、生产安全可靠的软件和应对漏洞。这四组中的一个关键主题是组织和供应商披露和应对影响消费者的漏洞的能力。这一点在一些方面得到了强调，例如制定政策来处理漏洞披露和修复活动。制定这些政策和流程可为软件供应商带来若干重要益处，例如能够向研究人员通报其漏洞管理实践，并向供应商报告他们可能发现的潜在漏洞。

长期从事网络安全或软件开发工作的人都知道，漏洞不是会不会出现的问题，而是何时出现的问题。因此，企业在向软件消费者披露漏洞时，关键是要有成文的安全响应流程和成熟的能力。传统的做法是通过网站、电子邮件和 PDF 文档等静态通知措施进行披露。然而，正如我们在本文其他部分所讨论的，该行业目前正朝着机器可读自动通知公告的方向发展。这主要体现在通用安全咨询框架（CSAF）和漏洞可利用性交换（VEX）等途径上，许多人认为 VEX 是 SBOM 的配套文件，它将显示与供应商的软件和产品相关的漏洞的实际可利用性。CSAF 的目标是让利益相关者自动创建和使用安全漏洞信息，并努力支持 VEX，尽管截至本文撰写之时，该功能仍在不断成熟。另一个值得注意的例子是 CycloneDX，这是我们讨论过的业界领先的 SBOM 格式，它也有一个被称为 "漏洞清单 "的东西（https://cyclonedx .org/capabilities/bov），允许在系统和漏洞情报来源之间共享漏洞数据。

CSAF 和 VEX 等方法和标准的出现表明，行业正不断从传统的静态漏洞咨询和通知流程向机器可读性和自动化流程转变，从而提高流程效率，减少出错率，并最终提高可扩展性。

制定漏洞披露计划（VDP）是软件供应商成熟的标志，可以建立与消费者之间的信任，同时使他们有能力了解正在发生的漏洞和事件，并采取补救措施，在被恶意行为者利用之前解决其环境中与产品相关的漏洞。在某些行业（如美国联邦部门），第三方软件供应商自我证明符合 SSDF 实践（如存在 VDP）也成为一项要求。

如果 VDP 能够及时响应安全研究人员的要求，并与消费者进行公开有效的沟通，就能建立起消费者的信任，并有助于降低供应商可能面临的财务风险，如不良行为的监管后果或声誉损害。虽然您可能会发现自己处于软件供应商的地位，但不可避免的现实是，您也可能是软件消费者，或者在向自己的下游消费者提供软件和产品时，在某种程度上使用第三方。这意味着您需要采取措施了解自己的供应链和供应商采取的安全措施。这可能会以证明和审查软件中使用的第三方软件组件的形式出现。如果是专有供应商，您可以使用合同措施来执行贵组织或下游消费者所要求的严格程度。如果组件是使用开放源码软件提供的，则需要实施开放源码软件治理，正如我们在其他地方讨论过的以及 NIST 等领导机构所建议的那样。如果做不到这一点，就会给下游消费者带来风险，并可能带来业务挑战，因为精明的消费者不可避免地会对传递给他们的不安全软件进行反击，他们会寻求了解贵公司的安全软件开发实践，或要求提供可能暴露产品或应用程序中风险的 SBOM 等工件。

第十章供应商实务指南

10.2 产品安全事件响应团队 PSIRT

另一项与 SSDF 和产品与软件供应商行业最佳实践相关的重要建议是建立产品安全事故响应小组（PSIRT）。PSIRT 类似于网络安全事件响应小组 (CSIRT)，但 PSIRT 并不是面向内部的，重点关注组织的基础设施和系统，而是以产品为重点，关注组织产品的漏洞和威胁。PSIRT 出现在 NIST SSDF 的 "漏洞响应"（RV）组中，并被列为一个实施示例，允许组织处理漏洞报告和事件的响应，并处理组织内部和外部利益相关者之间的沟通。

无论你是要组建新的 PSIRT 团队，还是要评估现有团队的成熟度以找出需要改进的差距，FIRST 的 PSIRT 成熟度文档都是一个很好的资源，FIRST 也是我们在其他章节中讨论过的 CVSS 和 EPSS 的领导机构 (www.first.org/ standards/frameworks/psirts/psirt_maturity_document)。FIRST 的 PSIRT 成熟度文档为 PSIRT 团队提供了三个成熟度级别，分别为基础级、中级和主动级（见图 10.1）。让我们简要了解一下每个成熟度级别，以了解每个级别的相关能力。

在深入研究 PSIRT 级别之前，最基本的步骤之一是创建 PSIRT 章程，该章程包含 PSIRT 的使命宣言、利益相关者、隶属关系/赞助组织和范围。

在基础级别，PSIRT可能只是刚刚建立并尝试获取功能的基础。这需要获得高管支持、确定利益相关者、预算和基础程序。这意味着PSIRT需要组织领导的支持；确定谁是利益相关者，包括内部和外部；并有预算用于初始人员配备和建立；并创建政策和流程以规范PSIRT将如何基本运作。

例子包括FIRST的文件中提供的政策和流程，提供了漏洞管理、信息处理和修复服务级别协议。除了这些，PSIRT还需要一些基本能力来满足其意图。这包括创建漏洞报告的能力，包括发布联系信息以及如何报告漏洞到组织的PSIRT。

接收漏洞报告只是第一步；接下来需要对漏洞报告进行分类和分析。这涉及关键步骤，如漏洞报告的验证，询问漏洞是否有效以及应接受还是拒绝。FIRST推荐PSIRT捕获关键漏洞信息并采用机器可读格式以提高效率和规模。资源包括通用漏洞报告框架（CVRF）、CSAF和通用漏洞和暴露（CVE）计划，最后一个由NIST的国家漏洞数据库（NVD）支持，并使漏洞通信能够通过消费者支持，如CVE扫描工具集成并查询NVD获取漏洞数据。

一旦PSIRT验证并接受漏洞，就需要进入漏洞分析阶段，这涉及了解漏洞如何运作，如何被利用，他们的产品和服务的哪些版本受到漏洞影响，以及漏洞利用的影响是什么。影响往往取决于环境和缓解控制措施是否存在，这通常会让消费者决定是否存在，由于他们对其操作环境的内在了解。

在分析期间，PSIRTs通常会执行优先级排序和评分。FIRST的文件推荐使用CVSS，这是合理的，鉴于他们与CVSS的关系，但正如我们在其他地方讨论过的那样，CVSS也有来自学术界和行业界的强烈批评。尽管有这些批评，CVSS在行业中得到了广泛采用，如果PSIRT选择另一种评分方法，如FIRST所述，他们可能仍需要解释该决定，因为消费者往往熟悉CVSS。

一旦漏洞得到验证和分析，供应商需要采取措施修复漏洞。修复可能涉及代码修复和产品补丁或提供指南给消费者，以减轻漏洞的风险，或者理论上选择不修复漏洞，无论如何，这基于PSIRT及其同行在供应商公司的成本效益分析。

最后，漏洞披露的基础成熟度级别涉及通知产品或服务的消费者关于漏洞。这种通知理想情况下伴随着如何修复漏洞或减轻它的指南，如果不存在代码修复或解决方案。FIRST还推荐感谢报告漏洞的安全研究人员或实体，并通过信用建立社区中的信任。

超越基础和基本成熟度级别，PSIRT将进阶到中级或中间级别。这是PSIRT开始提供更全面的服务，与组织内部和外部更多的利益相关者互动，并成熟现有的基本能力的地方。

如FIRST所述，中级PSIRTs拥有清晰的利益相关者理解、建立流程并优化其分析和响应漏洞的能力。中级PSIRTs还能够使用工具来改善其漏洞报告摄取和处理能力。FIRST推荐中级PSIRT理解发布的产品的组成部分，将这些数据捕获在产品清单或物料清单中，如果产品是软件中心的。

BOM的拥有不仅有助于软件组件的可见性和漏洞管理，还使组织能够了解需要与哪些第三方（如OSS项目）进行沟通。

FIRST的指南指出，更成熟的PSIRTs有更多的角色和责任来理解每个利益相关者在漏洞处理和分析活动中的角色，并开始与可能向PSIRT报告漏洞或缺陷的安全研究人员建立信任关系。这部分通过拥有功能性流程和工具，如票务系统来促进漏洞报告过程。

除CVSS和严重性评分外，PSIRTs通常会成熟并使用通用漏洞枚举（CWE）对漏洞进行标记。如我们在第3章“漏洞数据库和评分方法”中讨论的那样，CWE是由MITRE管理的系统，提供社区开发的软件和硬件弱点类型列表，允许漏洞的快速标记和分类。

中级PSIRTs还能够依赖先前的漏洞修复活动，避免从头开始，并有规范的流程来帮助漏洞修复活动，并最终漏洞披露。这意味着改进PSIRT与各方的合作关系作为披露的一部分，并推荐使用其多方漏洞协调和披露的指南和实践，以促进成熟的漏洞披露方法。

这一成熟度的一部分将涉及标准化的披露渠道、度量跟踪和迭代过程改进。FIRST还指出，PSIRT可能在实际公开披露之前提供客户通知。这是有道理的，因为一旦信息公开，不仅是防御者在看，恶意行为者也会试图在消费者修复漏洞之前利用它们。

最终，PSIRT理想地进阶到成熟度级别3，也称为高级。

通过查看图10.3可以快速了解，PSIRT现在已经建立了服务和能力的健壮组合，并且在基础能力上也在进步。这意味着漏洞报告摄取、分析和安全更新交付的流程得到了理解，并贯穿整个组织和其利益相关者。

先进PSIRTs与其他的一个最大区别是从反应性文化向主动性文化的转变。这意味着积极寻找产品中的漏洞或缺陷，向利益相关者过度沟通，并与产品工程团队紧密合作和协作。

成为先进的一部分包括执行基本要素，如与利益相关者建立强关系，提供和接收反馈，以优化PSIRT的功能和性能。这个积极改进过程与关键生产率指标（KPIs）和客户满意度等指标相关联。

保持DevSecOps的主题，FIRST提到另一个先进PSIRTs的标志是与开发团队的紧密集成和关系，以了解产品路线图和即将发布的功能。PSIRT还将优化其工具以处理漏洞摄取、分析和报告流程。PSIRT还积极影响组织产品和服务的整个软件开发生命周期，以确保漏洞分析和扫描是标准化的活动，嵌入到开发工作流程和生命周期中。

鉴于PSIRT不断与安全研究人员接触，有时与同一研究人员多次接触，他们开始理解漏洞报告的熟练程度和有效性，并基于此知识优先处理报告和升级。先进PSIRTs能够体现行业的“左移”理念，通过在产品开发生命周期的早期获取工程团队的反馈。这不仅包括漏洞的识别，还包括优先级排序和修复活动。

PSIRT还需要理解他们所处的生态系统，不仅是向消费者下游传递，还向其供应商上游传递。这种认识伴随着清晰和可操作的沟通和期望，覆盖软件供应链的各个方向。

最后，鉴于PSIRT处理漏洞和产品缺陷的能力，PSIRT可以开始教导他人。这可以体现在内部培训和关于产品安全和漏洞管理实践的沟通，优化PSIRT的性能以及他们支持的开发和产品团队的性能。这不仅改善了产品和PSIRT的运营，但也理想地导致更安全的产品供下游消费者使用，这是最终目标。

第十章供应商实务指南

10.3 分享还是不分享，多少才算太多？

在推动软件透明度的过程中，软件供应商可能会发现自己会问的一件事是，他们到底需要共享什么，或者他们是否应该共享这些数据。虽然每个组织的决策过程和分析看起来都不同，但有一点是明确的，由于软件供应链攻击的日益普遍，以及消费者和更广泛的行业对未知和潜在不安全软件消费风险的担忧，消费者、客户、政府机构和监管机构对软件透明度的推动正在继续增长。

决定供应商可能被要求或被迫分享什么的因素将受到无数因素的驱动，例如合同语言、消费者要求和适用的监管要求。一些消费者或行业尝试可能会要求或要求供应商提供第一方软件清单组件，而其他组件可能要求或请求在可行的范围内详尽地列出软件和产品中涉及的传递依赖关系。以 NTIA SBOM 最小元素报告为例，在深度方面，该报告指出，“SBOM 应包含所有主要（顶级）组件，并列出其所有传递依赖关系。至少，必须以足够详细的方式列出所有顶级依赖项，以便以递归方式查找传递依赖项。

显然，此要求仅适用于美国联邦生态系统中符合 NTIA 最低要素要求的实体，但它也可以作为有用的指南。需要注意的一点是，寻找传递依赖关系所涉及的工作量可能很大，因此供应商没有向消费者提供这种深度，就会给消费者留下负担，这当然是所有消费者的指数级增长，而不是由供应商直接完成，然后传达给他们的消费者群。除了在识别传递性依赖性时将工作留给消费者之外，仅向消费者提供顶级依赖关系会使他们对与传递依赖关系相关的漏洞和风险视而不见。正如 Endor Labs 的“依赖关系管理状态”报告中所讨论的，我们在其他章节中已经讨论过，该报告发现 95% 的易受攻击依赖关系是传递依赖关系。这意味着，如果 SBOM 未能包含传递依赖项，则大多数漏洞将无法传达或对消费者可见，而无需他们自己进行跑腿工作来识别它们。这不包括对依赖关系（无论是直接的还是传递的）是否可访问和利用的细致分析和细节，但它至少提供了与应用程序或产品相关的所有依赖关系及其漏洞的进一步上下文，而不仅仅是顶级细节。

提供 SBOM 的软件供应商的另一个关键考虑因素是他们提供的 SBOM 是否有用，是否包含足够丰富的元数据，使其对下游消费者有价值。帮助开展这项活动的一个早期新兴工具是 eBay （https:// github.com/eBay/sbom-scorecard）提供的 SBOM 记分卡项目。另一个新兴选项是 OWASP SCVS 项目中的一个项目，我们在第 6 章“云和容器化”中进行了讨论。虽然该项目仍在进行中，但它致力于帮助组织评估 BOM 是否符合组织策略、格式和分类。随着行业尝试继续采用 SBOM，此类工具以及 SBOM 记分卡将是必要的。正如我们所讨论的，SBOM 的深度、完整性和准确性目前各不相同，组织希望根据其组织或法规确保与其特定要求保持一致，以确保他们分发或使用的 SBOM 满足他们的需求（https://scvs.owasp.org/bom-maturity-model）。

此工具可用于确定一些关键条件，例如 SBOM 规范是否合规、是否提供有关其生成方式的信息以及与包关联的信息，例如具有 ID、许可信息和版本控制。

我们在第 4 章“软件物料清单的兴起”中讨论了 NTIA 定义的 SBOM 最小元素。这些最低要素对联邦软件供应商和消费者来说将是重要的，因为它很可能被要求与联邦证券法规中的最低要素要求保持一致。ntia-conformance-checker 是一个有用的工具，它可以验证 SBOM 文档是否具有 NTIA 定义的最小元素（https://github.com/spdx/ntia-conformance-checker）。

基于这两个工具，Chainguard 等组织通过其 Chainguard Labs 的努力，在 2022 年底研究了一组公开可用的 OSS SBOM，以确定它们的质量和内容，使用我们讨论过的工具（www.chainguard.dev/unchained/ are-sboms-any-good-preliminary-measurement-of-the-quality-of-open-source-project-sboms）。

虽然他们的研究发现，一些开放源码软件SBOM确实包含高质量的数据，但许多没有。没有一个符合 NTIA 的最低元素要求，其中很大一部分缺少软件包许可和版本信息。虽然这不是个好消息，但它也应该与SBOM的采用（包括发电、要求和质量）在整个行业中处于起步阶段的现实形成鲜明对比。然而，为供应商提供这些早期研究工作和工具是件好事，以了解现有的差距以及如何确保他们提供给下游消费者的 SBOM 是高质量和有用的。对软件组件清单、透明度和 SBOM 等努力的推动都围绕着数据展开。如果没有高质量的数据，供应商和消费者都将不知所措，因为没有足够的洞察力来做出风险知情的决策，并推动有助于加强软件供应链状态的组织成果。

第十章供应商实务指南

正如我们在第 5 章“软件透明度的挑战”中所讨论的，许可也是许多供应商关注的一个关键问题，特别是当它与开放源码软件及其应用的许可有关时。许多软件供应商可能关注的一种许可方法就是所谓的 Copyleft。Copyleft 在很大程度上被理解为一种使程序或软件自由的许可方法，并且要求程序的所有后续修改和扩展版本也是自由的。许可清单采用各种许可格式，最著名的是 GNU 通用公共许可（GNU GPL; www.gnu .org/licenses/copyleft.en.html）。

随着软件透明度的进一步推动，一些供应商可能会对侵犯版权的行为产生额外的担忧，包括违反 Copyleft 许可软件的行为。虽然供应商应采取措施确保他们目前没有违反许可证，但SBOM等指标的额外透明度将披露供应商产品和软件中的开放源码软件组件。许可的可见性不仅对供应商来说是显而易见的，而且对作为自由和开源软件（FOSS）项目主要维护者和贡献者的消费者来说也是显而易见的。版权所有者，如自由和开放源码软件项目的创建者和维护者，是可以根据感知到的侵犯版权的行为（如Copyleft）提起法律诉讼的实体。

供应商应确保采取额外措施来清点其软件组件的使用情况，并确保他们没有侵犯任何基于他们可能在其产品和软件中使用的FOSS软件的适用版权，以避免潜在的法律挑战和问题，以及道德问题。

如上一节所述，SBOM数据不足，包括缺乏许可信息，将使供应商无法完全了解其许可合规性。供应商需要确保他们了解其自由和开放源码软件的全部使用范围，以及其软件版本中涉及的任何组件的相关许可要求。

除了法律问题外，许可也是一个潜在的安全问题。鉴于大多数开放源码软件的自愿性质，许多维护者按原样提供他们的项目和代码。这意味着他们可能无法或不愿意解决下游消费者提出的问题。因此，使用开放源码软件的消费者和组织必须准备好分叉项目，并开始承担修复他们发现的问题或漏洞的责任，因为开放源码软件维护者没有责任或响应能力。许多业内人士仍然不明白这一点，而且经常看到对开放源码软件维护者施加不切实际的期望来解决问题或提供支持，而在大多数情况下，没有什么约束他们这样做。

虽然开放源码软件项目和组件的使用已经有了巨大的增长，但一些组织似乎误解了开放源码软件的动态。在软件供应链安全方面，大多数开放源码软件维护者不应被视为“供应商”。您的组织通常与他们没有业务或合同关系，并且您按原样使用他们的代码，对维护、更新或响应能力没有期望。因此，在其产品、应用程序和服务中使用 OSS 的组织需要了解其 OSS 的使用范围，并准备好在需要时对组件负责。

开放源码软件维护者Thomas Depierre在一篇题为“我不是供应商”（www.softwaremaxims.com/blog/not-a-supplier）的博客文章中很好地捕捉到了这种动态。Depierre指出，尽管自由和开放源码软件在数字经济中无处不在，但开放源码软件维护者不是传统意义上的“供应商”，下游消费者无法对他们提出任何要求。

第十章供应商实务指南

10.5 开源项目办公室

正如我们所讨论的，各种形状、规模和行业的组织都在拥抱开源软件（OSS）。金融、医疗和制造业，甚至国家安全，现在都使用OSS来支持其最关键的应用和活动。这包括软件供应商，他们通常使用OSS作为其产品和应用开发的一部分。

然而，这种广泛的采用带来了隐患：根据Sonatype的《软件供应链状态报告》，软件供应链攻击增加了近800%。随着OSS采用的快速增长，组织开始创建开源项目办公室（OSPO）来帮助规范OSS使用和贡献的策略，并促进与更广泛的OSS社区的合作。这些OSPO通常有关键责任，如培养OSS策略、领导其执行并促进整个企业使用OSS产品和服务（www.linuxfoundation.org/resources/open-source-guides/creating-an-open-source-program）。

随着组织继续采用和使用OSS，他们将从一开始实施OSPO中受益匪浅。OSPO可以帮助解决我们在前一部分讨论的一些问题，以及我们将要讨论的一些问题。

虽然供应商和企业消费者（他们通常进行自己的内部开发活动）都可以从OSPO中受益，但我们将从软件供应商的角度进行讨论，他们通常在其产品和软件中使用OSS（https://fossa.com/blog/building-open-source-program-office-ospo）。

OSPO在领导OSS管理和策略方面的独特地位使其成为组织在OSS安全和治理方法中的关键角色，越来越重要。研究表明，现代应用程序包括超过500个OSS组件。随着如此广泛的使用，有必要认识到一些关于OSS组件的令人担忧的统计数据。

根据2022年Synopsys的调查，81%的OSS组件至少包含一个漏洞，88%的组件在过去两年没有新的开发，且88%使用的组件不是最新版本。所有这些指标导致了一个令人震惊的现实：组织正在广泛使用过时和不安全的组件。这意味着我们在现代企业环境中拥有巨大的攻击面，这些环境治理不善，并且为恶意行为者提供了丰富的途径（www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf）。

现在，读者应该熟悉美国网络安全行政命令（EO），包括第4节“增强软件供应链安全”。由于EO的结果，NIST已经制定了全面的软件供应链指南，包括开源软件控制，我们将在这里讨论，以及OSPO如何倡导其实施（www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-open）。

NIST将其OSS控制措施分为三个成熟度级别：基础能力、持续能力和增强能力。这些控制措施包括使用NIST安全软件开发框架（SSDF）的一些方面，并确保通过可信来源的安全渠道获取OSS组件。现代企业环境的现实是，大多数组织对其自身的OSS使用没有全面的可见性和治理，更不用说持续监控与之相关的漏洞了。这正是OSPO的优势所在：作为商业OSS产品和服务有效使用的倡导者，提倡对OSS相关漏洞的警惕，并确保这些安全实践被编入组织的政策和流程中。

NIST推荐的OSS安全控制措施还包括建立已知和经过审核的OSS组件的内部存储库，开发人员可以使用这些组件来降低组织风险。与其允许开发人员自由提取和使用所有OSS组件，而不了解其漏洞和风险，内部存储库创建了一个强大的OSS组件库，可以提高开发人员的速度，同时降低由于使用易受攻击的OSS组件而带来的组织风险。

NIST SSDF的另一个关键建议是实施支持工具链，包括指定必须包含在CI/CD管道中的工具以减轻风险。示例可以包括将软件组成分析（SCA）和SBOM工具集成到现代CI/CD工具链中，以确保企业能够全面了解通过工具链进入生产环境的易受攻击的OSS组件。这也促进了“左移安全”的推动，确保安全扫描在软件开发生命周期的早期进行，并在引入生产环境之前识别和修复漏洞，以防止它们被恶意行为者利用。OSPO可以在这一领域倡导和编纂的政策和流程不仅包括漏洞扫描和SBOM，还包括启用签名功能，帮助创建不可变的记录和日志，以支持软件开发活动的完整性和可审计性。

NIST提出的最成熟的层级是增强功能，包括使用安全编程语言，并最终将OSS组件的收集、存储和扫描自动化到前面提到的强化内部存储库中。这也许是帮助降低风险的最关键步骤，同时又不会阻碍开发团队的速度，如果受到阻碍，开发团队肯定会绕过组织策略和流程来完成他们的任务。

在OSPO中常见的角色包括开发者关系、倡导和布道。虽然这些小组通常在公司开发团队中建立热情和兴趣，但它们也通常致力于建立关键关系。这些关系可以用来鼓励采用新兴的OSS安全最佳实践，尽管许多组织在其应用程序、软件和产品中广泛使用OSS，但这些实践往往尚未实施。这带来了多重好处，例如确保组织最小化使用不安全的依赖项，并生产出更安全的应用程序，无论是用于内部还是外部目的。

研究（如Chinmayi Sharma的研究）还表明，软件供应商是OSS的主要受益者，因此最有能力帮助解决OSS供应链风险。这使得软件供应商处于一个有利的位置，可以更多地参与OSS社区，扫描漏洞，并为OSS项目做出贡献以减轻这些风险。这将是一个从目前OSS社区主要承担这一负担，而软件供应商社区缺乏平等参与和贡献的模式的转变。软件供应商从其产品和服务中使用OSS中受益匪浅，通过实施和成熟一个OSPO，他们可以更好地理解其OSS使用及其相关风险，并为他们高度依赖的社区做出贡献。

这使得OSPO处于一个完美的位置，可以引领范式转变，最终增强更广泛的OSS供应链的安全性。OSS在几乎每个行业都带来了创新和能力。OSPO现在有能力引领这些行业和相关组织更多地参与OSS社区，同时解决由于分散参与和投资导致的OSS当前系统风险。这将通过更好的治理和OSS组件的安全性，帮助降低供应商软件传递给下游消费者的一些风险。

第十章供应商实务指南

10.6 产品团队之间的一致性

如果不能在组织的各个产品团队中一致地实施，那么推动软件透明度和提供 SBOM 和证明等工件就不可能有效。对于非常大的组织或具有全球影响力的组织来说，拥有多个产品团队的情况并不少见，其中一些团队拥有自己的工具和 SDLC 流程。

作者们了解到至少有一家自动化制造商为每条产品线创建一个新的法律实体。因此，本质上有几十个或数百个法律实体，都在生产名字非常相似的软件，这对最终消费者来说并不总是很清楚。因此，对一家公司及其相关开发流程的安全评估并不适用于其他公司及其相关产品线。这可能变得非常复杂。

在某个时候，其中一位作者管理一个全球制造公司的应用安全，该公司有超过100个不同的开发团队，其中大多数采用不同的实践。推动标准化的努力遇到了大量阻力，其中一些是由于地区偏见，例如欧洲与北美之间对谁拥有更好流程的意见分歧。

由于整个行业仍在决定对CycloneDX、SPDX、VEX和VDR的看法，因此我们可能会在组织内部看到这些不一致现象持续一段时间。因此，消费者在合同中的安全附录中明确他们期望和打算让供应商负责的做法是很重要的。

随着软件消费者寻求在其各种应用程序和产品中实施标准化流程、治理和客户体验，达成某种程度的共识是重要的。例如，可能具体的CI/CD工具看起来不同，但不同团队同意标准化的输出和工件格式。

第十章供应商实务指南

10.7 手动工作量与自动化和准确性

供应商必须考虑的一个关键点是自动化的作用与提供给消费者的信息准确性的需求形成鲜明对比。对于大型软件公司来说，进行软件保障成为一种可扩展性的练习，尤其是那些在数百甚至数千个软件产品中部署计划非常快的公司。在某些情况下，自动化可能无法识别关键软件组件。例如，在运行时动态加载组件或不在 Dockerfile 中包含组件的 Docker 映像可能需要手动识别该组件。但是，确定什么是“足够好”的，以便对SBOM进行初始捕获可能会有所帮助。

如果供应商可以生产出超过一定置信度（例如80%）的SBOM或其他人工制品，那么对于该人工制品的消费者来说，这是否足够？总会有一些出错的可能性，当自动化流程时，这个余量可能会增加。如果不是 80%，您的预期置信度是多少？谁是你的客户？你有没有和他们谈过现实的期望？您是否有一个流程来更新和纠正先前错误的供应链工件？要通知您的客户？要根据这些新信息更新任何分析？如果工件是正确的，但发现了新的分析见解（例如新的 CVE），该怎么办？不仅要您生成的工件必须正确，而且从分析中获得的见解也必须正确。

我们常见的一个问题，特别是针对逆向工程生成的SBOM（软件物料清单），是无法理解所分析的内容。有多种技术可以识别组件，但有些技术并不比在文件中进行字符串匹配复杂。例如，一个注释中写着“cve_x在component_version_1.2.3中被修补”，可能会被解读为安装的组件是1.2.3版本，而实际上是2.0版本。对每个版本进行详尽的逆向工程是不现实的，那么在这些情况下你的信心水平是多少？可能不到80%。根据作者的经验，这通常更接近60%。因此，了解工件创建的方法也可能会成为考虑因素。

SBOM生成的阶段是否重要？设计、构建和部署阶段可能会为同一个应用程序生成截然不同的SBOM。早期阶段的SBOM对最终消费者可能没有帮助，而尝试获得完美自动化的构建SBOM可能是一种徒劳的尝试。也许这对供应商的内部软件保证实践已经足够了，完美可以保留给最终交付给客户的产品。这将大量的手动工作移到了作为质量保证过程的最后阶段，并提供了纠正任何检测到的偏差的机会。

第十章供应商实务指南

10.8 小结

在本章中，我们鼓励消费者广泛而深入地思考软件供应链安全的挑战以及 SBOM 的作用。我们解释了为什么组织需要或应该希望 SBOM 以及更广泛地说，供应商的软件透明度，以及如何使用 SBOM 并大规模管理它们的推荐潜在用例。我们还讨论过，虽然 SBOM 可能有助于解决软件供应链安全性和透明度方面的一些挑战，但它远非灵丹妙药，在工具、自动化、标准化和成熟度方面还有很长的路要走。在下一章中，我们将讨论软件透明度预测、国际努力以及我们作为一个社会在软件供应链安全方面的发展方向。

第十一章消费者实务指南

软件供应商的另一面是软件消费者。这些消费者正试图理解正在出现的一系列指导、最佳实践和要求，这些指导、最佳实践和要求不可避免地涉及供应商和消费者之间关系的推拉动态。每个都有不同的观点、激励措施和目标，并且可能有不同的监管要求。

第十一章消费者实务指南

11.1 深思熟虑

虽然本章关于消费者指南的内容包括与软件物料清单（SBOM）相关的讨论和建议，但我们想强调的是，SBOM 只是软件供应链安全更广泛讨论中的一种新兴工具和资源。然而，鉴于其对行业的高度关注，我们觉得有必要提供一些相关的指导。

正如我们在SolarWinds、Log4j和Kaseya等重要案例中讨论的那样，与软件供应链相关的风险可能与专有软件供应商、开源软件（OSS）组件、托管服务提供商和云服务提供商等有关。

此外，从NIST、CNCF、NSA等来源的现有和新兴指导中可以看出，软件供应链的最佳实践和消费者考虑因素涉及一些关键活动，包括了解他们的供应商、在这些关系中的共享责任、围绕软件消费的组织治理以及伴随工具的内部实践和流程，以确保安全的消费、开发和使用软件，以满足其组织独特的业务和任务需求。

此外，正如在第4章“软件物料清单的兴起”中“SBOM批评和担忧”部分讨论的那样，SBOM工具和操作化仍有许多需要解决的问题，以帮助组织成功地摄取、分析、丰富和存储SBOM，并将其作为软件供应链和更广泛的网络安全供应链风险管理（C-SCRM）活动的一部分。此外，基于各种组织的研究和可用的工具评估，还必须提供一些关于OSS项目等社区的SBOM当前状态和成熟度的见解。

正如我们在本书中提到的，取决于行业和相关监管因素，SBOM的采用率和SBOM数据的深度在生态系统中有所不同，因为供应商不一定有动力在没有业务利益或监管或采购/收购要求的情况下向消费者提供这些工件。由于这些原因，我们要强调的是，虽然SBOM在推动软件透明度和软件供应链安全方面很有用，但不应将其视为万灵药，这几乎是网络安全领域的任何一个方面的情况。这个问题复杂，没有单一的解决方案，因此长期以来一直有“纵深防御”这一说法。IT系统面临的威胁涉及用户、端点、数据、复杂的相互依赖系统等，导致没有单一的解决方案或技术可以解决所有相关的挑战和威胁。

第十一章消费者实务指南

11.2 我真的需要一个SBOM吗？

随着围绕 SBOM 的所有炒作和混乱，一些软件消费者可能会问自己是否需要 SBOM。当然，虽然软件行业几十年来一直没有使用 SBOM，但这并不意味着没有挑战，而且随着 OSS 和第三方组件的使用增加，这些挑战只会加速。

SBOM（软件物料清单）的兴趣在软件行业的供应商和消费者中都大幅增长，并且这种趋势似乎不会减缓。根据Linux基金会的《软件物料清单（SBOM）和网络安全准备状态》等调查，SBOM的使用在2022年增加了66%，预测显示到2023年几乎88%的组织将在某种程度上使用SBOM（www.linuxfoundation.org/research/the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness）。

现代软件和应用程序主要由开源软件（OSS）和第三方软件组件组成，如果没有使用SBOM或软件组成分析（SCA）等严格的活动，消费者对所使用软件的组件或依赖项的理解就不够充分。这意味着消费者目前和传统上一直在使用供应商提供的软件时，对所涉及的组件、它们的漏洞、可利用性以及它们可能对组织及其合作伙伴、客户和利益相关者构成的风险几乎不了解。正如在第2章“现有方法——传统供应商风险管理”中讨论的那样，传统的采购/收购和供应商风险评估流程没有达到包括软件组件清单和风险管理的深度。

虽然成熟且积极的供应商理想情况下会发布补丁或更新以解决其软件中的易受攻击组件，但事实并非总是如此。Veracode在其2017年的《软件安全状态》报告中发现，只有大约一半的供应商为其软件中发现的第三方组件漏洞开发补丁（www.veracode.com/sites/default/files/pdf/resources/reports/report-state-of-software-security-2017-veracode-report.pdf）。这并不是说所有的易受攻击组件都是可利用的，但它仍然使消费者缺乏上下文和指导，并伴随着剩余风险。

因此，消费者可能会使用他们不知道存在漏洞的软件。除非他们从供应商那里获得了该软件的SBOM，显示其包含的组件，否则消费者无法关联这些组件相关的漏洞，无法向供应商询问其可利用性，或独立评估和验证其漏洞的可利用性。SBOM带来的透明度有助于缓解大多数软件消费者目前面临的可见性和意识差距。

消费者使用SBOM的另一个原因是，如我们在其他章节中讨论的那样，国家漏洞数据库（NVD）等数据库显示的是产品级别的漏洞，但通常缺乏对产品中涉及的组件和这些特定组件相关漏洞的详细见解。消费者不能仅仅依赖严格使用NVD和产品的通用平台枚举（CPE）名称来了解或意识到产品中的易受攻击组件。

正如我们讨论过的，其他漏洞数据库正在出现，这些数据库在OSS漏洞以及对包URL（PURL）的支持方面提供了更好的功能，PURL是一种更有效的识别组件级漏洞的方法（https://github.com/package-url/purl-spec）。

正如您记得的，我们讨论过SBOM论坛在其白皮书《组件识别操作化提案》中的努力，该白皮书呼吁MITRE和NVD采用PURL来识别OSS和商业软件。在某种程度上，这将有助于解决NVD在与产品相关的组件级漏洞方面的当前差距。正如白皮书中指出的那样，全面自动化和SBOM的有效性将受到抑制，直到这一命名挑战得到解决或至少显著改善。

虽然供应商可能经常主动识别其组件和产品中的漏洞，修复它们并通知其消费者，但这并非总是如此。拥有组件的可见性允许消费者保持对组件级漏洞的意识，并在消费者识别到新组件漏洞时通知供应商（如果供应商之前没有通知，这是理想情况）。它还赋予消费者询问识别到的漏洞的可利用性的权力，如果供应商没有主动提供相关背景的话。正如我们将要讨论的，它还使消费者能够在供应商尚未发布修复或补丁且可能永远不会发布的情况下，实施虚拟补丁等方法。

这将责任推给供应商，使其知道消费者关注并关心组件漏洞。现实是，识别和修复漏洞有成本，而供应商不一定有动力在其他产生收入的活动（例如产品和功能开发）上主动进行这项工作。

资产清单一直是SANS和互联网安全中心（CIS）等来源中的安全最佳实践和关键控制。然而，随着行业认识到单个软件组件可能对不仅仅是一个组织而是整个行业造成的风险，对软件资产清单和现在的软件组件资产清单的讨论已经成熟。

知道让组织采用所有安全控制或优先实施它们同等重要是不现实的，CIS提供了一份与生态系统中最普遍的攻击相关的关键安全控制清单。CIS表示，这份清单是每个希望提高其安全防御的企业的“必须做，先做”的起点（www.cisecurity.org/controls）。

CIS 关键安全控制映射到其他行业框架，例如支付卡行业数据安全标准（PCI DSS）、健康保险流通与责任法案（HIPAA）、北美电力可靠性公司关键基础设施保护（NERC CIP）和联邦信息安全现代化法案（FISMA），所有这些框架也在一定程度上讨论了软件清单的需求。虽然传统上这可能意味着应用程序，但随着软件供应链攻击和易受攻击的软件组件的激增，它越来越多地转向更精细的软件资产清单。

正如CIS指导指出的那样，软件资产的清单和控制是防止攻击的关键基础。恶意行为者经常寻找他们可以利用的易受攻击的软件版本。这可能对组织产生各种影响，包括横向移动到其他企业资产，甚至出现级联场景，在这种情况下，他们会从最初的目标组织转移到商业伙伴、客户或其他目标有访问权限的组织。

如果没有健全和准确的软件资产清单，消费者将无法确定其环境中是否存在易受攻击的组件，或者是否存在其他相关问题，例如许可问题。

除了在软件组件资产清单方面发挥关键作用外，SBOM还为消费者提供了其他用例，例如事件响应团队。例如，在Log4j事件发生后，网络安全审查委员会（CSRB）报告称，一些联邦机构花费了数万小时调查事件并试图找到其企业环境中易受攻击的Log4j组件的存在。

虽然在大型复杂环境中的事件响应无论在何种情况下都不可避免地需要时间，但如果事件与易受攻击的软件组件（如Log4j）相关，并且你的组织缺乏全面的软件组件清单，那么确定组织的脆弱性位置和程度将变得极其困难。

从消费者的角度来看，SBOM在采购和收购中也具有重要价值。当消费者通常通过流程来审查新应用程序和供应商，以在其企业中使用或促进业务流程时，了解这些供应商可能带来的潜在风险是关键。

组织使用的方法包括请求漏洞扫描、渗透测试报告、合规性文档（如SOC 2）等，以帮助他们确定使用特定供应商或供应商的适用性。然而，这些活动在历史上并不包括软件组件清单数据，这使得消费者对所包含产品的软件组件构成不了解，也不了解供应商在其产品中使用的第三方软件组件相关的漏洞。

通过向供应商索取 SBOM 和漏洞利用交换（VEX）文档，消费者可以了解与其供应商产品相关的任何漏洞、其可利用性以及这些产品可能对其组织的安全态势产生的潜在影响，然后再在采购和收购过程中走得太远。

对于消费者来说，SBOM的另一个关键考虑因素是确保他们与供应商合作，以消费者可以支持的格式接收SBOM（例如，如果他们的内部工具和功能面向SPDX或CycloneDX，而不是具有支持两者的能力）。消费者可以使用合同条款等方法，要求供应商根据其个人需求和能力提供特定格式。消费者还可以使用他们的合同条款来定义他们所需的 SBOM 格式，以及频率、交付方式、必填字段等。这方面的例子包括美国联邦部门，该部门正在围绕国家电信和信息管理局（NTIA）团结起来——为 SBOM 定义了定义所需字段和内容的最小元素。

第十一章消费者实务指南

11.3 我该怎么处理它

你已经从软件供应商那里收到了SBOM，或者基于内部开发工作开始创建SBOM。现在，如何让这些SBOM变得有价值且可操作？

正如我们之前讨论的，SBOM在多种应用场景中具有价值，例如漏洞管理、依赖关系卫生、事件响应、许可证管理和采购。使其可操作的关键在于将SBOM整合到组织的政策和流程中，并让相关利益相关者参与进来，使这些工件在他们各自的角色和职责相关方面变得有价值。

虽然我们在第4章讨论过，业界已经迅速涌现出各种帮助创建SBOM的工具，但在处理、分析、丰富、存储和大规模报告SBOM及其相关数据方面，业界仍有相当大的发展空间。

这种成熟度的欠缺也适用于其他挑战，例如遗留软件或云环境。由于云环境的复杂性以及服务和提供商之间的众多相互依赖关系，业界尚未就云环境中的SBOM应具备的形式达成统一共识。

如果在创建或接收到SBOM后没有一个连贯的计划，组织将只能获得一些可能提供漏洞、风险和依赖关系见解的工件，但这些工件不会变得有价值，除非通过组织的技术使用和支持政策与流程使其可操作。正如我们所讨论的，SBOM有巨大的用例，但组织必须有一个计划避免增加个人和组织的认知负担，却收效甚微，必须正确使用这些SBOM。

第十一章消费者实务指南

11.4 接收和管理大规模SBOM

虽然单独来看，SBOM的概念及其用于揭示产品所涉及的软件组件和被消耗的软件组件的用途显得合乎逻辑，但在大型企业环境中跨越数百或数千个开发团队和众多第三方软件供应商的大规模实施，这个想法很快就会变得令人生畏。一个组织如何管理如此大规模的数据？如何确保你有一个健全且全面的方法来持续处理SBOM，以推动围绕风险、采购和我们讨论过的一些其他用例的决策？

消费者可以通过多种方法接收或获取SBOM。一个有用的资源是NTIA白皮书《共享和交换SBOM》，该白皮书来自我们在其他章节中讨论过的NTIA关于软件组件透明度的多方利益相关者过程(https://ntia.gov/sites/default/files/publications/ntia_sbom_sharing_exchanging_sboms-10feb2021_0.pdf)。

在NTIA指导的背景下，SBOM交换包括广告或发现和访问。广告或发现涉及发布和定位SBOM或注册一个端点以接收SBOM更新。访问是在检索或传输SBOM本身的过程结束时进行的。一些例子包括网站、电子邮件、文件传输协议（FTP）、应用程序编程接口（API）或源代码管理（SCM）系统。指导中的一些例子扩展了供应商在产品文献或包装中包含的URL，消费者可以导航到这些URL以查看SBOM。虽然这对于了解产品所涉及的初始组件可能很有用，但随着产品更新和新组件的引入，很容易看到挑战会出现。它需要产品的URL保持最新，以包含不同版本产品中的最新组件。

包管理工具也可以促进SBOM的分发和检索，SBOM可以出现在软件存储库的顶级目录中，或者作为容器清单文件的SBOM。

NTIA提供的另一个例子是建立一个SBOM的发布和订阅系统。这种系统创建了一种情况，上游供应商可以定期发布更新的SBOM供下游消费者手动或通过自动化方式检索信息。这种情况使得软件组件组成的信息能够从供应商到下游消费者实现近乎实时的SBOM流动。

SBOM围绕JSON和XML两种数据交换格式，这两种格式支持机器可读性和自动化，这对于实现大规模处理至关重要。虽然这些工件可以被人类理解，但使用计算机来摄取和解析SBOM数据效率更高、可扩展性更强。这还可以通过执行漏洞分析或与数据库和其他存储系统的集成等过程来丰富数据。它有助于将SBOM数据集成到现有的组织工具和工作流程中，从而基于软件组件和漏洞数据做出更明智的决策。

现代企业环境涉及多个内部开发团队以及众多外部和第三方软件供应商。鉴于行业指南建议每次软件发布时都创建和接收新的SBOM，很容易看出静态工件和交付机制在大多数现代技术环境中并不可扩展或合理。

大型企业组织将继续开发围绕API和自动化的有机能力，以促进大规模创建、摄取、丰富、分析和存储SBOM。我们将看到托管服务提供商（MSP）和供应商继续增长，他们为那些不希望或缺乏资源和专业知识的组织提供支持SBOM使用和治理的平台。这些可能以托管组织的形式出现，作为供应商和消费者之间的可信第三方或中介。

除了获取SBOM外，消费者还应验证SBOM的完整性和来源，以确定其有效性。这包括使用数字签名和哈希值来验证SBOM及其相关组件和认证的真实性，这不仅可以提供对构建环境和开发、分发软件所用过程的见解，还可以了解其组件和构成。

随着SBOM日益成为组织软件供应链实践中的关键工件，恶意行为者将不可避免地试图利用它们及其相关实践来绕过组织的安全措施，危害整个生态系统中的组织。

正如NTIA在其“软件消费者手册：SBOM获取、管理和使用”指导中指出的那样（www.ntia.gov/files/ntia/publications/software_consumers_sbom_acquisition_management_and_use_-_final.pdf)组织通常可以通过将SBOM数据输入到组织工作流程中来充分利用SBOM。这将SBOM从单独查看的工件转变为可以解析、提取并加载到其他自动化组织流程中的数据集合。这种重新框架可以通过内部开发的开源工具或商业工具提供商来促进，从SBOM中提取数据。

指导指出，目前各种商业解决方案和特定行业的应用场景（例如医疗设备、车队管理等）正逐步采用SBOM。这一趋势创造了一种情况，即SBOM数据的子集（如特定组件、供应商、版本等数据）可以为组织的环境中不同应用场景和目的提供相关见解。它将允许组织将SBOM数据与其他相关数据和见解结合起来，以改进各种业务和任务决策。

对于软件消费者而言，在接收和存储SBOM时，除非软件供应商另有授权，否则应该期望安全存储和访问控制。许多软件供应商对广泛披露其SBOM有合理的担忧，因为这会暴露其应用程序和产品中的漏洞，可能被恶意行为者利用。

理想情况下，供应商正在积极解决其产品中的漏洞，但与任何组织一样，许多供应商也面临时间、预算和专业知识等资源限制，这意味着完全没有漏洞的产品往往不太可能或不实际。基于这一原因，获得供应商提供的SBOM的消费者应该采取适当措施保护其工件和数据，防止未经授权的访问或披露。一个例子是OMB 22-18备忘录，要求特定的美国联邦机构实施适当的机制，以保护信息并分享他们从第三方软件供应商处收到的工件（如SBOM）。

第十一章消费者实务指南

11.5 减少噪声

拥有SBOM是一个很好的开始，但如果没有关于漏洞实际可利用性的上下文信息，它很大程度上会成为额外的噪声，增加消费者及其各种利益相关者的负担。因此，获取关于软件组件的详细信息（例如可利用性）是关键。

如在第4章中所讨论的，漏洞可利用性交换（VEX）正在迅速成为SBOM的不可或缺的配套文档，受到实践者社区的广泛认可。原因在于，没有可利用性的上下文，软件消费者将没有指导或见解来帮助他们在漏洞管理过程中推动漏洞优先级排序活动。

当软件消费者掌握了关于漏洞可利用性的信息后，他们可以更好地了解应用程序的哪些组件需要额外关注，并呈现实际风险。这种授权和背景信息创造了一种情况，即使VEX可能伴随最初的SBOM，但也可能需要额外的VEX文档，并且即使没有改变基础软件组件，通过SBOM进行通信和交流仍然可以发生。这是因为新的漏洞不断被发现和报告，而与之关联的软件（VEX）没有发生变化。可能会为现有软件组件发现新漏洞，这意味着需要为软件消费者提供新的VEX，告知他们该漏洞的可利用性。开源、行业驱动的努力，如OpenVEX规范，已经开始在行业中获得动力，旨在满足CISA和其他机构讨论的VEX要求和使用案例，并提供一种最小的SBOM格式无关方法，用于创建、合并和验证VEX文档，以传达与SBOM和软件相关的漏洞的可利用性（https://github.com/openvex/spec）。

一个物料清单（BOM）格式是CycloneDX，它拥有强大的支持，可以提供与易受攻击组件相关的上下文，帮助消费者更好地优先处理其漏洞管理工作。CycloneDX在SBOM之外还提供额外的功能，包括支持VEX以传达产品中使用的易受攻击漏洞组件的可利用性。它还可以支持漏洞披露报告（VDR），用于传达影响组件和服务的已知和未知漏洞，甚至可以用于在系统和漏洞情报来源之间共享漏洞数据的漏洞清单（BoV）。

最后，鉴于我们拥有复杂的现代软件、服务和组件生态系统，CycloneDX支持所谓的BOM-Link，它使我们能够引用来自其他系统的BOM中的组件、服务或漏洞。消费者应坚决要求供应商提供附带的VEX文档等相关工件，以便深入了解其产品和应用程序中易受攻击组件的可利用性。如果未能这样做，消费者将需要投入大量精力和猜测来处理其消费的软件中的漏洞。

除了使用前述的VEX和其他方法外，软件消费者还可以利用我们讨论过的行业漏洞数据库（如OSV、OSS Index等），并结合漏洞预测评分系统（EPSS）和威胁情报来丰富漏洞数据，以提高漏洞洞察的准确性，并优先处理对组织构成最大风险的漏洞。

第十一章消费者实务指南

11.6 分歧的工作流程——我不能只是应用一个补丁？

正如我们在前面的部分中讨论的那样，现实情况是，尽管供应商的软件和产品中存在漏洞，但消费者通常无法简单地获取可用的修复补丁。

这可能是由于供应商面临的资源限制、修补和纠正时间表、竞争性功能积压，或者仅仅是由于软件供应商或项目缺乏进一步支持和维持的原因。

例如，Aberdeen Strategy & Research等研究小组发现，2020年发现的超过20,000个漏洞中，供应商到年底仍未发布补丁的漏洞几乎占20%。这其中包括数千个已有公开利用漏洞的漏洞。事实上，就像历史上软件消费者在漏洞可用时通常难以应用补丁一样，供应商在发布已知漏洞的补丁时通常也难以跟上节奏。

因此，这种情况导致消费者必须采取其他措施来应对这些漏洞或缺陷可能带来的风险，而这些措施并不直接涉及修补供应商的软件。通常，这最终形成了行业所谓的虚拟补丁，OWASP（全球应用安全项目）将其定义为“一种安全策略强制执行层，用于防止已知漏洞的利用”（https://owasp.org/www-community/Virtual_Patching_Best_Practices）。

对于Web应用程序来说，这通常涉及拦截事务和数据流，确保试图利用已知漏洞的恶意流量无法到达Web应用程序。这通常采用Web应用防火墙（WAF）的形式，通常部署用于保护Web应用程序免受如跨站脚本（XSS）或SQL注入等恶意攻击，这些攻击试图利用应用程序中的漏洞和缺陷。

许多研究显示，几乎一半的披露的漏洞在其披露时供应商没有提供可用的补丁。这显示了在迅速向消费者社区传达已知漏洞和风险方面的积极尝试，但也不可避免地创建了一种广泛披露漏洞但没有供消费者用于缓解风险的补丁的情况。

除了供应商端面临补丁可用性的限制外，业务或任务约束也很常见，这些约束并不总是允许传统的修补选项，即使供应商提供了补丁。例如，可能存在关于使任务或业务关键系统离线或可能干扰为组织创收的系统的担忧。组织也可能推迟应用供应商和供应商提供的可用补丁，直到计划维护窗口，而暂时采用虚拟补丁来减轻风险。

正是在这些情况下，虚拟补丁的实践对软件消费者发挥了作用。除了像Web应用防火墙（WAF）这样的方法之外，软件消费者可以对环境、系统和配置进行更改为了减少特定漏洞的利用或影响，软件消费者可以根据讨论的漏洞的具体细节对环境、系统和配置进行调整。

尽管一些组织可能已经实施了成熟的虚拟补丁方法，但许多其他组织通常还没有。一个很好的资源是OWASP的“虚拟补丁速查表”（https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html）。它提出了六个步骤的虚拟补丁方法论，包括准备、识别、分析、虚拟补丁创建、实施/测试以及恢复/跟进。接下来我们来看看这些步骤。

准备阶段

准备阶段涉及组织在需要处理漏洞或入侵之前建立虚拟补丁过程。正如OWASP指出的，事故可能是紧张、混乱的时期，试图在混乱中建立流程往往是灾难的开始。组织必须确保他们通过邮件列表和公开漏洞披露等来源监控来自供应商和供应商的警报。您可能还记得我们在第9章“运营技术中的软件透明度”中讨论过这是一项关键能力。消费者还需要获取预授权，以避开传统的组织修补和治理流程，尽快应用虚拟补丁。消费者需要在事故或活动发生之前部署他们的虚拟补丁工具，以便能够快速响应。最后，他们需要建立HTTP审计日志记录，监控请求URI以及请求和响应头部和主体等Web流量字段。这些数据将使消费者能够识别适用的流量，并在后续阶段做出响应。

识别阶段

一旦消费者准备好实施虚拟补丁，他们就可以开始识别环境中的漏洞。OWASP将识别定义为主动或被动两种方式。在主动方面，组织通过渗透测试、自动化Web评估或审查其应用程序源代码等方法积极评估其Web安全姿态，以识别漏洞。被动的识别方式通常是除了最成熟的组织外所有组织的常规做法，包括通过供应商联系、公开披露或最糟糕的情况，即经历实际安全事件来识别漏洞。

分析阶段

在分析阶段，涉及多项活动，以确保组织能够适当地响应已识别的漏洞，包括确定虚拟补丁的适用性。实际上的漏洞或缺陷是什么？组织的工具和能力是否提供了适当的机制来解决它？漏洞还必须在组织的跟踪或工单系统中记录，并应用适当的漏洞标识符。这可能是CVE名称和编号，供应商在漏洞公告中定义的标识符，或者甚至是通过组织的漏洞扫描工具分配的标识符。关键在于在内部使用统一的名称来标识任何漏洞，以确保一致的响应和跟踪流程。

除了正确识别和跟踪漏洞外，组织还必须了解漏洞的影响级别。并非所有漏洞都是相同的，它们的严重性各不相同。组织需要确定哪些具体版本的软件受到影响，然后确定这些软件版本在其环境中的存在位置。尽管软件的版本和存在性至关重要，组织还必须记录允许利用漏洞的特定配置。对于某些漏洞，这可能仅仅是它们存在的事实，而对于其他漏洞，则可能需要特定的配置或环境因素才能利用漏洞。

最后，OWASP建议在漏洞公告中提供了漏洞利用的概念验证（PoC）代码时进行捕获。组织可以使用这些利用代码来开始创建虚拟补丁，以解决漏洞问题。

虚拟补丁创建

你已经做好了准备，识别了漏洞并进行了分析，现在准备创建虚拟补丁。这涉及什么？OWASP定义了虚拟补丁必须遵循的两个总体原则，包括无误报和漏报。这意味着你不希望阻止合法的流量，因为这可能会对任务、业务、收入、客户等产生负面影响。此外，你也不希望发生虚假阴性，因为这可能允许恶意流量通过，可能是因为恶意行为者成功逃避了检测。显然，100%实现这些目标是一个高远的目标，但为了避免你的虚拟补丁尝试对组织产生负面影响，这是值得努力的目标。

虚拟补丁可以手动创建或自动创建。在手动方面，可能会涉及创建允许列表来执行输入验证，并拒绝与定义的标准不符合的任何内容。一个人为的方法是基于攻击和漏洞相关的一组规则和标准使用阻止列表来阻止符合条件的任何流量。OWASP指出，尽管这种方法是一种选择，但并不理想。在这种情况下，虚假阴性的可能性更高，恶意活动有可能绕过特定的标准，避开检测。例如，我们之前提到过可能在漏洞公告中提供的PoC（概念验证）利用代码。组织可以使用这些代码来创建阻止列表。

OWASP的虚拟补丁速查表指出，无论是允许列表还是阻止列表，都有其利弊。阻止列表更容易、更快速地创建，但也更容易被规避。允许列表更为严格，但也需要更高的精确度，因为与其不符的任何内容都将被阻止，包括可能会导致组织中断的合法业务和任务导向流量。这些情况可能会阻碍业务对安全的信任，并危及未来快速应用虚拟补丁的权威性。

除了手动创建虚拟补丁的过程外，某些情况下也可以实现自动化虚拟补丁。OWASP指出了几个示例，如OWASP的ModSecurity核心规则集（CRS）脚本、ThreadFix虚拟补丁以及直接导入到WAF设备。这些选项使用的方法包括从工具导入XML漏洞数据，并将其转换为虚拟补丁以保护系统。虽然这些修补是理想的，并且是扩展虚拟补丁实践的关键部分，但通常也需要一些手动参与、调整和监督以确保其有效性。

实施和测试

一旦虚拟补丁被创建，组织必须开始测试和实施，以保护其免受试图利用相关漏洞的恶意行为者的攻击。在此阶段，组织可能会使用各种应用程序，如Web浏览器、命令行界面（CLI）和代理服务器等。OWASP建议最初在仅记录日志的配置中测试虚拟补丁，以避免阻止合法用户流量，并确保虚拟补丁的有效性。一旦完成并验证后，虚拟补丁可以开始阻止可能是恶意的流量。如果它与先前定义的允许或阻止列表一致，可以全面实施，同时确保它不会妨碍业务及其运营。

恢复和跟进

OWASP为虚拟补丁确定的最后一个阶段是恢复和跟进阶段。此阶段涉及更新组织的工单系统数据、定期重新评估以及运行虚拟补丁警报报告等活动。正确更新工单系统可以使组织能够评估其虚拟补丁的有效性和状态与虚拟补丁相关的漏洞管理指标，并捕获相关数据以应对未来的事件。重新评估可以用于确定何时以及是否可以移除虚拟补丁（例如，Web应用程序的源代码是否已直接修复）。报告可以提供虚拟补丁何时被触发的信息，提供有关潜在恶意活动和流量的见解，这些活动和流量可能对组织产生影响。

长期考虑

需要记住的是，虚拟补丁可以被视为一种权宜之计——一个临时解决方案，针对的是一个永久性问题。尽管它是保护无法直接修补或由于业务中断和任务影响等原因无法纠正的易受攻击应用程序的绝佳方法，但虚拟补丁应被视为一种临时缓解措施。组织必须意识到，恶意行为者也可以使用各种创造性的方法绕过WAF。例如，2022年，应用安全公司Claroty展示了他们如何通过使用JSON来模糊数据库命令并逃避WAF工具的检测，从而绕过五个最受欢迎的WAF供应商（www.darkreading.com/application-security/popular-wafs-json-bypass）。

这一现实意味着，组织必须制定长期计划，从源头上修补应用程序漏洞，同时具备良好的安全架构和工程实践，如零信任，以减轻横向移动的风险，或进一步限制恶意行为者绕过虚拟补丁机制时的影响范围和业务影响。

第十一章消费者实务指南

11.7 小结

在本章中，我们为软件消费者提供了实用的指导，包括广泛而深入地思考其软件消费的范围以及相关的各种来源和潜在攻击向量。我们还讨论了软件物料清单（SBOM）的出现及其对软件消费者的意义，同时强调了一些潜在的缺口和需要改进的领域，这些领域需要软件消费者在将SBOM作为其网络安全供应链风险管理（C-SCRM）战略和流程的一部分进行操作时加以解决。我们讨论了软件消费者必须准备好使用虚拟补丁等方法来应对漏洞，特别是在使用开源软件（OSS）时，但也包括在面对可能未及时解决漏洞的供应商时。在下一章中，我们将阐述作为一个行业和社会的前进方向，并预测软件透明度运动的未来发展。

第十二章软件透明度预测

到现在为止，应该很清楚的是，软件透明度和加强更广泛的软件供应链安全态势的努力绝不是转瞬即逝的。我们看到全球公共和私营部门在法规、工具、技术和框架方面做出了无数努力

第十二章软件透明度预测

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 节“加强软件供应链安全”专门针对这一挑战，并要求美国各地的各政府实体制定指导、要求等，以应对整个软件供应链的风险。 12.1 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来识别和记录产品中包含的组件。该法案规定，“为了便于漏洞分析，制造商应识别和记录具有数字元素的产品中所包含的组件，包括起草软件材料清单。”该法案特别要求供应商识别产品中易受攻击的第三方组件。

第十二章软件透明度预测

12.2 美国政府供应链影响市场的力量

虽然数字因来源而异，但不可否认，美国政府的IT和软件支出市场意义重大。来源估计，美国联邦政府在2023财年的预算超过650亿美元（www.whitehouse.gov/wp-cont/uploads/202/203/ap_16_it_fy2023.pdf）。这比上一个2022年580亿美元的预算有所增加，表明联邦IT支出在民事分支机构中持续增长（见图12.2）。

在国防方面，2023财年国防预算要求为7730亿美元。虽然这一预算的很大一部分不是特定于技术和软件的，但其中一部分是，正如所讨论的，越来越多的现代战争系统和平台也由技术和软件提供动力。当然，这项支出与美国联邦政府的DoD无关，不包括其他美国政府市场，如州和地方政府实体，他们有自己的IT支出预算和消费。这并不是说所有的IT支出都与软件有关，但正如我们在本书中所讨论的，几乎所有的现代技术都是由某种形式的软件提供动力的。这意味着，当美国政府领域出现新的政策、监管或合同要求时，这些变化最终会影响到整个技术和软件行业的很大一部分。许多人认为，由于美国政府从许多与更广泛的社会相同的供应商那里购买软件，他们新出现的要求将对整个行业产生影响，甚至在政府部门之外。

我们讨论过的要求，如要求使用安全的软件开发实践，深入了解软件中的组件，以及建立漏洞披露程序等机制，不仅会影响成百上千与美国政府合作的软件供应商，还会影响那些与数千商业软件消费者合作的供应商，不可避免地还会影响全球数百万人。

其他人也提出，政府采用的NIST标准，如安全软件开发框架（SSDF）和其他软件供应链指南，也可能被商业部门实体自愿采用。一个流行的例子是NIST于2014年发布的网络安全框架（CSF），这是时任总统奥巴马之前发布的题为“加强联邦和关键基础设施的网络安全”的行政命令（EO）的结果。该行政命令规定美国联邦政府机构必须使用CSF，但正如NIST在其CSF常见问题解答中指出的那样，与美国联邦政府不同，许多私营部门组织现在使用CSF，尽管它们是自愿的（www.nist.gov/cyberframework/frequently-asked-questions/framework-basics）。

其他例子包括指导和框架，如Fed RAMP，它只适用于与联邦政府合作的云服务提供商，但它已成为商业部门云安全的领先例子，在云安全联盟（CSA）的云控制矩阵（CCM）等商业框架和指导中被引用。我们还讨论了Do D新兴的网络安全成熟度模型认证（CMMC），它影响了与DoD合作的30多万国防工业基地（DIB）供应商，并促进了围绕供应链风险管理的更广泛讨论，涉及到组织供应链中的供应商，而不仅仅是软件。

这里值得指出的一点是，2022年末发布的一项调查发现，大多数DIB供应商没有做好满足这些新要求的准备，87%的承包商在《国防联邦采购条例补充》（DFARS）要求中得分不合格，即承包商在所谓的供应商绩效风险系统（SPRS）中自我报告得分。

也有报告称，一旦由第三方评估，自我认证的分数与现实不符，当我们看到新兴的软件供应链要求（如OMB M-22-18）也要求第三方软件供应商就其安全开发实践的使用进行自我认证时，这应该引起关注。当涉及到合同和收入时，自我认证面临着诸如客观性和透明度等挑战（https://cybersheath.com/more-than-87-of-vangle-supply-chain-fails-basic cybersecurity minimums）。

许多人认为，政府的规模和范围往往会导致商业行业在要求和方法方面处于领先地位。这意味着，虽然SBOM和与安全软件开发相关的证明可能只是联邦部门的硬性监管要求，但它们也很可能进入商业实践，尤其是在金融和医疗等其他受监管和安全意识强的行业

第十二章软件透明度预测

12.3 供应链攻击加速

虽然我们在第1章“软件供应链威胁的背景”中讨论过一些指标，但在本文结束之际，我们认为再次强调软件供应链攻击的趋势只会继续加速是有必要的。这是由于多种因素造成的，例如现代数字环境和生态系统的复杂性增加，开源软件（OSS）和第三方软件的广泛使用，以及恶意行为者意识到软件供应链攻击的高效性和有效性。

我们引用的最令人震惊的指标之一是2022年Sonatype软件供应链状况报告。该报告发现在过去的三年中软件供应链攻击年均增长率为742%。报告还指出七分之六的漏洞是由于传递依赖关系造成的。这也得到了其他来源的证实，例如在讨论透明度和开源软件（OSS）的挑战时，我们在第4章所引用的来自Endor Labs的依赖管理状况报告。

单个易受攻击的组件或代码片段也可能被其他项目重用，从而导致其在生态系统中的存在呈指数级分布同时增加风险。例如，根据Sonatype（www.sonatype.com/resources/log4j-vulnerability-resource-center）的数据，Log4j中易受攻击的代码被数百个项目重用，并通过这种方式传播到其他成千上万个组件（总下载量超过1.5亿次），并且在截至本文撰写时，每天仍有数万次下载量。研究人员现在发现成千上万的恶意软件包正在跨生态系统传播，表现了恶意行为者越来越关注软件供应链并促成了我们现在行业中不断看到的软件供应链攻击指数增长。

同一份Sonatype报告显示一个相关原因是开源软件（OSS）供应和消费的巨大增长。如摘自Sonatype报告的图12.3所示，在调查的主要生态系统中现有超过300万个项目，4700万个版本，并且每年的请求量超过3万亿次，这些都导致了所调查的生态系统同比增长超过30%。

虽然开源软件（OSS）的增长和消费通过代码重用加速了几乎所有行业的速度、效率和创新，但也由于第三方代码中的漏洞在各处被重用而产生了重大的系统性风险。这些广泛被使用的项目和依赖关系也是最易受攻击的。从某种意义上说，由于广泛使用开源软件（OSS）增加了行业的攻击面，开源软件（OSS）项目的广泛成功和采用也会增加行业风险。

由于传递依赖关系的存在问题进一步加剧，平均每个库有5.7个传递依赖关系并且62%库的第三方依赖中存在漏洞。因此，确保依赖项经过谨慎考虑选择是很重要的，因其可能伴随的漏洞和潜在风险。一些供应商已经开始整合功能，帮助开发人员在软件开发过程中进行组件选择时做出基于风险的决策。

继续依赖管理的话题，Sonatype报告提出了普通开发人员必须面对的几个问题。这其中包括跟踪和管理150个初始依赖项，每个应用程序每年多达1500次依赖变更，还需要有足够的安全和法律专业知识来选择最安全的版本。现实环境下，许多开发人员是通过交付速度对其进行评估或激励的，这种分析和细微差别往往不是关键考虑因素，更不用说实际和现实了。

虽然Sonatype报告是最有名的报告之一，但它绝不是证实软件供应链攻击呈指数增长的唯一来源。开源软件（OSS）的加速使用，伴随着恶意行为者对供应链这一攻击媒介的日益关注以及许多有能力做出更安全决策的实体（如软件开发人员）的认知过载，创造了一个完美的风暴。

遗憾的是我们并未看到这一趋势有所下降，因为恶意行为者已经意识到这种方式的高效性和成果。事实上，我们预计攻击者的创新性和创造性将持续发展，不仅针对开源软件（OSS）组件，还会针对服务和软件提供商，正如我们在一些标志性案例中展示的那样。

为了进一步证明趋势有效性，2022年欧洲网络安全局（ENISA）将软件依赖关系供应链妥协列为到2030年出现的头号威胁（见图12.4）。这一威胁排在其他关键领域之前，如虚假信息传播、技能短缺和人工智能滥用的潜在风险。这表明软件供应链威胁不仅在当前显得至关重要，正如我们讨论的趋势以及历史背景和软件供应链攻击目录中可以看出，而且在未来一段时间内它仍将是各个组织和国家面临的相关威胁。

第十二章软件透明度预测

12.4 数字世界日益密切联系

社会上最明显的趋势之一是数字连接设备的快速持续增长。正如我们整本书多次说到的，我们社会几乎每一个方面都与数字连接设备和软件相关联，从无害的生活用品（例如：家庭设备、智能手表和医疗设备等）到关键基础设施和军事系统。

大部分传统连接是由服务器、终端和移动设备等计算设备驱动的，随着物联网的惊人增长，这一趋势也呈指数级加速。物联网（IoT）设备通常被定义为连接到互联网并且有能力传输数据的物体，物联网设备包含无线传感器、家用物品、工业工具和制造设备等。

在现代社会中，几乎无限数量和种类的设备是可以连接。促进连接设备增长因素很多，包括低成本传感技术、云计算和创新的网络协议。我们还看到所谓工业物联网（IIoT）的巨大增长。IIoT利用云、分析和机器学习为各种使用环境助力，如智能制造、城市、电网和数字供应链。

这种连接为分析、效率、创新带来了巨大潜力，这在以前我们未连接的世界中是不可能实现的。这种广泛的连接也带来了新的商业模式和收入来源，提高了效率和运营，甚至在个人环境中提供了更高的生活质量。然而，也带来了我们前所未见的指数级和系统性风险。

与物联网设备相关的常见安全挑战包括硬编码和弱凭证、缺乏定期和及时的固件更新，以及组织使用的物联网设备在覆盖范围上是有限总体可见的。

正如我们从Verizon的数据泄露报告等来源看到的，泄露凭证是恶意行为者常用的攻击媒介。这对于许多物联网（IoT）和操作技术（OT）设备来说并不乐观，因为这些设备通常使用制造商提供的默认凭证，这使得它更容易成为恶意行为者的目标。物联网设备的另一个常见挑战是缺乏定期的固件更新，甚至恶意行为者会破坏传递到物联网设备的补丁和软件更新包。考虑到物联网覆盖范围及规模的日益增长，很容易看到其增长将会加剧与软件供应链相关的挑战，以及一个被破坏的补丁如何能产生巨大影响。

一些消息预计，到2022年底，将会有超过130亿个连接设备，这一数字预计在2025年将增长到多达750亿个。随着连接设备数量的激增，政府和监管机构难以跟上步伐。尽管如此，也正在进行一些努力——试图改进对物联网设备的监管，重点关注隐私和网络安全，但主要集中在前者。

一个名为“Which?”的英国消费者权益组织在2023年发布了他们的调查结果，指出许多领先的智能设备制造商可能在短短几年后就放弃对设备的软件支持。该组织指出，这不仅对“智能“设备的操作支持和使用寿命构成担忧，还会由于这些设备在社会中的广泛使用并且在生命周期内缺乏数字支持而带来安全风险。

观察欧盟和美国，可以看到一些与隐私和网络安全相关的监管努力正在进行中，其中一些是针对物联网（IoT）的，另一些虽然范围较广但仍适用于物联网。在欧盟的消费者隐私方面，最显著的是《通用数据保护条例》（GDPR），该条例于2018年在欧盟和英国生效。GDPR侧重于个人数据如何被管理，并围绕公平、合法和透明的关键原则提供框架。

虽然GDPR是基于欧盟的，但如果一些组织掌控了欧盟公民的数据，GDPR也适用于欧盟以外的组织。我们之前讨论过欧盟正在出台的《网络韧性法案》。该法案要求制造商在设计和生产过程中实施安全措施，并提供对涉及设备（包括物联网设备）的软件组件的可见性。

在美国，最近的努力集中在为物联网（IoT）设备创建网络安全标签计划（www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/cybersecurity-labeling-consumers-0）。该计划针对美国消费者，旨在像欧盟的《网络韧性法案》一样，提高透明度并为消费者提供更好的信息以便他们在购买和使用产品时能做出更好的安全选择。这也旨在激励物联网设备制造商在产品开发过程中考虑安全性。白宫建立推动本书中讨论的《网络安全行政命令》（EO），与一些行业最大的互联网设备制造商进行了讨论和合作，以推动这一努力。截至本文撰写时，网络安全标签计划计划于2023年春季发布。（www.whitehouse.gov/briefing-room/statements-releases/2022/10/20/statement-by-nsc-spokesperson-adrienne-watson-on-the-biden-harris-administrations-effort-to-secure-household-internet-enabled-devices）

除了网络安全标签计划，NIST还拥有一个强大的物联网网络安全计划，提供标准、指导和相关工具。这包括物联网设备制造商的信息，以及寻求使用物联网设备的联邦机构和消费者的信息。2022年秋，美国商务部任命了一个物联网咨询委员会，以帮助推动物联网领域的安全工作，并根据专业知识和行业经验提供关键见解和建议。（www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program）

另一个显著的例子来自2023年由拜登签署的拨款法案，特别是第3305节，其中包括要求互联网连接医疗设备制造商合理确保设备及其相关系统网络安全的条款。具体要求包括监控、识别和解决设备中的网络安全漏洞，并提供上市后的更新和补丁解决漏洞。对需要满足这些要求的设备将由食品和药物管理局（FDA）监督。（www.congress.gov/117/bills/hr2617/BILLS-117hr2617enr.pdf）

很容易看出物联网在社会中的增长，几乎应用于每个行业以及专业和个人环境中，为攻击面的大规模增长打开了大门，并为希望通软件供应链攻击和破坏的恶意行为者提供了机会。这些物联网设备由软件驱动，广泛存在于社会中，预计将有巨大的增长，无论是作为供应商还是消费者，从网络安全角度对其关注较少。我们预计 2023 年拨款法案中的规定以及与物联网设备使用安全和软件相关的规定将继续发展。

第十二章软件透明度预测

12.5 接下来会发生什么？

预测未来是非常困难甚至不可能的，但对软件透明度日益增长的推动几乎是可以感受到的。易受攻击软件对普通公民、政府和社会构成的风险再也无法忽视。

软件深入到从我们最基本的个人奢侈活动到我们最关键的基础设施、公共服务和国家安全系统的一切之中。正如我们在本书中反复强调的那样，软件具有几乎无限的创新和创造潜力，但它也对我们的现代生活方式构成了一种巨大的系统性风险。除了我们讨论的众多行业和官方的努力外，我们还预计政府、学术界和行业将进一步努力，以提高软件行业的透明度和安全性。

在2023年初的一次采访中，CISA（美国网络安全和基础设施安全局）局长Jen Easterly强调了政府和行业共同努力提高社会网络安全的必要性。Easterly指出，不仅是技术公司，医院、学区和关键基础设施也在持续遭受攻击，说明当前的网络安全方法是不持续的。

她强调公司需要采取措施，设计安全的产品和软件，甚至表示“网络安全是一种社会公益”，并且改进软件安全的努力应直接关系到社会的稳定性。与我们从研究人员如Chinmayi Sharma在其文章《数字公地的悲剧》中听到的信息一致，Easterly表示，负担不能再落在消费者和普通公民身上，而应该由那些处于最佳位置采取行动的公司和软件供应商承担。（https://finance.yahoo.com/news/us-cybersecurity-director-the-tech-ecosystem-has-become-really-unsafe-222118097.html）

2023年1月，《华盛顿邮报》提到，预期中的国家网络战略与以往任何战略不同，“这是第一次将监管纳入国家网络安全战略”（www.washingtonpost.com/politics/2023/01/06/biden-national-cyber-strategy-is-unlike-any-before-it）。

隐私和互联网政策专家、加州大学伯克利分校讲师Jim Dempsey在2023年1月的一篇题为《网络安全的一小步立法》（www.lawfareblog.com/one-small-legislative-step-cybersecurity）的优秀文章中解读了网络安全监管增加的话题。Dempsey指出，2023年拨款法案中要求连接医疗设备的条款，可以说是自2005年以来，国会首次明确授权任何机构对任何类型的私人拥有和运营系统的网络安全进行监管。

Dempsey指出，截至目前，大多数与关键基础设施相关的网络安全措施都是自愿的。许多批评者指出，网络安全可以被归类为市场失灵，将其留给市场自我监管和优先考虑网络安全已经失败并且继续失败。如果这种观点是正确的，那么令人担忧的是，美国的大多数关键基础设施是私人拥有和运营的，通常使用易受攻击的软件组件，并且是恶意行为者的主要目标。

许多人怀疑美国国家网络战略及相关努力，传统上基于自愿努力的基础，正在开始转向监管要求。随着这些新兴要求的出现，供应商和忽视其在软件、产品和数字系统方面的网络安全责任的实体将面临更高的责任和问责。正如我们之前提到的，一些人认为网络安全是市场失灵的问题，仅靠自愿努力无法解决这一挑战。这种对监管要求和后果的推动旨在平衡局面，解决当前国家安全和公共安全中的差距，而这些差距现在都以软件为基础。

在美国，有16个关键基础设施部门，涵盖通信、能源、紧急服务、交通、信息技术和国防工业基地等领域。随着国家持续注意到针对关键基础设施实体的恶意网络攻击加速，关键的安全领导人加大了对这些部门及其监管状态关注。副国家安全顾问Anne Neuberger及其相关团队就是一个例子。该团队发现，虽然许多关键基础设施部门在网络安全方面有一些监管措施，但并非所有部门都如此。在美国的几个领域中，包括食品、农业和教育在内，发现了监管空白。

联邦紧急事务管理局（FEMA）指出，私人部门拥有全国85%的关键基础设施和关键资源。报告还指出，随着结构的平均年龄增加，这些关键基础设施变得更容易发生故障（www.fema.gov/pdf/about/programs/oppa/critical_infrastructure_paper.pdf）。

为了支持报告的有效性，2023年初，美国联邦航空管理局（FAA）因其航空任务通知系统（NOTAMs）的故障被迫于1月11日停止所有美国航班。FAA在2022年的一份报告中解释了其在遗留硬件和软件方面的挑战。（www.faa.gov/sites/faa.gov/files/2022-02/FAA_FY22_Business_Planv2.pdf）

正如2022年Synopsys开源安全和风险分析报告等研究所述，美国每小时遭遇1000万次尝试攻击，这些攻击特别针对关键基础设施部门。报告发现，关键基础设施代码库中有一半包含开源软件（OSS）。同一研究指出，几乎所有代码库都包含四年以上未更新或两年内没有新开发的OSS组件。软件和我们的物理基础设施一样，随着年龄的增长变得越来越脆弱，特别是由于新漏洞的出现。

当你考虑到老化的物理基础设施，通常由过时且可能存在漏洞的软件驱动并且经常遭受恶意活动的持续轰炸，你可以意识到问题开始变得令人担忧。2023年世界经济论坛（WEF）全球风险报告支持这一观点，报告将对关键基础设施的网络攻击列为最高风险之一。当被调查时，几乎所有网络安全领导者都表示对未来两年内发生毁灭性全球网络攻击的强烈担忧。（www3.weforum.org/docs/WEF_Global_Risks_Report_2023.pdf）

除了其他新兴的监管工作领域，如网络安全数据泄露报告要求和设备标签，人们还越来越推动供应商提供软件的透明度。这包括提供软件组件、依赖项及其相关漏洞的透明度。虽然这些努力并不完美，但它们有助于解决软件供应商和消费者之间现有的信息不对称问题。

期望普通公民和业务核心并非网络安全的企业成为软件安全、开发安全软件和漏洞管理的专家是不现实的。在社会的其他领域，如汽车、飞机、药品和食品，我们不会问这个问题。作为一个社会，我们已经为这些行业制定了措施，以解决供应商和消费者之间的信息不对称问题，以确保安全、责任和问责制，同时仍然允许消费者做出风险知情的决定。我们现在看到在软件和技术方面也在努力做类似的事情。

正如我们通过引用世界各国的努力所指出的，这个问题不仅限于美国。世界各地的政府和国家正在意识到不安全的软件、缺乏透明度以及缺乏对安全产品和技术的问责所带来的系统性风险。他们也正在采取类似的措施来应对这些问题。

我们完全可以预料到，与政府和监管机构的软件透明度和安全性努力相比，将会有来自工业团体、游说者和商业实体的抵制。例如，美国商会已经表示，他们正在积极准备审查新的国家网络战略，并确定其对各自成员的影响。游说者和行业团体在推动增加软件供应商透明度和问责做出历史性努力以及最近如2023年《国防授权法案》（NDAA）和其包含的软件物料清单（SBOM）等方面取得了一些成功。

当然，这些团体提出的担忧是有道理的，比如某些所需工件和见解的成熟度，以及协调其活动所受的各种监管要求的需要。分散的法规和要求会在行业中造成混乱，导致时间和投资的浪费，并可能阻碍创新和速度。政府和公民能够使用创新技术和能力对提高生活质量、经济繁荣和国家安全至关重要。对软件的监管努力必须与这些监管措施所施加的限制和影响相对照。例如，国防部的许多人认为，破碎和陈旧的要求和法规阻碍了他们以有效速度执行任务的能力。

在最新的国防部软件现代化战略中，这一点得到了强调，该战略解释了软件现代化在国家安全中所扮演的关键角色。文件的开头写道：

国防部的适应能力越来越依赖于软件，安全且快速地提供弹性软件能力是定义未来冲突的竞争优势。将软件交付时间从几年缩短到几分钟需要对我们的流程、政策、劳动力和技术进行重大变革。(https://media.defense.gov/2022/Feb/03/2002932833/-1/-1/1/DEPARTMENTOF-DEFENSE-SOFTWARE-MODERNIZATION-STRATEGY.PDF)

因此，尽管基于对软件消费透明度历史上的缺失、开源软件（OSS）使用的指数级增加以及恶意攻击者加速攻击的现实，推动软件透明度和增加软件供应链安全严格性是必要的，但这些努力必须与它们对团队、组织和行业所带来的负担和摩擦进行比较。

我们还预见到，实现这些目标需要相关的工具更加成熟。这适用于物联网（IoT）、操作技术（OT）、传统软件，甚至云环境中的软件组件资产清单、更高保真度的漏洞数据，以及支持软件供应商、消费者和其他行业实体之间数据交换。这些工具和组件必须是可自动化和可操作的，例如，开发团队能够不过度阻碍其交付代码到生产环境的速度，并帮助组织实现软件驱动的业务和任务目标。

我们还预见到的一个趋势是，从传统的静态表单式供应商风险评估转向一个以API为中心、由云等技术促进的，并能实现自动化和近实时评估的方式。这种自动化趋势对于成功扩展并实现与软件物料清单（SBOM）相关的预期目标以及传达可利用性尤为关键，特别是在遵循敏捷和DevSecOps方法学的大型复杂开发环境中，这些方法学伴随着频繁的软件发布，从而提高相关工件（如 SBOM 及其伴随的可利用性上下文）的速度。

多年来，合规性和安全性一直落后于行业的广泛趋势（推动DevOps、增加开发速度、加快市场上市时间以及快速软件开发和发布）。我们看到像DevSecOps这样随着发展不断成熟和壮大以及云和 CI/CD 工具链等环境中改进的创新安全工具和流程，以提供所需的安全性和合规性控制，同时限制对开发人员速度的影响。随着转向代码化（如，as-code）、声明式基础设施和微服务的趋势越来越大，安全性和合规性必须继续创新以跟上步伐，发挥推动作用，并在软件供应链方面提供所需的透明度和问责水平。

正如我们在第11章《消费者的实用指南》中讨论的那样，我们还预见到软件供应商和消费者将进一步努力成熟他们的软件供应链治理和安全措施。从供应商的角度来看，这将体现在改进OSS治理、产品中软件组件的透明度以及对他们广泛使用的OSS维护者和社区的实际期望方面的重新评估。

从消费者的角度来看，我们预见到软件消费者将继续要求其上游软件供应商和供应商提供更多透明度。这包括确保遵循安全软件开发实践过程，并要求提供 SBOM 等软件工件和附加工件显示漏洞和可利用性。供应商和消费者之间需要进一步沟通，以帮助解释不仅是漏洞的存在和可利用性，还包括修复时间表以及消费者在漏洞修复之前可以采取减轻风险的措施。

各类组织还应将持续认真检查其软件供应链。这种检查不仅限于其环境中安装和运行的OSS和第三方软件供应商，而且要扩展到托管服务提供商（MSP）、云服务提供商（CSP）和软件即服务（SaaS）提供商，这些提供商被越来越多的恶意行为者作为目标，试图利用我们当前运行的复杂软件供应链生态系统。

这些努力可能会导致软件生态系统中的一些调整，因为更成熟和安全意识较强的消费者希望利用成熟和安全的软件供应商和服务提供商来减轻其组织、利益相关者和客户的风险。我们怀疑这种趋势将在包括国家安全和金融、航空航天等受监管行业的社区中最为普遍。

除了开发、供应和消费软件的团队之间的变化外，我们预计在组织最高层次上对网络安全问题的进一步参与和监督，不仅限于首席信息安全官（CISO）和董事会。这在一定程度上是由于意识到几乎每个企业都涉及技术和软件领域，即使这不是他们的核心竞争力，但它通常帮助推动他们的收入和运营。美国证券交易委员会（SEC）等机构的变化推动也推动了这一趋势，这些机构推动董事会将网络风险纳入其信托和监督活动的一部分。

例如，SEC最近提出的规则变更《网络安全风险管理、战略、治理和事件披露》包括要求组织披露其董事会的网络安全专业知识的条款。这将促使组织领导层需要更了解和参与其各自公司网络风险的监督，包括与软件供应链安全和由于软件供应链攻击或恶意活动引发的事件（www.sec.gov/rules/proposed/2022/33-11038.pdf）。

这些变化标志着监管环境的转变，即组织董事会现在将被要求确保其董事会成员具备网络安全专业知识。鉴于软件供应链攻击正在加速，并且在过去几年中一直是组织讨论和关注的常规重点，可以安全地假设这一主题将引起董事会的注意，并且在某些组织中已经引起了注意。

在本书中，我们涵盖了软件供应链安全领域的广泛主题。这些主题包括具有里程碑意义的软件供应链攻击、传统评估方法、最新指导和最佳实践、SBOM的兴起及相关主题，以及对供应商和消费者的实用指导。我们还讨论了云计算、Kubernetes 和容器等创新技术在软件供应链生态系统中所发挥的作用。尽管考虑到现代软件供应链及其相关生态系统的复杂性，不可能涵盖所有相关主题，但这些内容应能使从业者能够透明地生产安全软件，并了解他们从OSS生态系统或第三方软件供应商处获取软件的风险。

正如我们在本书中反复强调的那样，软件对于我们社会的几乎每个方面都至关重要，随着我们进入无处不在的数字化未来，确保我们生产和消费安全软件至关重要。软件提供了无与伦比的创新、能力和增长的承诺，同时也带来了系统性风险，这些风险如果处理不当，可能会对我们的社会造成毁灭性打击。

正如美国最高法院法官路易斯·布兰代斯一个多世纪前所说：“阳光是最好的消毒剂。”如今，社会正在推动围绕我们生活各个方面的数字生态系统以及与之相关的系统风险的透明度。

我们是阳光的捍卫者

软件透明度

前言

引言

供应链安全的重要性

本书内容

目标读者

第一章 软件供应链威胁的背景

1.1 攻击者激励因素

1.2 威胁模型

威胁建模方法

威胁建模过程

1.3 里程碑案例一：SolarWinds

1.4 里程碑案例二：Log4j

1.5 标志性案例三：Kaseya

1.6 案例的启示

1.7 小结

第二章传统的供应商风险管理

2.1评估

2.2 软件开发生命周期评估

2.3应用程序安全成熟度模型

治理

设计

实施

验证

运营

2.4 应用程序安全保证

静态应用程序安全测试

动态应用安全测试

交互式应用程序安全测试

移动应用程序安全测试

软件成分分析

2.5哈希和代码签名

2.6总结

第三章 漏洞数据库和评分方法

3.1公共漏洞与暴露

3.2国家漏洞数据库

3.3软件标识格式

CPE

软件标识标签

PURL

3.4 Sonatype OSS索引

3.5 开源漏洞数据库

3.6 全球安全数据库

3.7 公共漏洞评分系统

基本指标

时间指标

环境指标

CVSS 评分尺度

批评意见

3.8 漏洞预测评分系统

3.9 EPSS模型

3.10 EPSS的批评意见

3.11 CISA的观点

通用安全咨询框架（CSAF）

漏洞可利用性交换

特定利益相关者漏洞分类和已知被利用的漏洞

3.12 行动意见

3.13 小结

第四章 软件物料清单的兴起

4.1 法规中的SBOM:失败和成功

NTIA:宣传SBOM的必要性

4.2 行业努力：国家实验室

4.3 SBOM格式

软件识别（SWID）标签

CycloneDX

软件包数据交换(SPDX)

漏洞利用可行性交换（VEX）和漏洞披露

VEX进入对话

VEX: 添加上下文和清晰度

VEX和VDR对比

4.4 行动建议

4.5 将 SBOM 与其他证明结合使用

来源真实性

构建证明

依赖管理和验证

Sigstore

采用

Sigstore 组件

提交签名

SBOM 的批评和关注

第一章软件供应链威胁的背景

第三章漏洞数据库和评分方法

第四章软件物料清单的兴起

第五章软件透明度的挑战

第六章云和容器化

第七章现有和新兴商业指南

第八章现有和新兴政府指南