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

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

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 应用程序安全保证

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

静态应用程序安全测试

进行代码审查的概念，对于从事应用程序安全实践的人来说可能并不陌生。这是对某一时刻应用程序或软件组件源代码的静态视图。通常，在一些重要的里程碑，如重大发布或架构变更时，会进行详尽的静态应用程序安全测试（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等更好，但它们仍然存在信任问题。

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

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

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

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

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

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

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

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

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

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

2.6总结

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