「用了再說」該付出代價：CRA 如何把隱性的開源依賴變成經營風險

歐盟《網路韌性法》（Cyber Resilience Act，CRA）2027 年 12 月全面合規期限距今不到 18 個月，但全球開源生態系的整備狀況不但沒有改善，反而倒退。這不是一個遙遠的法規議題，而是一個正在計時的財務問題——對台灣出口導向的 ICT 中小製造業尤其如此。

趨勢與重點

Linux Foundation Research 與 OpenSSF 於 2026 年 6 月聯合發布《2026 CRA Awareness and Readiness Report》，由 LF Research、OpenSSF、Balena、Ericsson 與 Revanite 共同製作，是接續 2025 年報告《Unaware and Uncertain》的年度追蹤。兩份報告合計勾勒出一個幾乎沒有改善的停滯圖像。

整體世界對其認知「不升反降」

2025 年，62% 的全球受訪者對 CRA「幾乎不熟悉或完全不熟悉」；2026 年這個數字升至 66%（2026 年報告，第 7 頁）。在美國與加拿大，這個比例更高達 72%（第 8 頁）。CRA 的適用門檻是「在歐盟市場銷售含數位元素的產品」，與製造商總部所在地無關——北美企業把 CRA 視為「歐盟內部的事」，這個誤解將在 2026 年 9 月的第一個硬性期限（漏洞與資安事件強制通報義務）到來時，直接轉化為法律風險。

知道 CRA 的人，也大多看不懂它

在已知 CRA 的受訪者中，54% 仍搞不清楚「製造商」（manufacturer）與「管理人」（steward）的角色區別——這是判斷自身義務的基本概念，一年前是 57%，幾乎沒有改善（2026 年報告，第 9 頁）。只有 34% 正確指出 2027 年 12 月是全面合規日期（第 9 頁）；僅 41% 的製造商預期能在期限前達到完全合規（第 15 頁）。

被動等待上游的習慣正在惡化

仍被動仰賴上游專案提供安全修補的比例，從 2025 年的 46% 上升至 2026 年的 51%（第 13 頁）。與此同時，各組織平均維護 86 個私有分支（private fork），作為處理上游無法或不願修補的應急措施。LF Research 的分析顯示，平均每個私有分支在每次發布週期的人力成本約為 25 萬 8 千美元；對員工超過 5,000 人的組織，整體負擔超過 11,000 個工時（第 14 頁）。

中小企業承受最大的結構性曝險

62% 的中小企業產品有四分之三以上仰賴開源軟體，遠高於大型組織的 35%（第 13 頁）。只有 32% 的製造商為所有產品產出軟體物料清單（SBOM）。

安全威脅與法規壓力同步升高

根據 LFX 平台索引的 14,000 多個開源專案，2026 年第一季公布的 CVE 數量年增 394%，高嚴重性漏洞更增加 811%（第 24 頁）。報告指出 AI 驅動的自動化掃描是部分原因，但漏洞數量本身是真實的，而 AI 工具降低了漏洞利用的技術門檻，使整備窗口壓縮得更緊。

大多企業從開源社群是認知到本議題，而不是從傳統官方監管管道

在已知 CRA 的受訪者中，48% 是透過研討會、開源工具文件或社群媒體得知，而透過官方歐盟管道得知的只有 25%（第 8 頁）。

我的觀察

「用了再說」已是經營風險，不只是治理問題

長期以來，企業對開源軟體的預設策略是「免費使用、被動等待上游修補、出了問題再處理」。這個模式在 CRA 框架下暴露了它從未被正視的真實成本：一旦上游無法提供及時修補，組織就只能維護私有分支，而私有分支的維護成本會隨著產品線累積成結構性負擔。

AI 工具的普及進一步加速了這個矛盾。AI 代碼生成工具讓開發者更快納入開源元件，卻不必然增加對這些元件來源、授權與安全狀態的了解。結果是：開源依賴度上升，但整備能力並未跟上。CVE 年增 394% 的數字，有一部分正是 AI 掃描把潛藏問題浮出水面；但製造商如果仍被動等待上游，就等於把自己的合規風險外包給一個自己沒有能力掌握節奏的外部機制。

這個邏輯不再停在治理層面。它已是帳面可以計算的財務決策：86 個私有分支、每次發布週期 25 萬 8 千美元，是可以拿去說服管理層的數字。

上游貢獻從選擇題變成成本試算題，從治理討論變成經營關係

