SBOM大解密：歐盟CRA合規的關鍵拼圖與開源軟體陷阱
- 台北訊
-
在上一篇文章中，我們釐清了歐盟《網路韌性法案》（Cyber Resilience Act；CRA）的管轄範圍，破解了「硬體不連網就沒事」的迷思，並了解到只要硬體綁定雲端服務，同樣難逃這次CRA法規的天羅地網。今天，我們將目光轉向研發內部，深入探討CRA實作階段中，最讓台灣RD團隊與法務主管頭痛的技術文件：SBOM（Software Bill of Materials；軟體物料清單）。
您可以將SBOM想像成食品包裝背後的「成分營養標示」。如果一家食品廠不知道自己的產品裡加了什麼原料，一旦爆發食安危機，根本無從查起。同樣地，如果您的設備不知道使用了哪些「第三方軟體或開源模組」，一旦爆發如Log4j 這種核彈級的資安危機，您要如何在CRA規定的24小時內通報義務下，釐清災情並進行早期的漏洞通報？
在新的EU CRA法規監管框架下，如果貴公司準備的技術文件（Technical Documentation）中沒有包含合規要求的top-level SBOM，產品就無法證明符合CE Mark標章要求。這意味著，不合規的產品將被直接拒於歐盟大門之外，面臨極高的產品召回費用與罰款風險。
為什麼歐盟CRA強制要求SBOM？，要了解SBOM的重要性，我們必須先看懂歐盟立法的底層邏輯。
1. 法規依據：CRA附件一的強制要求：根據CRA附件一（Annex I）Part 2針對「漏洞處理（Vulnerability handling）」的基本要求，製造商必須識別並記錄產品中包含的漏洞與組件，其中明文規定必須「建立並維護機器可讀的軟體物料清單（SBOM）」。這不再是加分項目，而是必考題。
2. 供應鏈透明化與盡職調查（Due Diligence）：現代軟體開發早就不再是「從零開始自己刻」。研究指出，現代軟體產品中有高達70~90%的程式碼是由開源軟體（Open Source）或第三方組件拼湊而成。CRA要求製造商必須對整合進產品的所有組件行使「盡職調查（Due Diligence）」。當貴公司的產品在歐盟市場遭遇漏洞通報時，貴公司團隊必須依靠SBOM快速盤點受影響的範圍，並能即時在歐盟的單一通報平台（Single Report Platform；SRP）上做出精準回應。
3. 自動化監控的基石：CRA法規於2026年9月11日後必須通報的兩大事件類型，製造商從2026年9月11日起，需透過單一通報平台（SRP）通報兩種特定情況：已遭積極利用的漏洞（Actively Exploited Vulnerabilities）： 產品中存在，且有證據顯示正被惡意利用的漏洞。嚴重事件（Severe Incidents）： 對產品安全性（如可用性、真實性、完整性或機密性）產生嚴重影響的事件。
面對每天成千上萬的新增漏洞（CVE），單靠工程師人工比對是不可能完成的任務。一份結構化、可機器讀取的SBOM，是企業導入自動化漏洞監控、快速修補（Patch）與資安事件應變的前提。
由於事件發生不分平日假日，製造商同步可從自動化監控的建置過程中建立24/7的資安應變機制，傳統「朝九晚五」的IT團隊很可能無法滿足24小時通報要求，必須建立全年無休的PSIRT (產品安全事件應變團隊) 或SOC能力。
台灣製造商最擔心的4個SBOM實務痛點
當老闆和研發主管第一次聽到要交出「軟體清單」時，腦中往往會警鈴大作。以下我們針對台灣產業界最關心的「軟體機密與智財權」問題，一一為您破解迷思：
常見問題01：交出SBOM，不就等於把我們公司辛苦寫的「原始碼（Source Code）」和商業機密底牌全看光了嗎？SBOM列出的是產品所「依賴的組件名稱、版本號以及依賴關係」。打個比方，它就像是列出這塊麵包用了哪一個牌子的麵粉、哪一家的酵母，而不是交出您獨家的「發酵環境、烘焙秘方與製程」。SBOM不會包含您的核心演算法、商業邏輯或原始碼，您的智慧財產權（IP）依然受到完整保護。
常見問題02：我們用了很多免費的「開源軟體」，如果開源模組有漏洞，是開源社群的責任還是我們的責任？免費的最貴，殘酷的真相就是，整合後將是您的責任。根據歐盟官方FAQ的釐清，純粹由非營利組織開發、未進行商業化的開源貢獻者可能獲得法規豁免。但是，「將該開源軟體商業化、整合進您的硬體或系統中，並對外販售的製造商（也就是您）」，必須承擔最終的合規責任。這代表，RD在引入開源軟體前必須做好風險評估，不能抱著「出事再說」的心態。
常見問題03：工程師把軟體成分用Excel或PDF條列出來，這樣符合CRA的SBOM規定嗎？不行，CRA的要求中是不接受手寫帳本的格式。CRA及相關調和標準（如正在起草的 EN 40000-1-x 系列）強烈要求 SBOM必須是「機器可讀（Machine-readable）」的格式。用 Excel 徒手記錄不僅容易出錯，更無法與漏洞資料庫自動對接。目前國際主流且受認可的格式主要有兩種：SPDX（由Linux基金會主導，為ISO/IEC 5962國際標準）。CycloneDX（由OWASP主導，專為應用程式安全與供應鏈分析設計）。建議企業主應考慮導入自動化工具來生成這兩種格式的SBOM。
常見問題04：這份SBOM是要公開在官網上讓所有人下載嗎？駭客不就可以按圖索驥來攻擊我們？
按法規所述的界線，並不需要完全公開。CRA並不強制要求製造商將SBOM「公開發布」在網路上。法規的要求是，您必須將SBOM納入內部的技術文件（Technical Documentation）中妥善保存。只有在歐盟市場監管機構（Market Surveillance Authorities）或符合性評估機構（Notified Body）進行稽核與調查時，您才需要提供給他們。它是合規的證明，而非駭客的導覽圖。
解方導入：用ISA/IEC 62443將SBOM無縫融入開發流程
在台灣，許多產品單位都忽略「正確性」的意義，SBOM是用來了解哪些弱點的相依關係，但是有許多開源或者商業工具並沒有辦法生成正確的清單，甚至包含一堆無用的「檔案」列表，除了造成使用的障礙，也不具備交換的意義。
CRA法規要求的不是「一張靜態的清單」，而是一套「持續動態的漏洞管理流程」。 產品上市後長達5年（或預期壽命內），只要爆發新漏洞，貴團隊都必須有能力處理，並針對歐盟Single Report Platform上的通報即時回應。實務上，公司內部產品也會有互相引用的狀況，應妥善考慮在接收通報時，就做好內部權責單位的協同作業，避免在CVE公告後，有使用到相關組件或產品的開發單位與產線在時限下手忙腳亂。
在這個階段，ISA/IEC 62443國際標準就是協助您將SBOM真正落地的最強武器。特別是針對開發流程的 ISA/IEC 62443-4-1（安全產品開發生命週期；Secure SDLC）：對接SM（Security Management）章節： 該章節規範了第三方組件與開源軟體的採購及安全評估流程。在RD決定引入某個開源套件前，就必須評估其維護活躍度與已知漏洞。
對接 SUM（Security Update Management）章節：該章節規範了如何利用SBOM來監控新發布的CVE 漏洞，並建立一套標準的修補程式（Patch）發布與測試機制。
專家觀點：一石二鳥的合規策略
如果您企業的研發流程已經取得了ISA/IEC 62443-4-1認證，這意味著您的Secure SDLC中已經先天包含了「軟體物料管理」與「漏洞應變」的核心精神。面對CRA的SBOM要求，您只需要微調自動化工具的產出格式（如輸出為SPDX），就能輕鬆跨越CRA的高牆，這對已經導入標準的廠商來說，簡直是「一石二鳥」的絕對優勢！
結語與行動呼籲：別讓開源盲區成為歐洲市場的絆腳石
SBOM是現代軟體供應鏈信任的基礎，更是未來歐盟海關、Single Report Platform稽核，以及B2B客戶採購時的必查項目。而從事件通報的角度來看，SBOM與SRP實際上是緊密相連的。為了滿足SRP嚴苛的24小時通報要求，製造商必須依賴精確且自動化的SBOM。
當零時差漏洞爆發時，企業無法再依賴員工們用人工方式翻找程式碼；擁有數位化、可自動查詢的SBOM是製造商能在數小時內確認「我的產品是否受影響？」、「哪些供應商組件有重大資安漏洞？」並啟動通報機制的唯一方法。
請問，貴公司的RD團隊，現在還在用人工Excel記錄第三方軟體嗎？您的團隊知道如何將SBOM整合進 CI/CD流水線，並建立自動化的漏洞警報機制嗎？法規倒數的時鐘滴答作響，與其閉門造車，不如讓專家團隊來協助您。
ISA台灣分會（ISA Taiwan Section）的業界合作平台，可對接研發流程與風險評估的專家團隊，同時，我們也強烈建議企業核心人員參與ISA原廠的專業證照培訓：Certificate 2（IC33）：風險評估專家 （Cybersecurity Risk Assessment Specialist）、Certificate 3（IC34）：設計專家（Cybersecurity Design Specialist）、IC47：系統／產品製造商與驗證評估人員專屬課程。
透過系統化的培訓，將儲備貴公司的開發團隊從源頭建立符合CRA要求的軟體供應鏈安全管理流程的能力。備戰CRA，您不需要單打獨鬥。立即聯絡ISA台灣分會進行培訓課程諮詢。
