VEX：漏洞可利用性交換（Vulnerability Exploitability eXchange）文件說明了什麼

什麼是 VEX？

VEX 是 Vulnerability Exploitability eXchange（漏洞可利用性交換）的縮寫，是一份說明產品是否受到特定已知漏洞影響的機器可讀聲明。供應商發布它，讓產品的使用者知道哪些漏洞需要採取行動、哪些不需要。在大多數組織中，供應商端的這項工作由 產品資安事件應變小組（PSIRT）負責。

CISA 的 Minimum Requirements for VEX （2023 年 4 月）以不依賴任何檔案格式的方式定義 VEX：VEX 文件是一個或多個 VEX 聲明的容器，而每個聲明針對一個或多個產品中的一個漏洞給出一種狀態。VEX 的設計是與 SBOM、漏洞資料庫及資安公告搭配運作，但並不依賴其中任何一項。

VEX 為何存在：SBOM 的雜訊

SBOM 列出產品中的每個元件，包括遞移相依套件。掃描器會將這些元件與資安公告比對，並回報它找到的每個版本中的每個 CVE。其中許多檢測結果並不適用：有漏洞的函式從未被呼叫、某個建置選項在編譯時將其排除，或產品的組態阻擋了攻擊。沒有 VEX，每位客戶都必須自行釐清，或開立支援工單詢問供應商。

VEX 將這項分析交給能一次為所有人完成的一方：供應商。客戶的掃描器讀取 VEX 文件，並隱藏供應商已標示為不影響產品的檢測結果。

VEX 只是幾種手段之一。如何減少漏洞雜訊依序整理了這些手段，第一步是建立與您出貨內容相符的資產清冊。

四種 VEX 狀態

每個 VEX 聲明都只帶有四種狀態中的一種：

狀態	意義	另需提供
not_affected	不需要修補或緩解。此漏洞不影響所列產品。	理由，或說明原因的影響聲明
affected	此漏洞影響所列產品，作者建議採取行動。	行動聲明：使用者應採取的措施
fixed	所列產品版本已包含修正。	無須額外提供
under_investigation	作者正在調查，尚未做出判斷。	無須額外提供；預期會變更

not_affected 的 VEX 理由

not_affected 聲明必須說明原因。CISA 的要求指出，它 SHOULD 使用五種理由之一，若未使用，則 MUST 提供自由文字的影響聲明。OpenVEX 與 CSAF 使用相同的五種理由：

• component_not_present：產品中不包含有漏洞的元件。
• vulnerable_code_not_present：產品包含該元件，但不包含有漏洞的程式碼，通常是因為其組態或建置方式。
• vulnerable_code_not_in_execute_path：有漏洞的程式碼存在，但產品從未呼叫它。
• vulnerable_code_cannot_be_controlled_by_adversary：程式碼存在且會被使用，但攻擊者無法控制它來利用該漏洞。
• inline_mitigations_already_exist：使用者無法停用的內建防護機制可防止漏洞遭到利用。

各種理由所需的佐證資料不同。component_not_present 需要一份準確記錄產品內容的資料。中間三種需要程式碼分析，例如可達性分析或人工審查，也是客戶最常質疑的理由。

VEX 聲明包含哪些內容

CISA 的最低要求列出了以下要素：

• 文件中繼資料：文件 ID、每次變更都會遞增的版本、作者（個人或組織，而非工具），以及首次發布與最後更新的時間。
• 產品細節：一個或多個產品識別碼，最好與產品 SBOM 使用的識別碼相同，例如套件 URL（purl）。聲明也可以指出帶有該漏洞的子元件。
• 漏洞細節：每個聲明一個漏洞 ID（通常是 CVE），以及說明或指向說明的連結。
• 狀態，以及該狀態所要求的理由、影響聲明或行動聲明。
• 聲明中繼資料：聲明本身的 ID、版本與時間戳記。

VEX 文件範例

以下 OpenVEX 文件說明，產品 example-api 3.2.0 雖然出貨了有漏洞的 log4j-core 版本，但不受 Log4Shell 影響，因為有漏洞的類別在建置時已被移除：

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

產品及其子元件以套件 URL 識別，因此掃描器可以將它們與產品 SBOM 中的元件比對。以 CycloneDX 或 CSAF 表達的相同聲明，會以不同的結構承載相同的事實。

VEX 格式：OpenVEX、CycloneDX VEX 與 CSAF VEX

VEX 是一組要求，而非一種檔案格式。CISA 列出了三種可以承載 VEX 的格式，而且它們無法互換：

	OpenVEX	CycloneDX VEX	CSAF VEX
