SBOM
雖說 VEX 並不盡然需要依賴於 SBOM，但在討論 VEX 之前，肯定必須先了解一下 SBOM（Software Bill of Materials, 軟體物料清單），因為這樣才能了解 VEX 的必要性和它所想解決的問題。
軟體物料清單提供了軟體組成的相關資訊。這些相關資訊會說明這些組成是由誰提供、由誰開發、包含哪些項目、何時建置和依賴訊息等訊息。這些資訊對於提升軟體的透明度相當有幫助。因為使用者能夠透過這些資訊了解該軟體所採用的套件或其他工具是否存在可被利用的漏洞而需要立即進行修補。
SBOM 之所以受到關注還是要歸因於從 2020 年後的三起重大的資安事件，包括 Solarwinds[1]、燃油管事件[2]和 Log4j[3]。這三個重大資安事件促使美國總統在 2021 年時簽署了行政命令，責令美國商務部和美國國家電信暨資訊管理局（National Telecommunications and Information Administration, NTIA）需要在 60 天內制定 SBOM 的最基本要件。雖然 SBOM 對提升透明度的確有所幫助，但它畢竟仍是一個靜態的資訊。軟體使用者仍需要從軟體供應者處取得該軟體相關組成的漏洞狀態，才能夠進一步確認當前軟體受到漏洞影響的狀態，而 VEX 正是提供此關鍵訊息的機制。
VEX
雖然漏洞代表著一種威脅，但同樣的漏洞在不同使用情境下所代表的威脅程度卻不見得相同，有時甚至不具有任何威脅，比方說所依賴的第三方套件僅有在使用某一功能才會出現漏洞問題，然而使用該套件的軟體並未使用到該功能，那麼即便該套件有漏洞也不代表攻擊者可以透過該漏洞來產生威脅。因此，為了確認是否存在威脅，使用者必須在漏洞被發現時向軟體提供者詢問該漏洞的影響範圍來決定是否進行修補。若此時，漏洞發生在第三方依賴套件時，漏洞是否修補的資訊收集過程將會更費時。即便採用弱點掃描工具來自動化掃描所使用的軟體或工具，也只是獲得所有與該軟體有關的全部可能弱點（包括了不會產生的任何影響的漏洞）。這樣的現況讓相關人員必須無差別地疲於確認每個弱點的影響狀況。此時，若軟體供應者或任何套件的供應者能夠提供即時的漏洞影響訊息，來讓供應鏈上的每個利害相關人取用並且做出判斷，那麼這些往返等待的時間浪費將能夠被降低，進而改善提升安全性的效率。
VEX（Vulnerability Exploitability Exchange）的概念和對應的資訊便是來迎合這個需求。它可以用來說明某軟體：
- 受到哪些漏洞的影響，以及並不受到哪些漏洞的影響；
- 針對受影響漏洞應該採取的行動；
- 哪些版本已經修復該漏洞；
- 是否仍處在調查狀態。
這些資訊將以機械可讀的形式由提供者來提供，所以使用者可以向軟體提供者取得 VEX 文件，以便能夠基於先前取得的軟體物料資訊來持續地了解和追蹤相關漏洞的訊息，構築一個自動化的軟體供應監測機制。
現實的麻煩
SBOM 和 VEX 都能以機器可讀的形式來進行取用，並且使用者可以透過工具來建立自動化的持續監控機制和運用於開發流程的檢查機制中，然而這一切都建立在供應者是否能夠及時並且主動地提供相關的資訊。從軟體開發的角度來看，雖然軟體開發者可以透過依賴套件的組態文件和掃描工具來直接掃出可能產生影響的漏洞，但如同前文所述的情況。在沒有 VEX 訊息的協助下，掃描工具將產生相當多的安全噪音。換言之，產生無效的漏洞告警。因此，若能夠有一種工具可以為正在開發的軟體自動地產生 VEX 文件，這不僅能夠幫助軟體開發者避開無謂的噪音，也能夠協助軟體提供者建立有效的 VEX 文件，而這正是 Kubescape 期望提供的功能。
Kubescape 所扮演的角色
Kubescape 是用於 Kubernetes 的安全工具。它能夠透過 Trivy[4] 和 Grype[5] 來針對映像檔進行弱點掃描，並且將其結果透過監控系統呈現出來，也能夠自動化產出映像檔的 VEX 文件。它的機制是運用 Kubernetes 的 API server 來取得相關的容器資訊，並且基於容器資訊和 eBPF 的機制來觀察容器運行時實際會載入的套件(如下圖)。透過這些資訊，Kubescape 能夠了解容器內實際運行的情況，從而知道依賴套件的相關漏洞是否對該映像檔所運行的容器產生威脅。
透過這種機制可以幫助使用容器來構築服務的組織或提供映像檔的軟體提供者更有效率地產生 VEX 文件，而這將對軟體供應鏈透明度的提升帶來關鍵的幫助。開發人員也能夠透過自動化流水線來構築必要的 VEX 文件並且整合到映像檔的弱點掃描關卡上，進而讓自動化流水線的安全噪音降低，減低開發人員的困擾。此外，也能大大地降低 IT 維運人員和安全人員的麻煩，讓 SBOM 和 VEX 兩者所帶來的好處能夠盡可能無損地被實現。