台灣韌體 SBOM 漏洞判定指南：VEX、EUVD 與通報決策
給 BMC、NIC、DPU、路由器、NAS 與 IoT 韌體團隊：把 SBOM CVE 轉成受影響、未受影響、已修補或調查中記錄，並用 EUVD、KEV、EPSS 排定優先順序。
本文內容
台灣韌體團隊最常遇到的 CRA 問題，不是「有沒有 SBOM」，而是「SBOM 掃出 CVE 之後，誰判斷產品到底有沒有受影響」。
這篇文章是台灣 AI 伺服器硬體 CRA 實務指南的深水區補充。AI 伺服器那篇處理 BMC、NIC、DPU、加速卡與資料中心硬體的證據包；本文只處理漏洞判定這一步：把 SBOM 的 CVE 命中，轉成可稽核的受影響、未受影響、已修補或調查中紀錄。
如果你的問題是 EU 品牌如何把 SBOM、CVD、12 小時 SLA 與支援期寫進代工合約，先看台灣 ODM 與零組件供應商 CRA 指南。如果你的問題是通報該送哪個 EU CSIRT，先看台灣製造商的 CRA 漏洞通報對象指南。
摘要
- SBOM 只提供元件清單與 CVE 命中，不等於產品受影響判定
- 台灣韌體團隊需要為每個產品版本留下四種狀態之一：受影響、未受影響、已修補、調查中
- VEX 是常見的機器可讀格式，但 CRA 沒有強制使用 VEX 這個名稱
- EUVD、CISA KEV、EPSS、供應商公告與 CVD 報告都可以用於優先排序，但它們不是 CRA 通報管道
- 被積極利用的漏洞只有在產品實際受影響、且製造商知悉可信利用證據時，才進入 24 小時通報判斷
- 對 BMC、NIC、DPU、路由器、NAS、IoT 閘道器與 ODM 客製韌體，判定紀錄要能連回韌體版本、客戶 SKU、修補版本與通知狀態
這篇適合誰？
這篇文章適合下列團隊：
- 台灣 BMC、BIOS/UEFI、NIC、DPU、SmartNIC 韌體團隊
- 路由器、NAS、交換器、工控閘道器、IoT gateway 韌體團隊
- ODM 量產線上管理多客戶、多 SKU 韌體映像的工程團隊
- PSIRT、產品安全、法務、客戶品質與歐洲業務團隊
- 需要向 EU 品牌客戶解釋「這個 CVE 為什麼不影響我們產品」的人
本文不主張每個 CVE 都要通報，也不主張 VEX 是法定格式。本文的重點是建立一個能被工程、法務、客戶與市場監督機關看懂的漏洞判定紀錄。
為什麼 SBOM 不夠？
SBOM 是必要輸入，但不是判定結論。
假設 OpenBMC 映像裡有一個受 CVE 影響的開源套件。掃描器會告訴你「這個套件版本有漏洞」。但它不會回答下列問題：
- 受影響函式是否真的被編譯進韌體映像？
- 服務是否在產品預設設定下啟用？
- 攻擊者是否能從管理網路或遠端介面到達該程式碼？
- 這個漏洞是否只影響開發工具，而不是出貨映像？
- 客戶 SKU 是否使用同一個韌體分支？
- 是否已有修補版本、臨時緩解或設定變更？
沒有這些答案，EU 品牌只能看到一串 CVE，卻無法判斷哪些型號要通知客戶、哪些版本要緊急修補、哪些事件需要通報。
四種判定狀態
每個 CVE 命中，至少要落到一個狀態。不要停在「掃描器發現漏洞」。
| 狀態 | 何時使用 | 需要留下的證據 |
|---|---|---|
| 受影響 | 漏洞存在於出貨韌體，且攻擊路徑可達或尚未被有效阻斷 | 受影響型號、韌體版本、攻擊面、緩解措施、修補目標版本 |
| 未受影響 | 元件雖命中 CVE，但產品不暴露受影響功能或程式碼不可到達 | 編譯設定、功能停用證據、路徑分析、測試紀錄 |
| 已修補 | 產品曾受影響，但某一版韌體已修補或移除風險 | 修補版本、release note、簽章映像、客戶通知紀錄 |
| 調查中 | 目前資料不足，仍在確認產品是否受影響 | 責任人、下一步檢查、暫時緩解、客戶回覆口徑 |
VEX 可以承載這些狀態。CycloneDX 與其他格式都能表達受影響與未受影響的理由。但格式不是重點，判定品質才是重點。若你用 spreadsheet、ticket、JSON 或客戶平台，也要能保留同樣的欄位與理由。
哪些資料進入判定？
實務上，韌體漏洞判定至少需要六類輸入。
| 輸入 | 用途 | 台灣韌體團隊要注意 |
|---|---|---|
| SBOM | 找出元件、版本與依賴關係 | BMC、NIC、DPU、BIOS、更新工具要分層，不要只掃 Linux rootfs |
| Build 設定 | 確認易受攻擊功能是否編譯進映像 | Yocto、OpenWRT、Buildroot、vendor SDK 的設定要保留 |
| Runtime 設定 | 確認服務是否啟用、接口是否暴露 | 預設關閉、管理網隔離、ACL 不是口頭說明，要有測試紀錄 |
| 漏洞情資 | 判斷是否需要升高優先順序 | EUVD、KEV、EPSS、NVD、OSV、供應商公告一起看 |
| 客戶 SKU 對照 | 確認哪個 EU 品牌、哪個型號、哪個韌體分支受影響 | ODM 客製化會讓同一平台出現多個結果 |
| 修補與通知紀錄 | 支撐已修補、客戶通知與通報決策 | 修補版本、簽章映像、release note、客戶信件要能連回 CVE |
EUVD 的角色是監測與優先排序，不是通報。KEV 能顯示已知遭利用的漏洞，EPSS 可提供短期利用機率參考，但兩者也不是自動通報觸發器。CRA 通報仍要回到產品是否受影響、是否有可信的積極利用證據、以及製造商何時知悉。
什麼時候進入通報判斷？
對 CRA 來說，韌體團隊要避免兩種錯誤。
第一種錯誤，是看到 CVE 命中就直接說「要通報」。這會製造大量假陽性，讓 EU 品牌失去信任。
第二種錯誤，是看到漏洞在第三方元件裡就說「不是我們的問題」。如果該元件已整合到產品中，製造商仍需要判斷產品是否受影響，並在必要時修補、通知使用者或通報。
比較穩的通報判斷可以用三個閘門：
- 產品閘門：這個 CVE 是否影響出貨產品或支援期內的韌體版本？
- 利用閘門：是否有可信證據顯示漏洞已被惡意利用？
- 知悉閘門：製造商何時知道這個可信利用證據？
三個閘門都打開時，才進入 24 小時早期預警的作業節奏。若產品未受影響，留下未受影響理由。若還不能判定，標成調查中並設定內部升級規則，不要讓 ticket 停住。
通報的時限在 CRA 下是固定的。一旦判定為受影響且有可信的積極利用證據，對外負責的製造商要透過 ENISA 單一通報平台（SRP）向一個協調者 CSIRT 提交下列通報：
- 24 小時內：早期預警
- 72 小時內：詳細通知
- 修補或緩解措施可用後 14 日內：最終報告
- 同時通知受影響的使用者
這個通報義務從 2026 年 9 月 11 日起適用，產品的主要義務則從 2027 年 12 月 11 日起適用。對 ODM 來說，這代表判定證據必須在小時級別內就能交給 EU 品牌，否則品牌無法在 24 小時內完成早期預警。
BMC、NIC、路由器韌體的判定範例
| 情境 | 初步狀態 | 為什麼 |
|---|---|---|
| OpenBMC 使用的 web server 元件有遠端利用漏洞，管理介面在 EU 客戶環境中可達 | 受影響 | 攻擊路徑可達，需確認型號、韌體分支與修補版本 |
| NIC 韌體包含有漏洞的診斷工具，但該工具只在工廠模式存在，出貨映像未包含 | 未受影響 | 需要保留 build artifact 與出貨映像證據 |
| Router SDK 的 UPnP 元件有已知利用，但 EU 型號預設關閉且防火牆阻擋外部到達 | 調查中或未受影響 | 需要測試證明外部不可達；若客戶可手動啟用，文件要說清楚 |
| NAS 管理介面元件受影響，已有修補韌體並完成客戶通知 | 已修補 | 記錄修補版本、release note、通知時間與未更新客戶風險 |
| DPU firmware 的隔離漏洞被供應商公告為已遭利用，但 ODM 尚未確認自家分支是否含受影響程式碼 | 調查中 | 需要立即拉取分支、比對 patch、通知 EU 品牌調查狀態 |
這些狀態不是永久標籤。調查中可以變成未受影響，也可以變成受影響。受影響在修補發布後可以變成已修補。每一次狀態改變都要留下原因與時間。
ODM 與 EU 品牌怎麼分工？
如果 EU 品牌以自己的名稱銷售成品，品牌通常是對外負責的製造商。但 ODM 或韌體供應商不能只回一句「我們不是製造商」。EU 品牌能否判斷通報、通知使用者、簽署文件，常常取決於供應商能否快速提供判定證據。
建議把分工寫成表格放進合約文件或安全作業程序：
| 工作 | ODM / 韌體供應商 | EU 品牌 |
|---|---|---|
| SBOM 產出 | 每個韌體版本、SKU、客製分支提供機器可讀 SBOM | 整合成成品級證據包 |
| CVE 初篩 | 比對元件版本、build 設定、runtime 設定 | 決定對外風險與客戶溝通優先順序 |
| 受影響判定 | 提供工程理由、測試紀錄、修補狀態 | 決定是否通報與通知使用者 |
| 修補交付 | 產出簽章韌體、release note、回歸測試 | 安排客戶發布、維護窗口與通知 |
| 事件紀錄 | 保留 ticket、證據、時間線 | 保留對外通報與市場監督回應資料 |
若台灣供應商把 BMC、NIC、DPU、韌體套件或連網模組以自己的名稱供應到 EU 市場，角色會改變。這時供應商可能需要自己的產品檔案、支援期聲明、漏洞處理流程與通報準備。若同一元件只是嵌在 EU 品牌成品裡，供應商證據通常透過合約交付給品牌。
判定紀錄應該包含哪些欄位？
不要只留下「not affected」四個字。可稽核的判定紀錄至少要包含：
- CVE / EUVD ID / 供應商公告 ID
- 產品型號、客戶 SKU、韌體分支、build hash
- SBOM 中命中的元件名稱與版本
- 判定狀態：受影響、未受影響、已修補、調查中
- 判定理由：不可到達、未編譯、未啟用、已修補、仍在比對
- 證據連結：build 設定、測試紀錄、patch、release note、客戶通知
- 責任人與覆核人
- 狀態變更時間
- 是否需要通知 EU 品牌、使用者或通報
對大型 ODM 來說，這份紀錄最好和漏洞管理系統、SBOM 儲存庫、韌體 release 系統連在一起。用 email 或 spreadsheet 可以起步，但很難支撐多品牌、多 SKU、多分支的長期維護。
常見問題
VEX 是 CRA 強制要求嗎？
不是。CRA 要求製造商識別與記錄產品中的元件和漏洞，並處理漏洞。VEX 是一種實務上常用的機器可讀判定方式，可以記錄某個 CVE 對特定產品版本是受影響、未受影響、已修補或仍在調查。你可以使用 VEX，也可以用其他能保留同等證據的格式。
EUVD、KEV 或 EPSS 命中就一定要通報嗎？
不一定。這些來源可以幫助排序，但不是 CRA 通報管道，也不是自動通報觸發器。通報判斷仍要看產品是否受影響、是否有可信證據顯示漏洞已被惡意利用、以及製造商何時知悉。如果產品未受影響，應留下未受影響理由。
如果漏洞在第三方 SDK 或開源元件裡，ODM 還要判定嗎？
要。第三方來源不會自動解除產品製造商或供應商的判定責任。ODM 至少要判斷該元件是否進入出貨韌體、受影響功能是否啟用、攻擊路徑是否可達、修補版本是否可用，並把結果交給 EU 品牌或自己的產品檔案。
未受影響的判定要寫多詳細？
要詳細到工程師可以重現。好的理由是「受影響函式未編譯進 EU 型號韌體，見 build config hash X 與測試紀錄 Y」；不好的理由是「不適用」或「供應商說沒有影響」。越接近 24 小時通報場景，越需要可立即交給 EU 品牌的證據。
這篇和 AI 伺服器 CRA 指南有什麼不同？
AI 伺服器指南處理 BMC、NIC、DPU、加速卡與資料中心硬體的整體證據包。本文只處理漏洞判定流程：SBOM CVE 出現後，如何決定特定韌體版本是受影響、未受影響、已修補或調查中，以及何時升級為通報判斷。
相關文章
CRA 是否適用於你的產品？
回答6個簡單問題，了解你的產品是否屬於 EU 網路韌性法的適用範圍。2分鐘內即可獲得結果。