「网络安全常用术语解读」漏洞利用交换VEX详解

漏洞利用交换（Vulnerability Exploitability eXchange，简称VEX）是一个信息安全领域的标准，旨在提供关于软件漏洞及其潜在利用的实时信息。根据美国政府发布的用例(PDF)，由美国政府开发的漏洞利用交换(VEX)使供应商和用户都能够专注于构成最直接风险的漏洞，可避免在没有实际影响的漏洞上浪费时间。本文接下来会详细介绍VEX，包括其产生背景、维护组织以及主要内容。

1. 产生背景

随着信息技术的快速发展，软件安全漏洞成为网络安全的重要威胁之一。黑客通过利用这些漏洞，可以进行网络攻击，窃取敏感信息，甚至破坏关键基础设施。为了提高对漏洞和其潜在利用的响应速度和效率，需要有一个统一的、标准化的信息交换机制，使得安全研究人员、软件开发者、安全运维人员以及相关组织能够及时共享和更新漏洞信息。在这样的背景下，VEX标准应运而生。

2. VEX简介

VEX（Vulnerability Exploitability eXchange），即漏洞可利用性交换，是一个软件生产者与软件消费者共享其软件组件中存在的漏洞评估的系统。VEX提供了一种一致且标准化的方式来描述漏洞，包括漏洞的标准详细信息，如严重性、影响软件。还包括对漏洞的分析，例如漏洞是否可被利用，以及如何减轻或修复漏洞，以及可用于防范的任何已知解决方案。VEX是软件生产商对其软件中的漏洞进行分类和标记的机制。

VEX标准是由开放式标准组织OASIS（Organization for the Advancement of Structured Information Standards）维护的。OASIS CSAF（Common Security Advisory Framework）技术委员会负责VEX的制定和更新，其目的是推动安全信息的标准化和互操作性。虽然VEX概念是为了满足软件材料清单（SBOM）使用方面的特殊需求而开发的，但VEX并不局限于与SBOM一起使用，也不一定会包含在SBOM中。

3. VEX内容

VEX文档是产品信息、漏洞信息和相关状态详细信息的绑定。VEX文档的最小数据元素必须包括VEX元数据、产品详细信息、漏洞详细信息和产品状态。

VEX元数据必须包括：VEX格式标识符、VEX文档的标识符字符串、作者、作者角色、时间戳。
产品详细信息必须包括：产品标识符或产品系列标识符（例如，唯一标识符或供应商名称、产品名称和版本字符串的组合，如既定SBOM指南中所述）
漏洞详细信息必须包括：漏洞标识符（CVE或其他标识符）和漏洞描述（如CVE描述）
产品状态详细信息（即有关该产品中漏洞的状态信息）必须来自以下列表：
- 不受影响：不需要对此漏洞进行补救
- 受影响：建议采取措施补救或解决此漏洞。
- 已修复：这些产品版本包含针对该漏洞的修复程序。
- 分析中：目前尚不清楚这些产品版本是否受到该漏洞的影响。更新将在稍后的版本中提供

其他VEX内容细节，如CVSS分数或到其他资源的链接，可以添加到VEX文档中，为客户增加价值。本文档介绍了每个用例所需的最小字段。产品状态字段中的状态信息在第4节中的3.1.1用例中介绍。

若想了解详细内容，可以参阅如下两个官方发布文档：

vex_one-page_summary.pdf (访问密码: 6277)
VEX_Use_Cases_Aprill2022.pdf (访问密码: 6277)

4. 使用案例

利用VEX可以清晰明了的体现下图中的漏洞影响场景，比如用例3.1.1表示单一产品、单一版本、单一漏洞、单一状态，用例3.2.2表示单一产品、单一版本、多个漏洞、单一状态。3.1.1这个用例表明公司要在在不同的VEX文档中对其产品的每个版本进行声明。对于给定产品的给定版本，特定漏洞只能具有单一状态。
在这里插入图片描述

假设Example Company获悉Log4j及其相关CVE2021-44228的安全漏洞。下面介绍了4种潜在的VEX状态，并分别举例说明：

不受影响：示例公司有一个ABC产品。当第一个Log4Shell漏洞（CVE-2021-44228）被披露时，Example Company的产品安全事件响应小组（PSIRT）发布了一份VEX文件，声明4.2版中的产品ABC不受影响。Example Company之所以作出此断言，是因为带有易受攻击代码的类在发货前已被删除。示例VEX文件

注意：为了告诉消费者为什么产品不受影响。在本例中，声明是易受攻击的库的“具有易受攻击代码的类在发货前已删除”
受影响：示例公司的产品DEF使用易受攻击的版本。DEF版本1.0中的Log4j库。当第一个Log4Shell漏洞（CVE-2021-44228）披露时，Example Company的PSIRT发布了一份VEX文件，声明产品DEF受到影响，客户应更新到产品DEF的1.1版本。示例VEX文件

