用 SBOM 與建置紀錄應對歐盟供應鏈審查

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-13

OpenSSF 與 OpenChain 近日提出軟件供應鏈安全指引，焦點放在軟件元件盤點、漏洞處理及安全證據保存。iThome 報道指出，指引希望協助企業回應客戶審查，並評估歐盟《網絡韌性法》（CRA）及 NIS2 指令可能帶來的要求。對香港開發團隊而言，若產品、SaaS 或 IoT 設備供應予歐盟客戶，或者在跨境供應鏈中擔任供應商，這類資料治理工作可預早降低交付及審查時的摩擦。

最重要的限制也要先說清楚：採用 OpenChain 的管理標準、OpenSSF 的技術指引，或產出 SBOM，均不等於已符合 CRA 或 NIS2。iThome 特別指出，企業仍要按自身產品、服務與實際適用的法規逐項評估。換言之，這份指引較適合作為建立可核查證據的操作框架；法規適用範圍、責任角色和生效安排，仍應以歐盟官方要求及專業意見作準。

客戶要看的，往往是可追溯的回答

軟件供應鏈的難點，在於一個產品通常混合自家程式碼、開源套件及其他第三方元件。當某一依賴項被披露漏洞時，團隊首先要回答的未必是「漏洞嚴不嚴重」，而是「哪個版本的哪件產品用了它、是否受影響、何時修正」。若答案散落在原始碼倉庫、CI 系統、試算表與同事的訊息紀錄，客戶審查很容易變成臨時翻箱倒籠，亦會拖慢修補決策。

iThome 報道所述的做法，是以 OpenChain 的組織管理標準配合 OpenSSF 的安全技術。前者關注開源授權遵循及安全保證所需的政策、責任分工和執行紀錄；後者則涵蓋安全程式開發、軟件來源追溯、建置完整性及漏洞管理。把兩者放在一起看，重點並非多裝一套掃描工具，而是讓技術產物和管理責任能互相對應：有人負責、有記錄可查，資料亦能連回特定產品版本。

這亦解釋為何供應鏈安全工作常被誤判為純資安或純 DevOps 項目。漏洞掃描可找出候選問題，卻未必說明元件從何而來、是否實際進入已發佈版本，以及修補決定有沒有被覆核。反過來說，只有政策文件但沒有可驗證的元件與建置資料，同樣難以支持產品級別的回應。按 iThome 的描述，指引要求保存的資料橫跨管理、開發與維護流程，正反映這是跨職能的證據鏈工作。

SBOM 與 GUAC：由清單走向關聯資料

SBOM 可視為軟件的組成清單，用來記錄產品所含元件及其相依關係。iThome 指出，企業可參考 OpenChain 相關標準建立盤點流程，並利用 OpenSSF 相關工具建立和維護 SBOM。對團隊來說，真正有用的 SBOM 應隨產品版本更新，而非在投標或客戶問卷到來前才手動匯出一次；否則它只是一份很快過期的附件，無法支援事故判斷。

OpenSSF 旗下的 GUAC 開源項目，則可整合軟件元件的來源、相依關係與漏洞資訊，供企業追查元件和漏洞的關聯。從實務角度推論，這類關聯能力的價值在於縮短排查路徑：團隊不用每次由漏洞名稱開始逐個倉庫查找，而可由元件、版本與產品關係反查受影響範圍。不過，資料整合本身不能保證資料正確；來源、版本命名和相依關係若未持續維護，最後產生的仍可能是錯誤信心。

因此，香港團隊可先把工作拆成一條最小可行證據鏈：為每個可交付版本產生 SBOM，保留所用來源與建置紀錄，並把漏洞處理結果連回對應版本。之後才逐步把元件來源、相依關係及漏洞資料接入 GUAC 或同類分析流程。這個次序較切合中小團隊資源有限的情況，亦能先解決客戶最常問的版本追溯問題，而不是一開始便追求涵蓋所有系統的龐大平台。

可執行清單：先建立可核查的最小閉環

以下清單並非 CRA 或 NIS2 合規清單，而是根據 iThome 所述指引整理的供應鏈安全起步項目。團隊應按產品類型、客戶合約及實際法規義務調整，並為每項安排明確擁有人和覆核方式。重點是讓紀錄能在需要時取出、理解並驗證，而不是只為通過一次性問卷。

為每個發佈版本建立及保存 SBOM，列出使用的軟件元件與相依關係。
保存軟件來源與建置紀錄，並清楚標記它們對應的版本與時間。
建立漏洞接收、判斷、修補或處置的流程，保留處理結果與審查紀錄。
訂立管理政策及責任分工，讓開發、資安、法務或產品負責人知道何時需要介入。
保存政策、SBOM、來源、建置及漏洞資料，並盡量採用可供系統交換的機器可讀格式。
在證據中標註審查項目、軟件版本與時間，方便客戶或稽核方核對資料的適用性。

當中最容易被忽略的是「保存」並不只是長期放檔。若建置紀錄、SBOM 與漏洞處理結果未能以同一產品版本串連，審查人員仍需人工拼湊時間線。較可行的做法，是把版本識別碼設為共同索引：發佈流程產生的 SBOM、來源參考、建置資料及處理紀錄都引用同一版本。這是由指引所強調的版本、時間及審查標示延伸出的實務建議，目的在於提升證據可讀性和重用性。

對香港團隊的含義：由交付檔案變成持續能力

對本地 SaaS 團隊而言，客戶未必只關心某次部署是否完成，亦可能要求供應商說明開源元件、漏洞狀態與修補紀錄。對 IoT 或軟硬件整合供應商，產品生命週期較長，追查某個元件進入哪些版本的需要會更明顯。至於替歐盟客戶開發軟件的外判或產品團隊，能否快速交出一致、可驗證的證據，可能影響客戶對供應商風險的評估。這些是跨境業務上的潛在影響，並不表示香港公司必然直接受歐盟法規規管。

採用開源工具和管理標準亦有取捨。好處是能把元件追蹤及證據保存制度化，減少遇到漏洞或審查才臨急抱佛腳；成本則是要處理資料質素、流程整合及持續維護。若團隊只把 SBOM 視作交付文件，或只把 GUAC 視作資料匯集器，缺少版本治理和修補責任，成效會有限。iThome 的報道提醒了工具、政策與紀錄三者的關係，實際成敗仍取決於它們是否融入日常開發與發佈流程。

下一步值得觀察的，是歐盟客戶如何把 CRA、NIS2 或內部供應商要求轉化為採購問卷、合約條款及審查證據。對有相關客戶的香港團隊，現在先完成一兩個核心產品的 SBOM、建置追溯及漏洞處理閉環，會比等到審查來臨才補文件更容易找出流程缺口；至於法規是否適用及需要達到何種程度，仍須按官方資料另行核實。