VEX 的未来会怎样?它会对你产生什么影响?

所有文章

新漏洞的披露速度不断增加。目前,每年平均有 15,000 个 CVE。 2022 年报告的新 CVE 数量超过 26,000 个。显然,并非所有漏洞都与您的软件相关。要确定某个特定漏洞是否存在问题,您首先需要确定您是否正在使用包含该漏洞的库或产品,然后确定您是否正在使用该库的有问题的版本和模块。最后,您需要咨询您的开发团队,了解该漏洞是否与您的特定产品以及您使用该漏洞库或产品的方式相关。

弄清楚这一切的过程并不简单,并且可能需要相当多的时间。著名网络安全专家 Tom Alrich 估计 特定软件产品中存在的所有 CVE 中约有 95% 不可利用。但是,如果您是最终用户或即将将第三方软件集成到其系统中的公司,您如何识别有问题的 5%,以便可以要求适当的修复或修补?

这就是想法的所在 漏洞利用交换(VEX)登场。 VEX 的目的,定义为 指导 美国国家电信和信息管理局 (NTIA) 于 2021 年发布的规定是“向用户(例如运营商、开发商和服务提供商)提供有关产品是否受到所包含组件中的特定漏洞影响的附加信息,以及如果受到影响, ,是否有建议采取的补救措施。”  

现在您可能在想 – 那么我怎样才能获得这些 VEX 文档,并开始检查我的组件呢?嗯,VEX 使用的现实和往常一样很复杂。

探索 VEX 的目的

简而言之,VEX 应该能够快速、轻松地回答“我的软件版本是否可以被利用”的问题。 脆弱性?.

这个问题的答案应该是四个主要选项之一:

  • 不受影响: 无需针对此漏洞进行修复。
  • 做作的: 建议采取措施修复或解决此漏洞。
  • 固定: 这些产品版本包含针对该漏洞的修复程序。
  • 在调查中: 目前尚不清楚这些产品版本是否受到该漏洞的影响。将在以后的版本中提供更新。

由于 VEX 应该是机器可读和机器生成的,因此我们的想法是在某个地方建立一个这些文档的可搜索数据库,以便任何感兴趣的各方都可以查询它并获得所需的答案。 

由于假设 95% 的漏洞在任何给定的软件产品中都不可利用,因此该系统旨在将每个产品发现的大量漏洞列表精简为用户应关注或请求修复或修补的漏洞为了。 

关于 VEX 的历史有许多有趣的事实

早在 2020 年,NTIA(美国国家电信和信息管理局)开始讨论 VEX 作为辅助工具的想法 斯博姆 (软件物料清单)。 2021 年 XNUMX 月,NTIA 发布了一页的介绍和解释 VEX 的用途。

后来,在 CISA(美国网络安全和基础设施安全局)的支持下,完善新咨询格式的要求,该机构发布了自己的咨询格式要求。 文件 2022 年初,我们会更详细地介绍 VEX 文档应该提供帮助的一些用例。该文档(草案)定义了 VEX 文档的最少必需字段,其方式与 NTIA 定义 SBOM 的最少必需字段的方式相同。 

从那时起,在实际创建机器可读的 VEX 文档格式方面进行了两次主要尝试:

  • 这款 通用安全咨询框架 (CSAF) 是第一个可用的格式。该格式由 OASIS Open 于 2022 年底发布,OASIS Open 是一家国际非营利组织,致力于为网络安全、区块链、物联网和其他领域制定开源标准。
  • 旋风分离器 DX, OWASP(开放式 Web 应用程序安全项目)推出的 SBOM 标准化格式,也适用于创建 VEX 文档。

CSAF 是一种综合格式,但为了实际成功使用它,您需要包含多个字段和大量元信息,这使得实际采用不太可能。CyclonDX VEX 计划要小得多,因此在考虑使用哪种 VEX 标准时,大多数人可能会选择与 CyclonDX 格式。

为什么 VEX 遇到了障碍 – 揭示阻碍其成功的问题

VEX 是一个好主意,可以提供快速检查特定漏洞是否确实可以在特定软件产品中利用的宝贵能力。 

