檔名先被規定好了：微軟驅動簽名的 SBOM 新規，是一份被設計過的信任介面

（事件日期：2026 年 9 月 2 日，微軟於當地時間發布 WHCP 政策調整公告。本文以回顧角度重新檢視其中的文件設計細節。）

一份驅動程式要通過微軟的簽名，從 2027 年 3 月開始，多了一道新的關卡。開發商提交給 Windows 硬體相容性計畫（WHCP）的每一個驅動，都必須附上兩份檔案：一份軟體物料清單（SBOM），一份漏洞可利用性資訊交換聲明（VEX）。缺了任何一份，或者檔案沒通過驗證，微軟就不給簽名。

這則公告多數人會從資安政策的角度讀它。但如果把視線放低，放到公告裡那些看似枯燥的細節上，會發現微軟其實是在設計一套介面。這套介面服務的對象是驅動開發商與微軟的審核系統，而它的核心課題，跟我們平常討論的任何使用者介面一樣：如何讓複雜的資訊，變成可以被機器與人穩定讀取的格式。

從一個檔名開始看

公告裡最值得停下來看的一行，是檔案命名規則。SBOM 檔案必須命名為「<inf_name>.spdx.json」，VEX 則是「<inf_name>.vex.json」。檔名必須與驅動的 INF 檔案一一對應，放在驅動套件目錄下的專用子資料夾，而且不能塞進補充文件目錄。

這是典型的「以檔名建立對位關係」的設計。INF 檔是 Windows 驅動世界的老居民，每個驅動套件本來就圍繞著一份 INF 組織。微軟沒有發明新的識別系統，而是讓 SBOM 直接掛在既有的 INF 名稱上，用副檔名區分性質。對審核管線來說，這表示可以用最機械式的方式配對檔案；對開發商來說，這表示不需要理解任何新的命名邏輯。

更嚴格的是數量規則：每個驅動各附一份，不能一套文件覆蓋整個提交。公告甚至給出了算式，若提交中有 N 個資料夾、每個資料夾有 M 個驅動，就需要 N 乘以 M 份獨立的 SBOM 與 VEX。把規則寫到可以直接套公式，這是把模糊地帶壓到最小的做法。文件設計裡最怕的就是「視情況而定」，而這條規則沒有留下視情況的空間。

SPDX 3.0 與 COSE 簽名：格式即政策

新規要求 SBOM 採用 SPDX 3.0 格式，並列出第一方與第三方元件，包括工具、函式庫、框架與依賴項，且必須包含傳遞依賴，也就是依賴的依賴，而非只列直接依賴。SBOM 與 VEX 都要通過 COSE 簽名保障完整性，並至少儲存十年，或依歐盟 GPSR 等法規的產品生命週期期限，取較長者。

這裡的設計意圖很清楚：微軟沒有自創格式，而是採用產業標準。SPDX 是 Linux 基金會體系下發展多年的軟體物料清單標準，VEX 則是用來聲明某個元件是否真的受特定 CVE 影響。選擇標準格式，等於把「什麼算一份合格的清單」這個定義權交給了共通規範，微軟只負責驗證與執行。

這種取捨在介面設計裡很常見。自己定格式可以完全掌控，但會把轉換成本轉嫁給所有合作夥伴；採用標準格式，則是承認這套介面必須與整個產業的其他環節互通。畢竟這次調整的動機之一，是滿足歐盟《網路韌性法案》（CRA）的合規要求。CRA 要求可銷售軟體具備元件透明度，而歐盟認的正是 SPDX 這類開放標準。微軟等於是在自己的簽名管線前面，加了一個通往歐洲法規的轉接頭。

時間表本身也被設計過。2026 年 12 月，新版 Windows 驅動程式工具包（WDK）將提供生成與驗證 SBOM、生成 VEX 的工具並附技術文件；開發商也可以先用第三方工具，但最終檔案必須嚴格符合 SPDX 3.0。先給工具、再給緩衝、最後才強制，這是政策介面裡標準的三段式上線節奏。2027 年 3 月之前提交的驅動不受影響，舊版 Windows 系統的認證要求也維持原樣，新舊之間畫出了一條清楚的線。

這些檔案不會到達終端使用者手上

公告裡有一個容易被忽略的細節：SBOM 與 VEX「不會作為驅動程式套件的一部分提供給最終使用者」。也就是說，這兩份檔案的生命週期止步於微軟的硬體開發者中心（HDC）。使用者更新驅動時，看到的仍然是熟悉的安裝進度與簽名確認，背後多出來的整套文件流程完全不可見。

這正是它作為介面的有趣之處。多數我們討論的設計是給人看的，這一套是給機器與稽核程序讀的。它的「好用」定義在於：檔名可預測、格式可驗證、依賴可追溯、簽名可驗真、儲存年限可查。當供應鏈資安事件發生，某個開源函式庫被爆出漏洞時，微軟與開發商要能在幾小時內回答「哪些驅動用了它、是否真的受影響」。VEX 存在的意義就在這裡，它讓「未受影響」也能成為一份正式、有簽名、可查核的聲明，而不是一句口頭保證。

同樣是信任機制的介面化，我們先前在FBI 招募降標的介面觀察裡看過官方語言如何重新設計一道門檻；而微軟這次的對象從求職文件換成了驅動套件，共通點是：真正的變化都發生在文件層，畫面只是最後的呈現。

收緊的是格式，也是責任的形狀

跟過去的驅動簽名相比，這次調整改變的東西可以用具體的對比來看。以前的 WHCP 簽名回答一個問題：這個驅動通過了相容性測試，出自可識別的開發商。2027 年 3 月之後，它還要回答：這個驅動由哪些元件組成、每個元件的版本是什麼、已知的漏洞是否影響它。簽名的含義從「身分保證」擴張為「成分揭露」。

這對開發商是實實在在的成本。整理第三方與開源元件、追出傳遞依賴、維持十年的文件儲存，每一項都是工時。微軟在公告裡也直接建議開發與合規團隊提前熟悉 SBOM、VEX 與 SPDX 格式，等於承認這不是簽署當天能補齊的作業。

但從介面設計的角度，這份公告示範了一件值得記住的事：大規模的行為改變，靠的往往不是宣導，而是把格式先定死。當檔名、副檔名、資料夾位置、數量算法、儲存年限都被寫成可以逐字遵循的規則時，合規就從一種判斷變成了一種排版。2027 年 3 月之後，一份無法通過簽名的驅動，問題多半不在程式碼，而在那兩個它沒帶上的 json 檔案。