第十章 供应商实务指南

虽然我们已经讨论了许多来自私营和公共部门组织的新兴行业指导来源，但接下来的几章将努力为供应商和消费者提供一些实用的指导。这将包括来自我们讨论的来源的指导的综合，以及基于作者专业经验的行业最佳实践和建议。
并非所有的建议、最佳实践和流程都适用于所有供应商。就像软件消费者的多样化生态系统一样，软件供应商在资源、专业知识和限制方面存在着不同的程度。根据行业、业务关系、监管要求和合同方面的情况，软件消费者和供应商之间往往存在着二分法，来达成关于何时、如何以及在什么情况下实施、提供或披露的问题。

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 等努力的推动都围绕着数据展开。如果没有高质量的数据，供应商和消费者都将不知所措，因为没有足够的洞察力来做出风险知情的决策，并推动有助于加强软件供应链状态的组织成果。
10.4 版权所有，许可问题和“原样”代码

正如我们在第 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 可能有助于解决软件供应链安全性和透明度方面的一些挑战，但它远非灵丹妙药，在工具、自动化、标准化和成熟度方面还有很长的路要走。在下一章中，我们将讨论软件透明度预测、国际努力以及我们作为一个社会在软件供应链安全方面的发展方向。