然而,到目前为止,有几个问题阻碍了其实施:

  • 提交责任 – 谁应该负责提交所需的 VEX 文件?是软件生产商吗?第三方安全公司或非营利组织?政府机构?如果多个来源提交的信息相互矛盾,会发生什么情况?
  • VEX 数据库 – 谁或什么应该保存和分类 VEX 信息?假设某些文档描述了软件中的可利用问题,那么是否存在信息落入错误(恶意)之手的危险?
  • 当前的格式没有正确解决版本问题,更没有解决组合版本控制的问题。
    组合软件/软件包版本是指将多个软件包或组件捆绑在一起形成单个发行版或安装包的做法。 

当涉及到漏洞修补时,组合的软件/软件包版本既可以帮助也可以阻碍该过程。一方面,拥有一个包含所有必要组件的安装包可以简化识别和修补漏洞的过程。您无需手动识别和修补每个单独的组件,只需将补丁应用到整个包即可。

然而,另一方面是,如果软件包中的一个组件容易受到攻击,那么整个软件也会容易受到攻击。这意味着,即使包中的某些组件已修补,如果存在单个未修补的组件,整个包仍可能面临风险。 

假设您的软件中库 A 的版本 1 有一个漏洞。仅当库 A 与库 B 的版本 2 一起存在时,该问题才会显现出来。有一个安全补丁,但并非每个人都会安装它。这意味着您的软件中该漏洞的 VEX 文档需要涵盖产品、其版本、其包含的库、其版本以及可能发布的补丁的所有可能组合。这是很多复杂的信息,不容易简单地表达。

  • VEX 将如何覆盖嵌入到硬件中并提供所有可能版本和补丁的软件?考虑到您无法轻易打开硬件并自行修补,谁有责任修补该软件?

这些只是任何处理 VEX 的自动工具需要理解和考虑的一些问题。 

如果您可以请求并获取任何版本的信息,不是更容易吗?

认为共享此重要信息的最佳方式是通过文档的假设可能是错误的。生成足够的 VEX 文档来涵盖版本、补丁和漏洞的每种组合是一项艰巨的任务,可以理解的是,没有人愿意承担这项任务。

刻划式打标系统 构建了一个平台,用于跟踪和共享特定软件项目或产品的每个版本的安全相关信息。作为其中的一部分,每个构建都会生成准确的 SBOM 和产品中发现的漏洞列表。

Scribe 使软件生产商能够向每个漏洞添加 VEX 格式的建议,以说明它们是否不可利用、正在调查等。版本发布后,有关该版本的所有安全信息都可以与感兴趣的第三方、用户共享、监管机构等。包括漏洞列表以及 VEX 咨询列表意味着接收者应该能够仅查看该特定产品中存在潜在问题的漏洞。它减轻了可以将其产品“列入白名单”的软件生产商和确切了解特定软件产品所涉及的风险级别的软件消费者的很大负担。

由于软件生产商是唯一可以明确地说特定漏洞实际上是否与产品的特定版本相关的人,因此他们是唯一可以在自己的产品上添加和修改建议的人。软件生产商对此的判断是最终的且不可争议的。与谁共享此信息的决定也是软件生产商的特权。

由于 Scribe 保存了产品构建、SBOM 和安全信息的完整历史记录,因此用户可以轻松请求并获取他们在整个软件生命周期中可能使用的任何版本的此信息。  

旗帜

结语

请记住,如今对软件产品进行任何适当的扫描都会产生数百甚至数千个可能的漏洞。大多数人无法应对这样的数字。警报疲劳开始出现,漏洞的数量就变成了一个数字。

将检测到的问题数量减少到可管理的数量的可能性对于软件生产者和用户来说是一个福音。目的是只关注真正的问题,以便软件生产商能够尽快修补和修复它们。 

自动化工具,例如 刻划式打标系统 提供了一种简单的方法来仅查看每个项目和构建的相关漏洞,您可以轻松共享信息,从而使漏洞之山显着缩小且更易于管理。

但一个重要的警告是,如果没有开源社区的积极参与,我们可以轻松地看到并仅对相关漏洞做出响应的未来是不可能实现的。如今,大多数代码都由大量开源软件组成,因此我们需要此类库的维护者和开发人员参与发现和修复困扰其代码的可利用漏洞。 

相关的、可利用的漏洞问题不会消失,因此我们所有人都应该找到最有效、最具成本效益的方法来回答这个问题:“我的这个软件版本是否可被利用” 脆弱性”.

此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多