作者：Taylor Lehmann、Seth Rosenblatt

诊断和治疗慢性疼痛可能是复杂的、困难的，对患者和医生来说充满了不确定性。根据患者的状况和医生的知识水平，做出正确的诊断需要时间，可能还需要尝试不同的治疗方法。

这种反复试验的过程可能使患者陷入痛苦和困惑的境地，直到能够开出最佳的药方。这种情况类似于许多当今安全运营团队所面临的日常挑战。

站在山顶上大喊“赶紧打补丁！”并不实用，尤其是当安全团队不确定应用某个补丁是否会导致更严重的问题，例如系统崩溃、不兼容或停机。就像患有慢性疼痛的患者，他们可能不知道系统中痛苦的根源在哪里。确定哪些漏洞应该优先打补丁，以及确保这些修复措施真的使系统变得更安全，是安全团队面临的最大挑战之一。这就是漏洞可利用性交换（VEX）起到作用的地方。

VEX的重要性

在之前的博客中，我们讨论了如何建立对患者安全和技术的可视性和认知是如何对创建一个弹性的医疗系统至关重要。我们还探讨了如何将软件物料清单（SBOM）与Google的供应链软件工件等级（SLSA）框架相结合，来构建更加安全、增强韧性的技术。

SBOM为你使用的软件及其来源提供了可见性，而SLSA则提供了指导方针，帮助增强你构建的软件的完整性和安全性。VEX可以作为这个公式的快速诊断工具，国家电信和信息管理局将其描述为与SBOM并行存在的“伴侣”文档。

回到我们的医学比喻，VEX是一个机制，使软件提供商能够告诉安全团队痛苦的根源在哪里。VEX数据可以在需要在特定时间点捕获库存和漏洞数据时帮助进行软件审计。这些数据还可以嵌入到自动化安全工具中，使优先修复漏洞变得更加容易。

你可以将SBOM看作是药瓶上的处方标签，SLSA看作是保证药物安全的儿童防护盖和防篡改封条，而VEX则是药瓶上的安全警告标签。作为一个诊断辅助工具，VEX可以帮助安全团队在坏人行动之前准确诊断“可能会伤害到什么”以及系统的薄弱点。

然而，准确评估那种威胁模型可能是充满挑战的，尤其是当审视我们用来运行系统的软件时。快速、准确地评估一个组织的薄弱点和痛点对于加快对漏洞的响应并在它们变得具有破坏性之前阻止网络攻击至关重要。我们认为VEX是帮助确保软件供应链安全的关键部分。

以2021年12月揭露的Apache Log4j漏洞为例。当发现Apache的Log4j 2日志系统如此容易受到攻击，以至于相对不太复杂的威胁行为者可以迅速渗透并接管系统时，包括医疗在内的全球行业受到了另一次打击。通过Google的研究和CISA提供的信息，我们了解到Log4j 2中的漏洞，一个单独的软件组件，可能会影响到数千家因其近乎无处不在的使用而依赖它的公司。

尽管VEX不会捕获零日漏洞，但它能够告知安全团队Log4j 2中的其他已知漏洞。一旦漏洞被公开，安全团队可以使用SBOM来查找它们，并使用VEX来了解是否需要优先进行修复。

VEX如何提高可见性?

我们之所以重视像SBOM和SLSA这样的可见性机制，是因为它们让我们有能力了解我们的风险。如果我们无法看清需要保护的内容，就难以迅速地降低风险。

可见性是阻止恶意攻击者的关键第一步。但是，如果没有上下文，过多的数据会使安全团队感到不知所措。举个例子，根据开源漏洞数据库(OSV)的数据，仅仅是影响开源软件的已知漏洞就有30,000个，那么我们应该从哪里开始修复呢？NIST的国家漏洞数据库(NVD)则追踪了近181,000个漏洞。如果我们采取“全面修补”的策略，那我们可能会修补到下一个千年。

要逐一解决每一个漏洞是不可能的。为了取得进展，安全团队需要能够优先处理发现的问题，并首先关注那些可能造成最大影响的问题。VEX的目标就是使这种优先处理变得稍微简单一些。

虽然SBOM在构建中包含的材料发生更新时会被创建或修改，但VEX是在新的漏洞或威胁发现时设计的。这意味着VEX和SBOM需要分开维护。由于安全研究人员和组织不断地发现新的网络安全漏洞和威胁，VEX这种更为动态的机制有助于确保开发者和操作者能迅速了解他们使用的软件的风险。