它是什麼	專為 VEX 設計的小型 JSON 格式	CycloneDX 文件中的 vulnerabilities 區段	CSAF 資安公告標準的 csaf_vex 設定檔
標準	開放規格，v0.2.0	ECMA-424（CycloneDX 1.6 及更新版本）	OASIS Standard（CSAF 2.0，2022 年）
狀態	四種 VEX 狀態	自有的分析狀態：not_affected、exploitable、in_triage、 resolved、resolved_with_pedigree、false_positive	產品狀態清單：known_not_affected、known_affected、fixed、 under_investigation
理由	CISA 的五種理由	自有的九種理由，例如 code_not_reachable 與 requires_configuration	CISA 的五種理由，以旗標表示
適合的團隊	希望 VEX 檔案越小越好	已在出貨 CycloneDX SBOM	已在發布 CSAF 資安公告
Trivy 是否讀取	是	是，用於 SBOM 掃描	是
Grype 是否讀取	是	未列出	是

OpenVEX 最為輕量：一份包含作者、時間戳記、版本與聲明清單的文件。其 規格將 VEX 視為一連串的聲明，每個聲明都會覆寫或補充先前的聲明。

CycloneDX VEX 使用 CycloneDX 處理其他所有內容時所用的同一個 vulnerabilities 結構，其中的 analysis 物件包含狀態、理由、回應值（例如 update 或 will_not_fix）以及自由文字的細節。VEX 資料可以放在 SBOM 內，也可以放在另一份以 BOM-Link 指向 SBOM 的 CycloneDX 文件中。請注意，它的理由用語與 CISA 的不同，因此與 OpenVEX 或 CSAF 互相轉換時需要對應表。SBOM 方面的比較請參閱 CycloneDX 與 SPDX 比較。

CSAF VEX 是類別為 csaf_vex 的完整 CSAF 文件。它需要產品樹、CVE 或其他 ID、附註，並且針對每個產品提供影響聲明（若不受影響）或修補方式（若受影響）。它比 OpenVEX 更繁重，但適合已透過 CSAF 提供者發布 CSAF 資安公告的組織。

VEX 與 VDR 的比較

漏洞揭露報告（Vulnerability Disclosure Report，VDR）列出確實影響產品的漏洞，並附上其分析與修補方式。NIST SP 800-161 將 VDR 列為建議的供應鏈實務，而 CycloneDX 兩者皆支援。兩者的差異，如 CycloneDX 範例 所述：

• VDR 說明哪些漏洞影響產品。它可以涵蓋在您自己程式碼中發現、從未在其他地方公開的漏洞。
• VEX 主要是否定性的聲明：哪些已知漏洞不影響產品，以及原因。它只涵蓋已知漏洞。

許多供應商兩者都會發布：VDR 回答「我需要修正什麼」，VEX 回答「我可以忽略什麼」。

掃描器如何使用 VEX

只有在客戶的工具會讀取 VEX 文件時，它才能真正省下工作。兩款廣為使用的開源掃描器都支援：

• Trivy 透過其 --vex 選項 （標示為實驗性功能）接收 VEX，來源可以是本機檔案、VEX 儲存庫、OCI 證明或 SBOM 中的參照。它可讀取 OpenVEX、用於 SBOM 掃描的 CycloneDX VEX 以及 CSAF VEX，並停止回報標示為 not_affected 的漏洞。
• Grype 透過 --vex 接收 OpenVEX 與 CSAF VEX。它會將 not_affected 與 fixed 的比對結果移到忽略清單（可用 --show-suppressed 顯示），並可選擇將 affected 與 under_investigation 聲明加入結果中。

比對取決於識別碼。如果 VEX 使用與 SBOM 不同的識別碼來指稱產品，掃描器就無法將兩者連結，檢測結果也會保留下來。

誰發布 VEX

VEX 通常來自供應商：出貨產品的廠商、開源發行版或裝置製造商。在供應商內部，這是 PSIRT 的任務，屬於產生資安公告與修正的同一個 漏洞管理生命週期。例如，Red Hat 會在其 CSAF 資訊來源的專屬目錄中發布 CSAF VEX 文件，與其資安公告並列。PSIRT 工程師的日常工作，請參閱 PSIRT 角色。

客戶也會為自己撰寫 VEX，記錄對供應商產品的分級研判決策，讓自己的掃描器不再提出這些項目。歐盟 Cyber Resilience Act（CRA）等法規要求製造商處理其出貨元件中的漏洞，而 VEX 是告訴使用者哪些漏洞適用的一種方式。

保持 VEX 最新

