國際自動化協會臺灣分會

ISA是工控自動化的專業平台

CRA Requirements and SBOM

SBOM（軟體物料清單）大解密：歐盟 CRA 合規的「關鍵拼圖」與開源軟體陷阱

—

作者:

ISATaiwanSection
分類: , ,

ISA臺灣分會 林上智、賴俊福、詹燿州 共同撰文 | 2026

在上一篇文章中，我們釐清了歐盟《網路韌性法案》（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 Requirements and SBOM

為什麼歐盟 CRA 強制要求 SBOM？

要了解 SBOM 的重要性，我們必須先看懂歐盟立法的底層邏輯。

1. 法規依據：CRA 附件一的強制要求

根據 CRA 附件一（Annex I）Part 2 針對「漏洞處理（Vulnerability handling）」的基本要求，製造商必須識別並記錄產品中包含的漏洞與組件，其中明文規定必須「建立並維護機器可讀的軟體物料清單（SBOM）」。這不再是加分項目，而是必考題。

CRA Annex I Part II: vulnerability handling requirements
CRA Annex I Part II: vulnerability handling requirements

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 在引入開源軟體前必須做好風險評估，不能抱著「出事再說」的心態。

SBOM Lifecycle
Source: 林上智. (2024, May 16). 軟體物料清單 （ SBOM ） 實務應用：探討常見誤區與關鍵指引

常見問題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）發佈與測試機制。
EU CRA Software Bill Of Materials
Image credit: Google Gemini

專家觀點：一石二鳥的合規策略

如果您企業的研發流程已經取得了 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 臺灣分會進行培訓課程諮詢，讓我們一起為您的產品打造最強韌的資安護城河！

備註：This article does not speak for the International Society of Automation (ISA) | 本篇報導不代表國際自動化協會 (ISA) 立場

CRA 相關系列文章:

  • 歐盟 CRA 風暴來襲：台灣​製造業的「滅絕級」挑戰還是轉型契機？[點選閱讀]
  • 歐盟 CRA 法規全解析：別以為只是硬體的事！軟體、韌體到雲端，管轄範圍一次看懂 [點選閱讀]
  • Dr. Lukasz Kister 解析歐盟 Cyber Resilience Act 關鍵挑戰與應對策略摘要整理 [點選閱讀]
  • 用 ISA 官方課程建立符合 CRA 期待的資安開發基礎。[點選閱讀]

參考資料：

留言

發表迴響