電信與網路設備製造商的資安解決方案
路由器、交換器、無線基地台與無線電設備所出貨的韌體，是由嵌入式 Linux 發行版、晶片廠商 SDK 與數百個開源套件建置而成。主管機關與電信業者如今都在詢問每個版本裡有什麼。CRACI 執行您的韌體建置，並記錄進入其中的每個元件。
三套法規，同一個問題
路由器、交換器、無線基地台與無線電設備，目前須遵循歐盟無線電設備法規；自 2027 年 12 月起，須遵循 Cyber Resilience Act（CRA）對重要產品的規定；此外還須回應依 NIS2 必須查核供應商的電信業者。這三者最終都歸結於同一個問題：每一個韌體版本裡到底有什麼？
- 無線電設備指令的資安要求開始適用於連網無線電設備。
- Cyber Resilience Act 對遭積極利用的漏洞與嚴重資安事件的通報規定開始適用。
- Cyber Resilience Act 全面適用，無線電設備資安規定同時廢止。
無線電設備指令：授權規則（EU）2022/30
這項授權規則使無線電設備指令第 3(3) 條 (d)、(e)、(f) 款的基本要求開始適用：不得危害網路、保護個人資料與隱私，以及防範詐欺。它涵蓋連網無線電設備及部分其他類別，例如育兒設備、玩具與穿戴式裝置。它自 2025 年 8 月 1 日起適用，比原先規劃晚了一年。Wi-Fi 路由器與無線基地台是典型的連網無線電設備；純有線交換器則不屬於無線電設備。請自行確認您產品的分類。
EN 18031-1、-2 與 -3
EN 18031-1、-2 與 -3:2024 是對應 (d)、(e)、(f) 款的調和標準。其引用已於 2025 年 1 月刊登於歐盟官方公報，但附有限制：
- 「rationale」與「guidance」章節不提供符合性推定。
- 產品允許使用者選擇不設定或不使用密碼時，不提供推定（第 6.2.5.1 與 6.2.5.2 條）。
- 就 EN 18031-2 而言，缺乏家長或監護人存取控制的育兒設備與玩具不提供推定。
- 就 EN 18031-3 而言，6.3.2.4 的安全更新評估準則不提供推定。
實務上，採用上述任一選項的產品，其受影響的要求需要第三方評鑑。
過渡到 CRA
授權規則（EU）2026/339 自 2027 年 12 月 11 日起廢止 2022/30，這一天正是 CRA 全面適用之日，因為 CRA 的基本要求已涵蓋 RED 第 3(3) 條 (d)、(e)、(f) 款的所有內容。對於 2025 年 8 月 1 日至 2027 年 12 月 10 日之間投放市場的無線電設備，依無線電設備指令進行的市場監督將持續進行。CRA 要求在制定其自身標準時參酌 EN 18031 的成果；EN 18031 本身並不會直接成為 CRA 標準。因此，2027 年 12 月 10 日前投放市場的無線電設備依授權規則評鑑；自 2027 年 12 月 11 日起則適用 CRA。
網路設備的 CRA 類別
CRA 附件 III 列出重要產品。Class I 包括路由器、用於連接網際網路的數據機與交換器；網路管理系統；VPN 產品；實體與虛擬網路介面；以及作業系統。Class II 包括防火牆與入侵偵測及防禦系統。附件 IV 的關鍵產品並未列出路由器或交換器。
Class I 產品只有在完整採用調和標準、共同規格，或保證等級為「substantial」的歐洲網路安全驗證機制時，才能自行評鑑；否則須有指定機構參與（EU 型式檢驗加上型式符合性，或完整品質保證）。Class II 產品則一律需要上述其中一種途徑或驗證機制。在這些類別的 CRA 調和標準公布之前，Class I 製造商應預先規劃第三方評鑑。
CRA 通報
自 2026 年 9 月 11 日起，製造商須通報遭積極利用的漏洞與嚴重資安事件：24 小時內提出早期預警、72 小時內提出通報；最終報告則在漏洞修正可用後 14 天內提出，若為嚴重資安事件，則在通報後一個月內提出。
NIS2：與您的客戶相關
依 NIS2（指令（EU）2022/2555），公共電子通訊網路與服務的提供者不論規模大小都在適用範圍內。第 21 條要求他們管理供應鏈安全與漏洞處理，並考量每個直接供應商的漏洞、其產品的整體品質，以及其安全開發實務。這就是電信業者會向設備製造商寄送資安問卷與 SBOM 要求的原因。NIS2 的義務由電信業者承擔，而非設備製造商。
| 產品 | 授權規則 2022/30（至 2027 年 12 月 10 日） | CRA 類別（自 2027 年 12 月 11 日起） | 客戶通常會詢問的內容 |
|---|---|---|---|
| Wi-Fi 路由器 | 是：連網無線電設備 | 重要產品，Class I（路由器） | 每個韌體版本的 SBOM；每個 CVE 的「我們是否受影響？」 |
| 企業級交換器（純有線） | 否：不屬於無線電設備 | 重要產品，Class I（交換器） | SBOM、電信業者的資安問卷 |
| 防火牆設備 | 需確認：僅在具備無線電功能時適用 | 重要產品，Class II（防火牆） | 漏洞處理流程、SBOM、更新政策 |
| 網路管理軟體 | 否：不屬於無線電設備 | 重要產品，Class I（網路管理系統） | SBOM、安全開發佐證資料 |
| 無線接取單元 | 需確認：視產品而定 | 需確認：視其功能而定 | SBOM、漏洞處理、供應商問卷 |
| CPE 數據機 | 是，具備 Wi-Fi 時 | 重要產品，Class I（用於連接網際網路的數據機） | 每個韌體版本的 SBOM、更新支援期間 |
本內容為一般資訊，並非法律意見。請自行確認您產品的分類。
為什麼網路設備難以追蹤
韌體大多是別人的程式碼。嵌入式 Linux 發行版、SoC 廠商的 SDK 與核心修補程式、網路協定堆疊、數百個開源套件，以及在較新平台上的 Rust 與 Go 服務。每一項都會帶入各自的相依套件。
一套程式碼、多種平台、多個版本。同一套韌體會針對多種硬體平台建置，而且許多版本會同時在市場上使用。每個版本都是一組不同的元件。
掃描完成的映像檔只能推測。掃描韌體映像檔只能推斷其內容，並會遺漏編譯進去的部分。Yocto 自身的 SBOM 對 recipe 記錄得很完整，但在我們比較的建置中，它沒有為 Rust crate 提供套件 URL，因此無法與資安公告比對。進一步了解在 CRACI 上執行 Yocto 建置。另請參閱為什麼 SBOM 掃描工具會遺漏 Yocto 建置中的內容。
每出現一個受矚目的 CVE，客戶詢問就隨之增加。據我們從產品資安團隊聽到的情況，每一則詢問都從「我們是否受影響？」開始，而且每一則都需要針對每項產品、每個版本給出答案。
「我們是否受影響？」的示意案例
一個常見的壓縮函式庫公開了一個漏洞（虛構情境，僅供說明）。兩個產品資安團隊收到電信業者客戶提出的相同問題。
| 步驟 | 每次建置都有 SBOM 與建置歷史記錄時 | 只掃描完成的映像檔時 |
|---|---|---|
| 找出元件 | 在記錄的 SBOM 中搜尋該函式庫及其版本 | 重新掃描仍在市場上使用的映像檔（如果找得到的話） |
| 找出版本 | 建置歷史記錄會列出包含它的建置，不論是直接還是遞移相依 | 以人工比對掃描結果與版本說明 |
| 找出期間 | 含漏洞版本的第一次與最後一次建置，即為曝險期間 | 依映像檔的建置時間推估 |
| 回覆客戶 | 列出受影響與未受影響的產品及版本 | 附帶但書的最佳推測 |
進一步了解如何回答「我們是否受影響？」。
逐步準備
密碼處理與安全更新等產品資安功能屬於裝置本身。以下步驟涵蓋的是進入其韌體的內容。
- 為每項產品分類. 針對每項產品判斷：在 2027 年 12 月之前，它是否屬於授權規則所指的無線電設備；以及從那時起適用哪一個 CRA 類別。類別決定了符合性評鑑的途徑。
- 為每次版本發布建置產生 SBOM. 在每次韌體建置中記錄核心、SDK、取用的原始碼與每個套件，而不只是映像檔安裝的套件。若要為所有團隊與管線設定一致的 SBOM 政策，請參閱跨工程團隊的 SBOM 產生。
- 記錄哪些版本在何時出貨了哪些內容. 記下每個版本、其元件與出貨日期。這份記錄能讓「我們是否受影響？」變成一次查詢。
- 納入供應商與晶片廠商的 SBOM. 晶片廠商的 SDK 與授權使用的協定堆疊都是您韌體的一部分。請向他們索取 SBOM，並與您自己的 SBOM 一併監控。
- 持續監控並記錄未受影響的判斷. 每當有新漏洞公開時重新檢查每個版本，並以 VEX 記錄含漏洞的元件為何不會影響某項產品。
- 建立 CRA 通報流程. 遭積極利用的漏洞與嚴重資安事件的通報規定已自 2026 年 9 月 11 日起適用。請決定由誰研判、由誰決定通報、由誰回覆客戶；請參閱 PSIRT 的運作方式。
- 鎖定建置環境. 在隔離環境中以預設拒絕的對外連線政策進行建置，並封鎖已知有問題的版本，避免它們透過更新再次進入。
CRACI 的定位
CRACI 在自家執行器上執行您的 GitHub Actions 韌體建置，並記錄每個版本包含的內容，因此您給主管機關或電信業者的答案，直接來自建置本身。
記錄所有內容的韌體建置
在 CRACI 的 GitHub Actions 執行器上執行您的 Yocto 與其他嵌入式 Linux 建置，最高 32 vCPU，可選 x86-64 或原生 ARM64。建置執行期間，CRACI 會記錄它取用的每個套件與檔案，包括主機套件、Git 原始碼、GitHub Actions，以及任何 recipe 或鎖定檔都未列出的下載內容。在一次 core-image-sato 建置中，CRACI 的 SBOM 包含了 Yocto 自身 SBOM 中的所有元件，另外還有 88 個 Yocto 遺漏的元件，並為 653 個 Rust crate 版本各自提供了套件 URL。進一步了解在 CRACI 上執行 Yocto 建置。
供應商程式碼與您的程式碼並列
加入晶片廠商與其他供應商的 SBOM，外購元件就會與您建置的韌體一起受到監控。當下一個 SDK 漏洞出現時，廠商的程式碼與您的程式碼就在同一份記錄中。
分級研判、VEX 與政策關卡
資安團隊研判每項檢測結果，並轉派給負責修正的團隊。CRACI 支援以 VEX 記錄漏洞對您產品的影響，而政策關卡可以讓特定 CVE 不再進入之後的任何建置。
只連線到必要目標的建置
每個作業都在各自隔離的虛擬機器中執行，並套用您可設為預設拒絕的對外連線政策；政策在作業開始前完成驗證，並採失效即封鎖（fail closed）。採用預設拒絕政策時，連往建置不需要的主機的連線會遭到封鎖並發出警示。
CRACI 不適用的情況
CRACI 適用於您自行建置的韌體與軟體，但不適用於以下情況：
- 不適用於保護自家網路的電信業者，或為自身營運滿足 NIS2 要求的電信業者。CRACI 是為設備與軟體的製造商打造，對電信業者的幫助僅在於讓其供應商能提供更好的佐證資料。
- 不適用於在 GitHub Actions 以外建置的韌體，或在 Windows、macOS 上建置的韌體，也不適用於必須留在您自家機房的建置農場。GitLab CI 與 Jenkins、Windows 與 macOS 執行器，以及客戶自行託管的執行器，皆已列入產品藍圖。
- 不適用於非您自行建置的映像檔。CRACI 不掃描二進位檔或第三方韌體；這類情況您需要廠商提供的 SBOM 或二進位分析工具（請參閱 CRACI 與 ONEKEY 比較以及嵌入式資安工具比較）。
- 不是完整的 PSIRT 案件管理或資安公告發布系統。CRACI 不會將外部漏洞通報作為案件受理，也不發布資安公告，且不提供可達性分析。請參閱 PSIRT 工具比較。
- 不負責符合性評鑑、EN 18031 測試或產品資安功能，例如密碼處理、安全更新與存取控制。CRACI 不簽署韌體。
網路設備資安解析
設備製造商關於 RED、EN 18031、CRA 與 NIS2 的常見問題
哪些網路設備屬於 CRA 的重要產品？屬於哪一個類別？
附件 III 的 Class I 包括路由器、用於連接網際網路的數據機與交換器、網路管理系統、VPN 產品、實體與虛擬網路介面，以及作業系統。Class II 包括防火牆與入侵偵測及防禦系統。路由器與交換器不屬於附件 IV 的關鍵產品。
RED 的資安要求從何時開始適用？適用於哪些無線電設備？
自 2025 年 8 月 1 日起。授權規則（EU）2022/30 使無線電設備指令第 3(3) 條 (d)、(e)、(f) 款適用於連網無線電設備，以及育兒設備、玩具與穿戴式裝置等部分其他類別。這個日期是由後續的授權規則從 2024 年 8 月 1 日延後而來。
EN 18031-1、-2 與 -3 是否提供符合性推定？
是，但附有限制。其 rationale 與 guidance 章節不提供推定；使用者可選擇不設定或不使用密碼時不提供推定；就 EN 18031-2 而言，缺乏家長或監護人存取控制的育兒設備與玩具不提供推定；就 EN 18031-3 而言，6.3.2.4 的安全更新準則不提供推定。這些情況需要第三方評鑑。
CRA 適用後，RED 授權法規與 EN 18031 會如何？
授權規則（EU）2026/339 自 2027 年 12 月 11 日 CRA 全面適用時起廢止 2022/30。2027 年 12 月 10 日前投放市場的無線電設備，仍受 RED 市場監督管轄。EN 18031 將在 CRA 自身的標準中被參酌，但它本身不會直接成為 CRA 標準。
NIS2 對電信業者的供應商有什麼影響？
間接影響。NIS2 將義務加諸於電信業者，他們必須管理供應鏈安全，並考量每個直接供應商的漏洞、產品品質與安全開發實務。他們會透過資安問卷、SBOM 要求與合約條款將這些要求轉嫁給供應商。設備製造商本身的法律義務則來自 RED 與 CRA。
路由器或交換器製造商可以依 CRA 自行評鑑嗎？
只有在完整採用調和標準、共同規格，或保證等級為 substantial 的歐洲網路安全驗證機制時才可以，因為路由器與交換器屬於 Class I 重要產品。否則須有指定機構參與。在這些產品的 CRA 調和標準公布之前，請預先規劃第三方評鑑。
CRACI 支援 Yocto 嗎？
支援。Yocto 與 BitBake 建置可在 CRACI 執行器上執行，CRACI 會在建置執行時記錄作業的 SBOM。Yocto 自身的 SPDX 輸出仍帶有 CRACI 不記錄的 recipe 中繼資料，例如套用的修補程式，以及 recipe 標示為已修正的 CVE；如果您仰賴這些資訊，請保持 create-spdx 啟用。
CRACI 支援哪些 CI 系統與建置機器？
CRACI 在 Linux 執行器上執行 GitHub Actions 作業，支援 x86-64 與 ARM64，規格從 1 到 32 vCPU。GitLab CI 與 Jenkins 等其他 CI 系統已列入產品藍圖，Windows 與 macOS 執行器亦同。