我们来看一个来自CycloneDX的VEX示例。您可以看到找到的漏洞列表、追踪和报告这些漏洞的第三方、按照CVSS的漏洞评级，以及最重要的，来自开发者的声明，这会指导查阅VEX的操作者了解哪些漏洞是可以利用的并需要得到保护。在底部，您会看到VEX“影响”了一个SBOM。

这些信息允许VEX文档的用户参考其关联的SBOM。出于需要，VEX被有意地与SBOM分开，因为它们需要在不同的时机进行更新。当出现新的漏洞时，需要更新VEX文档；当制造商对软件进行更改时，需要更新SBOM。尽管它们可以且需要被单独更新，但由于它们是关联的，所以每个文档的内容可以保持一致。

借助可见性强化系统韧性——SBOM+VEX+SLSA

VEX的引入为安全漏洞的管理带来了革命性的变化。不少操作人员常常被大量的安全漏洞所困扰，他们需要尽力推断哪些是首要处理的，并花费大量时间浏览众多的文档来寻找最佳的解决方案。

有了SBOM、SLSA和VEX，操作者能够通过基于软件的方式进行风险评估，而不再是依靠直觉或者盲目猜测。这三者的结合提供了一个及时更新的问题清单，帮助我们识别最亟待关注的问题。这种方法代表了安全领域的一次巨大进步，帮助团队更有效地进行漏洞防范，从最关键的环节开始。

由于关键基础设施，如医疗保健，屡次遭受网络攻击，政府已经更为重视软件和供应链的安全问题。为增强SBOM在美国的应用效果，新提议的“保护和转型网络健康关怀（PATCH）法案”应运而生。这项法律将强制医疗设备制造商在产品中实施基本的网络安全标准，这包括为其产品创建SBOM，并计划对产品使用期间发现的网络安全漏洞进行实时监控和修补。

FDA近期的医疗设备网络安全草案指导也进一步强调了他们希望医疗设备制造商更进一步加强其产品的网络防护。此外，白宫在2021年5月的行政命令中也提及了SBOM，该命令旨在明确安全软件开发的要求，特别是为联邦政府使用的软件制定和发布SBOM。

不管这些政策措施如何落实，Google坚信，SBOM、SLSA和VEX的结合是确保软件安全、建立韧性强大的医疗生态系统的关键。这种联合策略为安全团队提供了全面而关键的风险数据，帮助他们更有效地采取措施，降低各种风险。

我们建议您怎么做?

在谷歌，我们正在与开源安全基金会合作支持SBOM的开发。我们关于安全软件开发的“了解、预防、修复”报告为谷歌如何考虑从可预防的漏洞中保护开源软件提供了更广泛的框架。你可以从我们的云架构中心了解更多关于在谷歌云上保护工作负载的努力。请查看Cloud Build，这是一项谷歌云服务，可用于生成高达SLSA 2级的构建工件。

由于依赖开源软件（OSS），客户往往难以完全了解和控制漏洞。可确保的开源软件（Assured OSS）是谷歌云的一项服务，可帮助团队保护他们使用的外部OSS包，并通过从代码库中简单地消除它们来克服可避免的漏洞。最后，请向我们了解谷歌的网络安全行动团队，这是世界上最优秀的安全咨询团队，其独特的使命是支持政府、关键基础设施、企业和小企业的安全和数字化转型。

如果你是软件供应商，请考虑我们上述的建议。无论你是否是供应商，你应该开始：

• 通过合同要求所有新软件提供SBOM+VEX+SLSA（或等同物）工件。
• 培训采购团队要求和使用SBOM+VEX+SLSA来进行采购决策。组织不应采购具有已知可预防问题的软件或硬件。即使如此，这些机制提供的信息应有助于安全团队在设备进入网络前决定是否能够承受风险。
• 建立确保控制采购决策的人了解并负责与他们购买的软件相关的风险的治理计划。
• 使安全团队能够构建流水线，将SBOM+VEX+SLSA工件引入其安全操作，并用它来战略性地提供建议并推动缓解活动。

在谷歌，我们相信实现弹性的道路始于将可见性和结构意识作为关键的第一步构建到软件、硬件和设备中。时间会告诉我们VEX是否会被广泛采用，但它背后的观点不会改变——没有可见性，我们无法知道自己的脆弱之处。在这方面，VEX是一个重要的概念。