第十一章 消费者实务指南

软件供应商的另一面是软件消费者。这些消费者正试图理解正在出现的一系列指导、最佳实践和要求，这些指导、最佳实践和要求不可避免地涉及供应商和消费者之间关系的推拉动态。每个都有不同的观点、激励措施和目标，并且可能有不同的监管要求。

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）时，但也包括在面对可能未及时解决漏洞的供应商时。在下一章中，我们将阐述作为一个行业和社会的前进方向，并预测软件透明度运动的未来发展。