为了告诉消费者他们应该这样做。在这个例子中，行动声明是“客户应该更新到产品DEF的1.1版本，这可以解决问题。”
分析中：示例公司有GHI产品。当第一个Log4Shell漏洞（CVE-2021-44228）被披露时，Example Company的PSIRT发布了一份VEX文件，声明目前正在调查GHI的17.4版本是否受到CVE-2021-4 4228的影响。示例VEX文件

预计VEX文件将在稍后的某个时间点更新分析结果。
已修复：示例公司有一个使用1.0版Log4j库的产品DEF。当第一个Log4Shell漏洞（CVE-2021-44228）被披露时，Example Company的PSIRT发布了一个更新和一份VEX文件，声明产品DEF版本1.1已修复。示例VEX文件

此状态主要与受影响状态结合使用（即，以前的版本受到影响，当前版本已修复），但也可以用作独立状态。

VEX补充了SBOM，并可用于提供产品或多个产品中给定漏洞的最新状态。它还可以用于提供单个产品中多个漏洞的状态。

SBOM是组成一个软件的所有组件的清单。它包括每个组件的详细信息，如名称和版本。我们可以使用SBOM来查找软件包的某个版本是否存在任何已知的漏洞，但SBOM只会告诉我们漏洞是否会影响这些软件组件，而不会影响应用程序。VEX允许团队不仅交流影响这些软件组件的漏洞，还解释这些漏洞是否会影响应用程序。

5. VEX给漏洞管理带来的诸多好处

VEX（Vulnerability Exploitability eXchange）标准为漏洞管理带来了多方面的好处，这些好处可以概括为以下几个核心点：

标准化和结构化信息：VEX提供了一种标准化的信息交换格式，使得不同组织之间可以交换漏洞信息，而不必担心格式不兼容的问题。这种标准化也有助于自动化工具的处理和分析。
提高信息共享效率：通过VEX，安全研究人员和利益相关者可以更容易地分享和获取漏洞信息，降低了误解和沟通成本，从而提高整个行业的安全水平。
实时更新和响应：VEX允许实时更新漏洞信息，这意味着安全团队可以迅速了解新发现的漏洞，并据此更新防御措施。
跨供应链协作：VEX与软件材料清单（SBOMs）结合，可以帮助供应链中的所有环节了解和应对共享的漏洞风险，从而加强整个软件供应链的安全性。
支持多漏洞和多产品管理：VEX可以同时处理多个漏洞和多个产品，这对于大型企业和复杂的软件生态系统来说尤其重要。
支持自动化工具：VEX设计时考虑了自动化处理的需求，使得安全工具和系统可以更容易地集成和利用VEX数据。
帮助制定修复策略：通过VEX提供的漏洞利用难度等详细信息，组织可以更有效地制定修复漏洞的优先级和策略。
提升用户意识：VEX标准化的安全咨询格式有助于用户更好地理解和响应安全通知，提高用户的安全意识和行动力。

总体而言，VEX通过提供一种标准化、结构化和实时的漏洞信息交换方式，极大地提高了漏洞管理的效率和效果，有助于组织更有效地保护其信息系统免受漏洞威胁。

6. 附：VEX样例

{
  "document": {
    "category": "csaf_vex",
    "csaf_version": "2.0",
    "notes": [
      {
        "category": "summary",
        "text": "Example Company VEX document. Unofficial content for demonstration purposes only.",
        "title": "Author comment"
      }
    ],
    "publisher": {
      "category": "vendor",
      "name": "Example Company ProductCERT",
      "namespace": "https://psirt.example.com"
    },
    "title": "Example VEX Document Use Case 1 - Fixed",
    "tracking": {
      "current_release_date": "2022-03-03T11:00:00.000Z",
      "generator": {
        "date": "2022-03-03T11:00:00.000Z",
        "engine": {
          "name": "Secvisogram",
          "version": "1.11.0"
        }
      },
      "id": "2022-EVD-UC-01-F-001",
      "initial_release_date": "2022-03-03T11:00:00.000Z",
      "revision_history": [
        {
          "date": "2022-03-03T11:00:00.000Z",
          "number": "1",
          "summary": "Initial version."
        }
      ],
      "status": "final",
      "version": "1"
    }
  },
  "product_tree": {
    "branches": [
      {
        "branches": [
          {
            "branches": [
              {
                "category": "product_version",
                "name": "1.1",
                "product": {
                  "name": "Example Company DEF 1.1",
                  "product_id": "CSAFPID-0001"
                }
              }
            ],
            "category": "product_name",
            "name": "DEF"
          }
        ],
        "category": "vendor",
        "name": "Example Company"
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2021-44228",
      "notes": [
        {
          "category": "description",
          "text": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.",
          "title": "CVE description"
        }
      ],
      "product_status": {
        "fixed": [
          "CSAFPID-0001"
        ]
      }
    }
  ]
}