SBOM落地的关键一步——漏洞可利用性交流（VEX）

SolarWinds 网络安全事件的影响，加上 Log4j 漏洞对众多知名企业产生难以估量的后果，使软件供应链安全成为安全领域的热门话题，并且SBOM现在成为网络安全漏洞计划的一个重要组成部分。

SBOM 本质上是构成软件的组件列表，其好处之一是识别潜在的带有漏洞的组件。领先的 SBOM 平台和工具，如 Dependency Track，通过将与组件相关的漏洞与那些使用 SBOM 来分析其软件组件的人所关注的漏洞相关联，来实现这一目的。此类工具通过查询国家漏洞数据库（NVD）、Sonatype OSS索引、VulnDB或OSV等来源来实时更新漏洞信息。

然而，软件中带有漏洞的组件并不意味着该组件是可以被利用的。这便是漏洞可利用性交流（VEX）发挥作用的地方。

漏洞可利用性交流（VEX）最初是为用户（运维人员、开发人员以及服务提供商）提供额外的信息，说明产品是否受到所含组件中特定漏洞的影响，如果受到影响，是否有建议的补救措施。

简言之，VEX为漏洞添加了上下文信息以告知风险管理活动。与SBOM和软件供应链安全指南类似，VEX诞生于美国国家电信与信息管理局软件组件透明度的多利益相关方流程。虽然VEX是为特定的SBOM用例而开发的，但它并不局限于与SBOM一起使用。

再次强调，并不是所有漏洞都可以被利用，因此企业可以通过漏洞管理计划和活动进行风险管理。在网络安全风险管理中，企业需要基于其风险容忍度来识别、分析、评估和解决网络安全威胁。因此，企业需要根据风险发生的可能性和严重程度来对风险进行优先级排序。如果不了解漏洞是否被利用，就不可能精确地预估其发生的可能性。

软件供应商授权发布VEX，为用户提供特定产品中的漏洞信息。VEX 支持4个主要的状态选项：

未受影响（Not affected）：无需对该漏洞采取补救措施

已受影响（Affected）：建议采取措施来修复或解决此漏洞

已修复（Fixed）：这些版本的产品已经包含对该漏洞的修复

以SBOM为例，它推动了机器可读构件和文档的发展，可以更好地实现自动化、准确性并提升效率。在 NIST 的开放安全控制评估语言（OSCAL）中我们也能看到类似的趋势，该语言将传统的基于书面的安全控制和授权文件转换成机器可读的格式。

VEX正在做类似的事情，避免通过电子邮件发送安全公告或有关漏洞和建议的细节，而是将这些信息转换为机器可读格式，进而可以使用现代化的安全工具进行自动化操作。随着对软件供应链透明度和安全性越来越受到重视，我们不难想象这样一个世界：企业软件清单能够在仪表盘和工具中被可视化，同时还有其相关的漏洞和漏洞的实际可利用性，所有这些都是依靠SBOM和VEX数据呈现的。

但实际情况与之相反，在现代生态系统中，大多数组织都没有他们所消费和部署的软件组件的准确清单，也没有与之相关的漏洞信息。尽管现实中现代软件绝大多数是由开源软件（OSS）组件组成的（有些估计高达80%至90%），但企业仍不重视SBOM。虽然VEX可由软件供应商生成，但也可以由第三方生成，让用户决定如何使用数据。进而，我们会看到安全人员和安全漏洞厂商会尝试为产品制作VEX，作为其服务的一部分。

2022年，CISA发布了两个VEX文档。一个是VEX用例文档，另一个是VEX状态说明文档。

VEX用例文档提供了VEX文件的最少数据组件，与SBOM中的最少组件定义类似。在这一文档中，它说明了VEX文档必须包含VEX源数据、产品细节、漏洞细节和产品状态。产品状态细节包含产品中的漏洞状态信息——是否受影响、是否修复还是仍在调查中。

VEX状态说明文档的重点是要求VEX文件包含一个理由说明，说明为什么VEX文件创建者认为产品的状态不受影响。这使得供应商必须提供产品不受漏洞影响的理由，如组件或易受攻击的代码不存在、易受攻击的代码不能被对手控制或代码不在执行路径中以及产品中已存在内置的缓解措施。

VEX将成为SBOM可落地的关键一步，它提供产品供应商关于其产品中存在的漏洞的可利用性的上下文见解和说明。通过使用为VEX文件定义的最少要素及其相关的不受影响的理由字段，可以让软件消费者做出风险知情决定，以推动其漏洞管理行为成为网络安全计划的一部分。