本文編譯自:Google Blog

對於患者及醫生來說，診斷和治療慢性疾病是複雜、困難且充滿不確定性的。根據患者的情況和醫生知識，做出正確的診斷需要時間，並且需要嘗試不同的治療方法。

這種反覆驗證的過程會讓患者陷入痛苦和困惑，直到開出最好的治療方法，這種情況類似於當今許多安全運營團隊面臨的日常鬥爭。

盲目的“修補它！”， 當安全團隊不確定應用補丁是否會產生更嚴重的問題（如崩潰、不兼容或停機時間）時，這並非很有幫助。應該先確定優先修補哪些漏洞，並確保這些修復會為您提供更安全的系統，是安全團隊可能面臨的最艱鉅的任務之一。這就是漏洞可用性交流(VEX) 的用武之地。

先前，討論過如何建立對患者安全和技術的可見性和意識對於創建有彈性的醫療保健系統至關重要，並研究了將軟體物料清單 (SBOM) 與 Google 的軟體工件供應鏈級別(SLSA) 框架相結合如何幫助建構更安全的技術以實現彈性。

SBOM 提供正在使用的軟體及其來源的可見性，而 SLSA 提供的指南有助於提高建構軟體的完整性和安全性。使用 VEX 將快速診斷評估添加到該等式中，國家電訊和訊息管理局將其描述為與 SBOM 並存的“伴侶”文件。

回到醫學比喻，VEX 是一種讓軟體供應商提供給安全團隊應該要在哪裡尋找痛苦根源的機制。當需要在特定時間點捕獲庫存和漏洞數據時，VEX 數據可以幫助進行軟體審核。該數據還可以嵌入到自動化安全工具中，更輕鬆地確定漏洞修補的優先順序。

然後，可以將 SBOM 視為藥瓶上的處方標籤，將 SLSA 視為確保藥物安全的兒童保護蓋與防篡改封條，將 VEX 視為瓶子的安全警告。作為診斷助手，VEX 可以幫助安全團隊在壞人之前準確診斷什麼可能造成傷害和系統弱點。

然而，準確評估該威脅模型可能具有挑戰性，尤其是在查看用於運行系統的軟體時，能否快速準確地評估組織的弱點和痛點的能力，對於加快對漏洞的反應和在網路攻擊變得具有破壞性之前阻止它們至關重要，VEX 是幫助確保軟體供應鏈安全的重要組成部分。

舉個例子，2021 年 12 月發生的Apache Log4j 漏洞。當 Apache 的 Log4j 2 日誌系統被發現如此脆弱以至於相對簡單的威脅行為者可以迅速滲透並接管系統時，包括醫療保健在內的全球行業受到了打擊。通過Google 進行的研究和CISA提供的訊息， Log4j 2（單個軟體組件）中的漏洞可能會影響成千上萬依賴它的軟體公司，因為它幾乎無處不在。

雖然 VEX 不會捕獲零日漏洞，但它可以將 Log4j 2 中的其他已知漏洞通知安全團隊。一旦發現漏洞，安全團隊可以使用 SBOM 找到它們，並使用 VEX 了解是否需要補救。

關注 SBOM 和 SLSA 等可見性機制的一個關鍵原因是，它們使我們能夠了解風險。如果沒有能力了解必須保護的內容，就很難確定如何快速降低風險。

可見性是阻止惡意黑客的關鍵第一步。然而，如果沒有上下文，可見性會讓安全團隊不堪重負的數據。根據開源漏洞數據庫(OSV) ，當嘗試緩解僅影響開源軟體的 30,000 個已知漏洞時，會從哪裡開始呢？NIST 的國家漏洞數據庫(NVD) 正在追踪近 181,000 個漏洞。如果採用“修補一切”的方法，將在下一個千年進行修補。

不可能單獨解決每個漏洞，為了取得進展，安全團隊需要確定漏洞的優先順序，並關注影響最大的漏洞，VEX 的目標是使優先順序更容易一些。

雖然 SBOM 是在更新中創建或更改的，但 VEX 主要是在新的漏洞或威脅發生更改時進行修改和分發。意味著 VEX 和 SBOM 應該分開維護，由於安全研究人員和組織不斷發現新的網路安全漏洞和威脅，因此，像 VEX 這樣更動態的機制可以幫助運營商快速確定軟體的風險。

讓我們深入研究 CycloneDX中的 VEX 案例。可以看到發現的漏洞列表、追踪和報告漏洞的第三方、每個 CVSS 的漏洞評級，最重要的是，開發人員的聲明可以指導操​​作員閱讀 VEX 以了解可利用且需要保護的漏洞。

此訊息允許 VEX 文件的用戶參考其配套的 SBOM，必要時，VEX 有意與 SBOM 分離，因為它們需要在不同的時間進行更新。當出現新的漏洞時，需要更新 VEX 文檔，當製造商對軟體進行更改時，需要更新 SBOM。儘管它們需要單獨更新，但每個文檔的內容可以保持一致，因為它們是相互連動的。

VEX 可以顯著改善安全漏洞的處理方式。發現操作員被埋在漏洞中的情況並不少見，他們猜測需要修復的漏洞，並嘗試理解數十頁（有時是數百頁）的文件以確定最佳、影響最小的修復。

通過 SBOM+SLSA+VEX，運營商正在使用以軟體驅動機制來進行風險分析和評估，而不是依賴直覺和最佳猜測。SBOM+SLSA+VEX 提供了最新的問題清單和需要關注的觀點，這是安全領域的變革性發展——使團隊能夠更好地處理漏洞，從可能造成最大傷害的地方開始。

在醫療保健等基礎設施遭受反覆網路攻擊的推動下，政府監管機構對軟體安全和供應鏈採取了更感興趣的立場，加強 SBOM 的有效性是組成新戰略的重要部分。

保護和改造網路醫療保健 (PATCH) 法案，將要求醫療設備製造商在其產品中遵守最低網路安全標準，包括為其設備創建 SBOM，計劃監控和修補在設備生命週期內發現的任何網路安全漏洞。

與此同時， FDA 新的醫療器材網路安全指南草案繼續參與，積極鼓勵醫療器材製造商提高其產品的網路安全性。美國白宮也代表 SBOM，2021 年 5 月的一項行政命令規定了安全軟體開發的要求，包括為聯邦政府使用的軟體生產和分發 SBOM。

無論這些措施取得什麼成果，Google 都認為 SBOM+SLSA+VEX 提供的控制對於保護軟體和建立有彈性的醫療保健生態系統至關重要。為安全團隊提供詳細的、關鍵的風險數據，方便採取必要的措施來降低即時和長期風險。

Google正與開源安全基金會合作支持 SBOM 開發。關於安全軟體開發的“了解、預防、修復”報告更廣泛地概述了 Google 如何保護開源軟體免受可預防漏洞的影響。從Google的雲端架構中心可以了解更多關於如何保護 Google Cloud 上工作負載的訊息。例如Cloud Build，這是一項可用於生成最高 SLSA 2 級建構工件的 Google Cloud 服務。

由於依賴開源軟體 (OSS)，客戶通常難以全面了解和控制漏洞。Assured Open Source Software (Assured OSS) 是一項 Google Cloud 服務，可幫助團隊保護外部 OSS 軟體包，並通過簡單地從代碼庫中消除它們來克服可避免的漏洞。

請向神通資科洽詢 Google 的網路安全行動，這是一流的安全諮詢團隊，以及支持政府、關鍵基礎設施、企業和小型企業的安全和數位化轉型的獨特使命。