過去，向上游開源專案貢獻資源（程式碼、維護人力、資金）被定義為企業社會責任或開源治理立場。CRA 的 SBOM 要求與來源可追蹤性規範，改變了這個框架。

當私有分支策略在合規層面越來越難持續，上游貢獻就從「可以做但沒必要」，變成「不投入就要自己承擔更高的合規維護成本」。2026 年報告引用 LF Research 的貢獻 ROI 分析，以及「多組織參與的開源專案安全評分與參與組織數量呈正相關（Spearman 係數 0.57）」這項新發現，提供了一個可量測的論述基礎（第 23 頁）。

這個轉變的含義是：是否投入上游，不再是工程師或 OSPO 的內部治理討論，而是一個需要財務長與法務長一起計算的採購與合規問題。

開源社群是 CRA 認知的主要入口，但自己也是最大的認知盲區

48% 透過社群管道、只有 25% 透過官方渠道得知 CRA，這個數字的解讀方式是雙向的。正面的解讀是：技術社群、基金會與維護者社群擁有官方監管渠道無法取代的傳遞能力。負面的解讀是：一年過去了，這套傳遞機制並沒有讓全球不熟悉比例從 62% 下降，反而從 62% 升到 66%。

OpenSSF 報告的說法是「缺的不是資訊，是把合規語境嵌入開發者日常工作流的社群機制」。

這意味著，光是把課程、文件和政策頁面做好是不夠的；需要的是讓合規意識進入 Pull Request 流程、進入套件管理工具的使用情境、進入社群的技術提問與解答文化中。指引已存在，但進入日常實踐的最後一哩路尚未打通。

這也是開源社群需要誠實面對的：做為 CRA 認知傳播最主要的渠道，社群同時是傳播者，也是受眾的一部分——許多人既不清楚 CRA 如何適用自己，也還沒找到方法把這套語境轉化給同儕。

台灣中小企業的雙重曝險

台灣以出口導向 ICT 製造業著稱，大量中小型硬體與嵌入式系統廠商的供應鏈高度依賴開源元件，產品同時進入歐盟與北美市場。把報告的兩個數字疊加在一起，可以看到台灣中小廠商面對的結構性處境：

第一，全球中小企業有 62% 的產品四分之三以上仰賴開源軟體，遠高於大型組織的 35%——開源依賴度高；

第二，美加地區的 CRA 認知缺口（72% 不熟悉）比全球平均（66%）更大，而台灣目前沒有直接的調查數字，但以相似的出口市場結構與非歐盟地理位置，估計認知缺口不小於北美水準。

在 CRA 框架下，這些廠商屬於「製造商」而非「管理人」，承擔主要的合規義務，包括：主動管理開源元件安全、產出 SBOM、建立漏洞揭露流程。距離 2027 年 12 月全面合規期限不到 18 個月，而第一個硬性期限「強制通報已被主動利用的漏洞與嚴重資安事件」將在 2026 年 9 月到來。若連「CRA 是否適用自己」都尚未評估，整備窗口已相當有限。

後續建議

對企業（特別是中小製造商）

立即評估 CRA 適用性是最低起點，不是可以推遲的事。判斷自身屬於「製造商」還是「管理人」，決定了義務的性質與範圍。OpenSSF 的《CRA Readiness Guide for Maintainers and Developers》與《Stewards Playbook》（openssf.org/CRA）提供了依角色分類的實作步驟，可作為自評的第一份工具。對於有出口歐盟產品的台灣廠商，建議把 2026 年 9 月的漏洞通報義務列為最近期的合規行動項目。

對開源社群與基金會

如果 48% 的人是透過開源社群管道得知 CRA，那麼基金會、技術社群、開源工具維護者承擔著官方監管渠道無法替代的角色。接下來需要做的不是再製作更多文件，而是把合規語境嵌入開發者實際使用的工具——在套件管理工具的相依性報告中標注授權與安全狀態，在 PR review 流程中整合 SBOM 生成提示，讓合規不是另一份要閱讀的清單，而是工作流的一部分。

對政策討論

台灣目前缺乏針對本地廠商 CRA 認知狀況的系統性調查。在這個議題的討論中，「台灣廠商的準備度如何」是一個有數據缺口的問題。產業公會、資策會或學研機構若能複製類似 OpenSSF 的追蹤方法，建立在地基準數據，才能讓政策介入的優先順序有事實依據。

本文整合自下述來源，AI 協助彙整後，經由 Ian 人工審閱後發出