判定產品未受影響，要說得出為什麼，也要知道哪些變動會讓原來的結論失效
文／游政卿‧校訂╱CIO 編輯室
在 2026 年 3 月，產品資安測試實驗室在檢查韌體 5.10 的軟體物料清單（Software Bill of Materials，SBOM）時，發現十款產品都使用同一個開放原始碼函式庫，而這個函式庫存在一項已揭露的漏洞。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
「我們有 SBOM，應該很快就能確認哪些產品受這個漏洞影響。」
實際比對之後，才發現要釐清的問題還很多。
SBOM 記錄產品包含哪些元件與版本，能把調查範圍縮小到這十款。但至於韌體有沒有用到有漏洞的功能、編譯時是否啟用相關模組、供應商是否改過原始版本，清單上看不出來。同一款產品的不同硬體版本，使用的元件也可能各有差異。
十款都在清單上，受影響的是四款
進一步分析後，三款在確認的版本與設定下，相關功能沒有啟用，無法觸發漏洞；兩款在編譯時已移除有漏洞的模組。另有一款雖然使用漏洞資料庫列出的受影響元件版本，但供應商已在該版本中完成修補，且確認產品採用的元件包含修補內容。
最後確認，十款產品中有四款受影響、五款在確認的版本與設定下未受影響，另外一款已修補。
SBOM 說明產品裡有哪些元件，漏洞可利用性交換（VEX）則說明特定漏洞對產品的影響狀態，包括受影響、未受影響、已修補與調查中。判定未受影響時，要說明依據。
已修補與未受影響要分開記。供應商修補過的元件，要先確認產品實際採用的版本含有修補內容，才能記為已修補，並保留修補與驗證資料。把這類產品歸進未受影響，日後查閱的人可能無法掌握漏洞的修補歷程。
我的看法是，SBOM 管理成熟到什麼程度，要看企業怎麼處理判定未受影響的產品，能否拿出當時的判定依據，以及版本或設定改變之後，是否知道哪些結論需要重新確認。
還沒有導入 SBOM 的企業，收到供應商「未受影響」的回覆時，也可以先問，這個判斷適用於哪個版本，又是根據什麼資料？
未受影響，要寫出在什麼條件下成立
客戶問產品有沒有某個元件，查對應版本的 SBOM 就能回答。追問為什麼判定未受影響，就要拿出技術依據。在特定產品版本與設定下，經分析確認漏洞程式碼沒有可觸發的執行路徑、漏洞觸發條件不存在，或編譯時已排除有漏洞的程式碼。技術依據說明結論為什麼成立，產品版本與設定則劃出結論適用到哪裡。
[ 推薦閱讀：從告警到可決策：企業還要 4 小時 ]
這些依據通常不在 SBOM 裡，要靠另外保存的漏洞影響分析紀錄。紀錄至少寫清楚產品與元件版本、漏洞觸發條件、產品為何無法滿足這些條件、分析人員與驗證方式，以及分析日期與適用設定；程式碼分析、測試結果或供應商佐證也一併保存。VEX 可以記錄判定理由，但支撐結論的分析紀錄、適用設定與重查時機，企業仍須妥善保存。
結案之後，條件還會變
確認受影響的產品，接下來有風險評估、修補與安全公告，流程會推著人往前走。判定未受影響的產品，調查通常就停在那裡。容易被忽略的是：當初支撐這項判斷的條件，日後還成立嗎？
產品版本、功能設定或供應商提供的技術資訊如果有變動，就要確認是否影響原來的判定依據；需要重新判定時，應更新漏洞影響狀態，必要時也要修正對外說明。
網通設備特別容易遇到這種情況。3 月判定未受影響的五款裡，有三款的理由是相關功能沒有啟用；新版韌體若把該服務改為預設開啟，或客戶自行在管理介面啟用，原本的未受影響結論就不再適用於新的設定。後者發生在客戶端，製造商的版本紀錄上沒有痕跡。
客戶、稽核人員或主管機關日後要求說明，拿得出當時的分析紀錄，接手的人才能判斷那次驗證是否充分、有無遺留未釐清的問題。
完成率變高，可能只是狀態被改掉
導入 SBOM 後，常見的追蹤指標是已有 SBOM 的產品比例、能自動產生 SBOM 的韌體版本比例、第三方元件辨識完成率，看的是建置進度。每款產品都有 SBOM，重大漏洞一來，仍可能有許多產品停在調查中。
我建議另外追蹤本文所稱的「決策覆蓋率」，也就是針對同一個漏洞，已完成影響判斷、具備可查核依據且結論仍然有效的產品與版本組合，占所有需要評估組合的比例。評估範圍也要有依據，不能因為部分產品的元件資訊不完整，就直接排除在分母之外。仍在調查中、判定依據不足，或原有判定條件已改變卻尚未重新確認的項目，仍應納入需要評估的範圍，但不能計入已完成的數量。
網通產品的分母往往很大。同一個開放原始碼元件可能同時出現在交換器與無線基地台，每條產品線又有好幾個仍在支援期的韌體版本，產品與版本組合一乘開來，遠多於產品數。
系統若只依影響狀態計算完成率，沒有檢查依據是否充分，還沒查清楚的項目只要被標成未受影響，就會從調查清單上消失。下游客戶的掃描工具讀到未受影響的聲明，也可能直接把這個漏洞濾掉。報表上的完成率提高了，技術問題還在原地。
所以抽查要從判定未受影響的紀錄開始，優先看理由不明確、供應商佐證不足，或版本與設定已變動卻沒有重新確認的項目。除了檢查當時的判定依據是否充分，也要確認適用條件是否仍然成立，必要時重新分析或測試。
SBOM 對不上出貨版本，判斷就落空
我在現場看過，有企業的 SBOM 元件清單相當完整，遇到重大漏洞時，卻因為對不上產品與韌體版本，無法立即確認影響範圍。
斷點通常在資料分散。SBOM 由研發團隊產生，產品生命週期資料在另一套系統，已發布的韌體與客戶實際使用的版本又由不同團隊管理。沒有確認 SBOM 是否對應實際發布的韌體版本，就可能拿錯元件清單做判斷。
知道某個韌體版本含有某個元件，還要能接著回答哪些型號採用這個版本、能掌握哪些客戶仍在使用，以及產品是否仍在支援期限內。型號與韌體的對應關係界定評估範圍，客戶實際使用的版本與產品支援期限，則影響後續通知、修補與升級的安排。
只保留最新版 SBOM 也會出問題。產品出貨後，研發持續修補，客戶未必同步升級，各版韌體的第三方元件也可能有差異，缺少對應版本的 SBOM，舊版產品是否受影響就查不清楚。
SBOM 元件與漏洞資料庫比對不到結果，同樣要繼續查。元件名稱對應失敗、版本資訊殘缺，或第三方提供的二進位檔還沒完成元件辨識，都會讓比對落空。
依據來自供應商，結論還是製造商的
晶片廠的軟體開發套件（SDK）、設計代工廠（ODM）提供的韌體、未開放原始碼的二進位檔、商用函式庫，影響判斷多半要靠供應商的技術資訊。製造商知道產品含有這些元件，手上卻常缺原始碼、編譯設定或漏洞分析資料，難以獨立確認。
供應商的分析資料應說明受影響的元件版本、觸發條件與修補狀態，必要時附上測試或分析紀錄。製造商要確認這些資料適用於自家產品的元件版本與使用方式，才能據以判斷，最終結論仍由製造商負責。
[ 閱讀所有 游政卿 的文章 ]
以 Linux 核心與無線網路驅動程式為例，晶片廠常在 SDK 裡維護自己的分支。漏洞揭露後，若還缺少晶片廠的分析資料，無法確認自家產品是否受影響，就先列為調查中；已確認受影響的產品，則應標示為受影響，並追蹤供應商的修補進度。
拿一個真實的 CVE 從頭追一次
評估企業的 SBOM 管理能力時，我會挑一個真實的重大 CVE，從漏洞資訊追到元件、產品型號與韌體版本，看企業能否分辨含有漏洞元件的產品與實際受影響的產品；第三方元件的分析結果，也追到可查證的來源。
還沒有導入 SBOM 的企業，也可以先從一個實際漏洞開始。產品製造商可以向研發團隊或供應商確認哪些產品與版本受到影響；一般企業則可以從既有系統、軟體版本與供應商公告著手，確認自己使用的環境是否受影響，並留下判定依據。過程中如果發現連產品版本、元件資訊或供應商窗口都無法確認，就能進一步找出管理缺口，不必等到 SBOM 全部建置完成才開始處理。
這套做法要依規模調整。產品與版本少的時候，可以用工單保存分析紀錄與佐證；產品線與韌體版本一多，就需要一致的紀錄欄位並集中管理，日後才查得回當時的判斷依據。
3 月那五款產品，可以依當時確認的版本、設定與技術依據結案。我在意的是，日後企業還找不找得到這些依據，條件改變時，又能不能辨識哪些結論需要重查。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
