SBOM 漏洞修補的第一步，是把公告中的漏洞識別碼對到實際部署的產品版本；第二步才是由產品責任人判斷是否受影響，決定更新、緩解或暫不處置。NIST 的供應鏈指引也把 SBOM、漏洞偵測、資產清冊與風險管理放在同一條工作流裡。只保存一份 SBOM 檔案，沒有接上這些資料，漏洞揭露後仍然找不到該修哪裡。

我在SBOM 是什麼與台灣企業怎麼建立軟體物料清單已經拆過格式與基本欄位，這篇往後走，專注在告警進來之後怎麼分工、怎麼留下可回溯的處置紀錄。

企業資安團隊在螢幕上檢視軟體元件、漏洞告警與修補版本。

SBOM 漏洞修補先做什麼

收到 CVE 或供應商安全公告時，先建立一筆「漏洞事件」，欄位至少包括漏洞識別碼、公告時間、來源、受影響版本、目前部署版本與負責窗口。接著用 SBOM 的元件名稱、版本與唯一識別碼做比對，找出產品、服務、容器或設備的實際落點。NIST 建議把漏洞偵測能力接到 SBOM 儲存庫，讓供應鏈風險能自動產生告警；這個建議也明確要求企業把 SBOM 對回自己的資產清冊。NIST 指引的相關段落可直接對照實作。

這一段的產出不是「掃描通過」，是三張能互相對上的表：漏洞、軟體版本、部署資產。少了部署資產，團隊只知道某個元件可能有問題，仍不知道它出現在正式環境、測試環境，還是根本沒有被使用。

五段流程各自要交出什麼

階段主要負責人要留下的紀錄
收到告警資安或維運識別碼、來源、時間、初始嚴重度
對照範圍資產與平台團隊產品版本、SBOM版本、部署位置
判定影響供應商或產品團隊受影響、不受影響、尚待確認的理由
決定處置產品負責人與維運修補版本、緩解措施、停機或回復方案
結案回填資安治理與變更管理測試結果、上線時間、新版SBOM與通知紀錄

我的判斷是，表格中的第三段最容易被省略。企業把「找到元件」誤當成「已確認受影響」，後面就會出現兩種錯誤：所有產品一起緊急升版，或供應商一句「我們有用這個套件」就把整個責任推回採購方。

怎麼把 SBOM、漏洞資料與資產清冊串起來

資料架構不用一開始就做成大型平台，但三個識別軸要先固定：元件識別碼、產品版本、部署資產。SBOM 儲存庫保留每次產製的版本與時間，漏洞資料來源保留公告與更新時間，資產清冊則要知道這個產品目前跑在哪個環境。NIST 建議企業要求供應商提供可機器讀取的標準格式，並把各類軟體的 SBOM 納入目錄；若沒有供應商清單，對舊系統進行二進位分析也只能在技術與法律可行時採用。NIST 對採購、格式與漏洞告警的建議有列出這些能力。

SBOM、漏洞資料與資產清冊匯入同一個風險管理流程。

實作上，我會把資料流設計成「事件建立、範圍比對、人工判定、變更申請、驗證結案」五個狀態。每個狀態都要有時間、負責人與下一步，避免把討論散在電子郵件或聊天記錄裡。若產品版本對不上 SBOM，系統應該先標成「資料不足」，不要自動判定安全。

採購條款也要跟著改。要求供應商交一份 SBOM，只能驗收檔案；要求它在版本更新、元件變更、漏洞揭露與停止支援時提供更新資料，才有機會把 SBOM 接進維運。NIST 建議供應商維護可取得、具數位簽章的 SBOM 儲存位置，企業則要把收到的清單納入持續監測。相關採購建議支持這個設計方向。

VEX 怎麼幫忙判斷要不要修

SBOM 命中某個有漏洞的元件，仍可能需要看產品如何使用它、哪些功能有開啟、外部介面是否可達，以及供應商是否已經提供修補或緩解。VEX，也就是 Vulnerability Exploitability eXchange，用產品對漏洞的狀態補上這層脈絡；CycloneDX 的 VEX 說明指出，VEX可用機器可讀資料表達產品受影響、已修補或不受影響等狀態，讓工具與團隊能繼續處理。