• 狀態會變動。聲明通常從 under_investigation 開始，最後成為 not_affected，或先成為 affected 再變為 fixed。每次變更都要發布；CISA 要求版本每次都必須遞增。
• 新版本需要新的聲明。針對 3.2.0 的 not_affected 判定，無法說明 3.3.0 的情況。每當元件、其版本或建置組態變更時，都要重新檢查。
• 將 VEX 與 SBOM 分開。SBOM 描述一個版本，內容固定不變。VEX 在版本發布後仍會持續變動，因此將它作為獨立文件發布，可避免重新發布 SBOM。
• 發布在工具會查找的地方。放在 SBOM 旁邊、作為容器映像檔上的證明，或放在您的資安公告資訊來源中，並在您的揭露政策中說明位置。請參閱 協同漏洞揭露。

VEX 的限制

• 它是主張，而非證明。not_affected 聲明是作者的評估。CISA 建議以密碼學方式將作者身分與文件綁定，但大多數使用者仍是因為信任供應商才信任 VEX。
• 沒有聲明不代表任何事。VEX 不隱含任何預設狀態。沒有聲明的漏洞是未知狀態，而非不受影響。
• 格式之間無法一對一對應。CycloneDX 使用與 OpenVEX 及 CSAF 不同的狀態與理由，因此轉換時會遺失細節。
• 它的品質取決於資產清冊。要說某個元件不存在，就必須確切知道產品包含什麼，包括遞移相依套件，以及建置在套件管理工具之外下載的任何內容。

VEX 始於準確的 SBOM

每個 VEX 聲明都指向元件，而最容易站得住腳的理由 component_not_present，只有在資產清冊完整時才成立。事後掃描 lockfile 產生的 SBOM，可能會列出從未出貨的開發相依套件，並遺漏建置以其他方式取得的套件。

CRACI 在自己的執行器上執行 GitHub Actions 建置，並記錄每個作業實際取用的套件，包括遞移相依套件、從快取還原的套件，以及任何鎖定檔都未列出的相依套件。每份 SBOM 都帶有完整性狀態，並可匯出為 CycloneDX 或 SPDX 格式。受監控的 SBOM 會持續重新評估，建置歷史會顯示哪些過往建置含有有漏洞的相依套件，而且 CRACI 支援 VEX。請參閱 SBOM 產生與 漏洞追蹤。

VEX：常見問題

VEX 代表什麼？

VEX 代表 Vulnerability Exploitability eXchange（漏洞可利用性交換）。它是一份說明產品是否受到特定已知漏洞影響的機器可讀聲明，發布目的是讓使用者知道哪些已通報的漏洞需要採取行動。

SBOM 與 VEX 有什麼不同？

SBOM 列出產品中的元件。VEX 則針對特定漏洞，說明該產品是否受影響。SBOM 在版本發布後很少變更；VEX 聲明則會隨著供應商的調查與修正而變更。因此，VEX 通常以指向該產品的獨立文件發布，而不是直接寫進 SBOM。

四種 VEX 狀態是什麼？

not_affected、affected、fixed 與 under_investigation。not_affected 聲明需要理由或影響聲明，affected 聲明則需要說明使用者應採取什麼措施的行動聲明。

我應該使用哪種 VEX 格式？

使用您的使用者與工具會讀取的格式。OpenVEX 最小，可搭配 Trivy 與 Grype 使用。CycloneDX VEX 適合已在出貨 CycloneDX SBOM 的團隊。CSAF VEX 適合已在發布 CSAF 資安公告的組織，這在工業與企業軟體中相當常見。許多供應商最後都會在這些格式之間轉換。

VEX 與資安公告相同嗎？

不同。資安公告說明一個漏洞、哪些人受影響以及如何修正，主要是給人閱讀。VEX 則是針對每個產品與漏洞、範圍狹窄的機器可讀狀態，主要是給工具使用。兩者經常一起提供：CSAF 標準同時具有資安公告設定檔與 VEX 設定檔。

誰撰寫 VEX 文件？

通常是產品的供應商，往往是其產品資安事件應變小組（PSIRT），因為他們了解產品如何建置與設定。CISA 的最低要求也允許第三方撰寫 VEX，而且每份文件都必須註明作者。

漏洞掃描器會讀取 VEX 嗎？

有幾款會。Trivy 透過其 --vex 選項接受 OpenVEX、CycloneDX 與 CSAF VEX，並捨棄標示為 not_affected 的檢測結果。Grype 透過 --vex 接受 OpenVEX 與 CSAF VEX，並將 not_affected 與 fixed 的檢測結果移到忽略清單。