產品團隊檢視 VEX 漏洞狀態、修補版本與緩解措施。

我會把 VEX 視為「判定紀錄」，不把它當成免修補通行證。若標成不受影響，紀錄裡仍應寫清楚理由，例如元件未被打包進正式版本、受影響功能未啟用，或產品有足以阻斷風險的設定。這些理由要能由產品團隊或供應商回覆，資安團隊負責檢查證據是否足夠。

責任分派可以這樣切：供應商回覆元件與產品的影響範圍，開發或產品團隊確認程式與設定，維運團隊確認部署版本和變更窗口，資安治理保留判定與例外核准。採購與法務則把回覆期限、更新格式和停止支援通知寫進契約。每一段都有明確輸入與輸出，才不會讓「誰要修」變成無人認領的共用信箱。

台灣現況與醫療設備要多看一層

台灣的政策推進目前看得到兩個訊號。資通安全署在 2026 年 4 月 29 日舉辦 SBOM 工作坊，公開說明預定於 2026 年下半年發布 SBOM 實務參考指引；同一份官方新聞稿也提到，政府以政策引導和共同供應契約鼓勵供應商提供元件資訊，並把漏洞管理、流程安排、產品發布與後續追蹤列為工作坊討論內容。這代表企業現在就能把格式、更新和回覆責任寫進採購流程，不能等到指引發布後才開始盤點。

醫療設備的要求更接近產品生命週期。FDA 2025 年的醫療器材資安指引建議，SBOM 或等效能力要納入組態管理，隨上市產品的軟體變更定期更新；對 cyber device，上市前申請還有 SBOM 要求，並應提供元件支援狀態與停止支援日期。FDA 同一份指引也要求製造商評估已知漏洞對設備與系統安全的影響，提出相應的安全控制。

醫院資訊人員在聯網醫療設備旁檢視 SBOM、支援期限與安全更新紀錄。

這和一般企業軟體的差別在於，更新失敗可能碰到臨床服務中斷、設備功能異常或病人安全風險。台灣醫院採購聯網醫材時，我會把四個欄位列為基本驗收項目：目前軟體版本、元件清單取得方式、漏洞通知窗口、更新後的驗證與回復方案。醫療器材資安的台灣規範與國際要求，可再看醫療器材資安是什麼與台灣網路安全規範走到哪。

結案前要檢查什麼

漏洞修補完成的判定，至少要同時通過四件事：正式環境版本已更新、受影響功能完成測試、SBOM產製時間與內容已更新、供應商和內部責任人都留下回覆。若暫時不能更新，則要記錄緩解措施、適用範圍、期限與重新評估日期。這些項目讓後續稽核或下一次漏洞公告可以沿著同一筆事件回查。

醫療、金融或高可用服務還要多加一個回復檢查：更新後若功能驗證失敗，誰能在什麼條件下回到前一版，回復後的風險由誰接受。這是流程設計，不是工具品牌選擇；工具可以縮短比對時間，不能替企業決定哪一項服務可以停、哪一項風險可以留下。

常見問題

SBOM 漏洞修補第一步要做什麼？
先把漏洞識別碼對到 SBOM 的元件、版本與產品，再對照實際部署資產。完成範圍比對後，才交給供應商或產品團隊判定是否受影響。

SBOM 命中漏洞就一定要立刻升版嗎？
不一定，仍要看產品如何使用該元件、受影響功能是否啟用，以及供應商提供的影響分析。若暫不更新，應留下 VEX 或同等判定、緩解措施與重新評估時間。

台灣企業現在要把 SBOM 寫進採購嗎？
資通安全署已公開推動 SBOM 工作坊，並表示預定於 2026 年下半年發布實務參考指引。企業可先把機器可讀格式、更新頻率、漏洞回覆窗口與修補紀錄寫進契約，再依後續官方文件調整。