2026 年每日通報的 CVE 數量比前一年多 131%。

海事軟體與設備製造商的網路安全

如今的船舶仰賴來自數十家供應商的軟體運作,而船級規則與歐盟法規都期望每家供應商掌握其軟體包含哪些內容,並確保其安全。CRACI 會執行您的 GitHub Actions 建置,並記錄每個版本納入的每一個元件。

哪些規範適用於哪些海事產品

海事供應商須面對三套彼此重疊卻不完全一致的規範:歐盟產品法規、新造船的船級規則,以及 IMO 為船舶營運者提供的指引。在規劃佐證資料之前,請先釐清每項產品適用哪一套規範。

CRA 排除海事設備指令所涵蓋的設備

Cyber Resilience Act(CRA),即規則(EU)2024/2847,第 2 條第 4 項規定:「本規則不適用於屬於指令 2014/90/EU 適用範圍內的設備。」該指令即海事設備指令(Marine Equipment Directive,MED),涵蓋已裝載或將裝載於歐盟船舶上、且依 IMO 公約須經船旗國主管機關核准的設備,也就是帶有 wheel mark(舵輪標誌)的設備。例如雷達、ECDIS、AIS 與航行資料記錄器等航行設備、無線電通訊設備、防火設備與救生設備。請針對您自己的品項,查閱最新的 MED 施行清單。

仍在 CRA 適用範圍內的產品

投放歐盟市場、且非 MED 設備的具數位元素產品:以產品形式銷售(安裝或下載)的船上與岸上軟體;船舶營運、住艙、餐飲與旅館管理系統;船員與乘客服務系統;船隊與航程管理軟體;船上 IoT 感測器與閘道器;不需船旗國核准的監控與自動化設備。單純的軟體即服務不在 CRA 範圍內,除非它是產品的遠端資料處理,不過其供應商仍可能適用 NIS2。

有些情況需要法律意見,而非單靠規則判斷:銷售給非歐盟船旗船舶的 wheel mark 型式設備,以及將 MED 設備與 MED 範圍外之軟體模組結合的產品。

IACS UR E26 與 E27

國際船級協會(IACS)的統一要求是透過船級制度適用,而非歐盟法規。兩者的 Rev.1 適用於 2024 年 7 月 1 日(含)以後簽訂建造合約的船舶。對於從事國際航行的客船與高速船、從事國際航行的 500 GT 以上貨船、移動式離岸鑽探平台及部分自航式離岸裝置,這些要求是強制性的;對其他船舶則作為指引。因 MED 而不在 CRA 範圍內的產品,仍可能在 E26 與 E27 範圍內,反之亦然。

IMO

MSC.428(98) 號決議要求船舶營運者,最遲須在 2021 年 1 月 1 日後公司符合文件(Document of Compliance)的首次年度查核前,於其安全管理系統中處理網路風險。IMO 海事網路風險管理指引是為營運者提供的非強制性高層級指引。其 2026 年 5 月的最新修訂版指出,網路風險管理應考量第三方廠商、嵌入式系統,以及軟體與硬體供應鏈,並要求營運者為關鍵系統訂定軟體與硬體供應鏈安全政策。這就是營運者會把這個問題轉向供應商的原因。

產品範例帶有 wheel mark(MED)?Cyber Resilience ActIACS UR E26 與 E27供應商必須提出的內容
ECDIS是排除(第 2 條第 4 項)是,適用於範圍內的新造船MED 核准;E27 文件與軟體資產清冊
新造貨船上的主機自動化系統需確認是,除非屬於 MED 設備是:推進系統屬於涵蓋的系統E27 文件、資產清冊與安全開發生命週期;CRA 技術文件與 SBOM
旅館與餐飲管理軟體否是,以產品形式銷售時需確認:E26 涵蓋其連接至涵蓋系統的網路介面CRA 所需的 SBOM 與漏洞處理
船員福利網路設備否是需確認:E26 涵蓋其連接至涵蓋系統的介面CRA 所需的 SBOM 與漏洞處理
以軟體即服務提供的船隊管理軟體否不適用,除非它是產品的遠端資料處理否:它在岸上執行回覆營運者的供應商問卷;供應商可能適用 NIS2
船上狀態監測感測器需確認是,除非屬於 MED 設備需確認:屬於涵蓋系統的一部分時在範圍內CRA SBOM;屬於涵蓋系統的一部分時須提供 E27 文件

經驗法則:如果您的產品需要 wheel mark,CRA 就不適用;如果它裝在 2024 年 7 月以後簽約的船上,E27 很可能適用;如果您在歐盟銷售軟體或連網產品,請假設 CRA 適用。

E26 與 E27 對供應商的要求

E27 是直接觸及設備供應商的要求。第 3.1 節列出供應商須就電腦化系統向船級協會提交的文件,其中包括:

  • 資產清冊(3.1.1):硬體元件,及其系統軟體(例如作業系統與韌體)的名稱、版本與修補程式層級;以及軟體元件,每項皆列出其安裝所在的硬體、製造商、型號或類型、用途與軟體版本。
  • 資安功能說明(3.1.3)及其測試程序、資安組態指引,以及維護、事件應變、復原與變更管理計畫。
  • 安全開發生命週期文件(3.1.6),其中也說明如何處理軟體更新與修補。

第 4 節訂定必要的資安功能,以 IEC 62443-3-3 中選定的系統要求為基礎,例如身分驗證與惡意程式碼防護。這些是產品本身的功能。

第 5 節要求安全開發生命週期涵蓋需求、設計、實作、驗證、發布、維護與終止支援,並記錄在由船級協會審查的文件中。其中必須包含取自 IEC 62443-4-1 的控管措施:程式碼簽章金鑰的保護(SM-8)、為使用者記錄安全性更新(SUM-2)、記錄相依元件或作業系統的安全性更新(SUM-3)、更新的真實性交付(SUM-4),以及縱深防禦與強化指引(SG-1 至 SG-3)。

E26 在船舶層級補足了這個循環:船舶資產清冊列出硬體與軟體,並沿用各供應商 E27 資產清冊中的欄位,須在船舶整個使用期間保持更新,而可能引入新漏洞的軟體與硬體變更也都會記錄在其中。

E27 沒有提到的是:它並未提及 SBOM。每個版本的 SBOM 是為資產清冊產出軟體版本、以及提供 SUM-3 所需相依元件資訊最精確的方式,但它是用來支援這些要求,而不是要求本身。

E26 或 E27 要求船級協會或船廠的期望來自建置的佐證資料仍由您負責的部分
E27 資產清冊(3.1.1)每個軟體元件及其用途與版本,以及每個硬體元件的系統軟體每個版本的 SBOM,列出每個元件及其版本每個元件安裝在哪個硬體上、製造商與型號細節
SUM-2 與 SUM-3 更新文件有記錄的安全性更新,包括相依元件與作業系統的更新每個版本中元件的漏洞記錄與建置歷史您發送給使用者的更新說明與資安公告
SM-8 與 SUM-4受保護的程式碼簽章金鑰與更新的真實性交付無:CRACI 不簽署軟體您的簽章流程與金鑰保管
第 4 節資安功能身分驗證、惡意程式碼防護與其他產品功能無:這些是產品功能產品設計及其測試
第 5 節生命週期文件經審查的說明,描述各階段如何處理資安證明發布階段受到控管的記錄:每次建置包含什麼、能連線到哪裡撰寫文件並執行流程
E26 船舶資產清冊船舶的資產清冊,在其整個使用期間保持更新您匯出的 SBOM,交給系統整合商哪個版本安裝在哪艘船上,以及移交給船廠或系統整合商

為什麼海事軟體難以追蹤

船舶的壽命比專案更長。一艘船會服役數十年,船上軟體的支援負擔,會比交付它的專案、打造它的團隊,甚至往往比供應商自己的產品線存續得更久。

眾多小型供應商與系統整合商。一艘船搭載來自數十家供應商的軟體,由系統整合商組裝,而每一次移交,都可能讓人無法掌握每個版本包含哪些內容。

船上系統無法隨意更新。更新必須等待靠港、船級核准或維護時段,因此在修正推出後很久,舊版本仍會持續服役。您必須知道哪些船仍在執行哪個版本。

偏遠地點,連線有限。海上船舶與偏遠設施難以連線,因此安裝內容的記錄必須存在岸上,並來自建置,而不是來自對船舶的掃描。

以試算表作為記錄系統。我們從海事軟體製造商那裡聽到,SBOM 與相關記錄分散在許多以人工維護的試算表中。每次發布新版本,這些資料就會變得更過時。

逐步準備

身分驗證等資安功能屬於產品設計的範疇。以下步驟涵蓋的是關於產品所含軟體的佐證資料。

  1. 將每項產品對應到其適用規範. 針對每項產品,判斷它是 MED 設備、CRA 產品、屬於 E26 與 E27 範圍,或同時屬於其中多項。佐證資料計畫便依這份對應來擬定。
  2. 為每個版本產生 SBOM. 記錄您建置的每項產品在每個版本中納入的內容,包括遞移相依套件,讓軟體資產清冊來自建置,而不是來自記憶。
  3. 為每個安裝地點維護資產清冊. 追蹤哪個版本安裝在哪艘船上,以及何時變更。這些資訊會提供給 E27 資產清冊,以及系統整合商的 E26 船舶資產清冊,後者會記錄船舶整個使用期間的變更。
  4. 監控漏洞並通報. 在新漏洞公開時重新檢查已出貨的版本。對於 CRA 範圍內的產品,遭積極利用的漏洞與嚴重資安事件的通報,自 2026 年 9 月 11 日起已開始適用。
  5. 阻止已知有漏洞的套件進入建置. 封鎖會出貨已知漏洞的建置,避免漏洞透過相依套件更新再次出現。
  6. 為客戶與系統整合商記錄安全性更新. 依照 SUM-2 與 SUM-3 的期望,告知客戶與系統整合商每個安全性更新修正了什麼,包括相依元件與作業系統中的修正。

CRACI 的定位

CRACI 在自己的執行器上執行您的 GitHub Actions 建置,並記錄每個版本納入的內容。這份記錄就是 CRA、您的 E27 文件與客戶提問背後共同的佐證資料。

記錄每一個版本

您的建置透過 runs-on: craci 在 CRACI 的 GitHub Actions 執行器上執行,執行結果仍會顯示在 GitHub 中。在每次建置執行時,CRACI 會記錄它取用的每一個套件(包括 npm 與 PyPI),連同任何鎖定檔都未列出的隱藏相依套件,並為每個作業標示完整性狀態。SBOM 可匯出為 CycloneDX 或 SPDX,並包含遞移相依套件、宣告的授權,以及在其元件中找到的漏洞:這正是 E27 資產清冊軟體部分的原始資料。進一步了解建置時 SBOM。

An SBOM recorded during the build Packages from npm, PyPI, Cargo, Go, OCI registries and the CI cache pass through a package-aware proxy on the CRACI runner. The job's SBOM lists what was fetched, states its completeness and exports as CycloneDX or SPDX. Package sources npm PyPI Cargo · Go OCI registries CI cache restore Package- aware proxy on the runner Job SBOM express 5.2.1 requests 2.32.3 serde 1.0.219 + transitive deps Declared license on every component Complete Completeness states per job and cache: Complete, Complete with connections, Incomplete, Unavailable, Not recorded CycloneDX · SPDX

阻擋有漏洞的套件

政策關卡可以封鎖含有特定 CVE 的建置,授權政策規則也可以依授權封鎖建置。已知問題會在 CI 中被攔截,不會隨版本發布到船上。

Policy gates in CI Every build on CRACI records its SBOM, runs under an egress policy and records provenance data. Policy gates can block the build on findings or on a license, so issues are caught in CI before release. Pull request New dependencies, added by a developer or an AI agent Every change reaches the build the same way CRACI build SBOM recorded Egress enforced Provenance Every build, no extra step Policy gate Findings or licenses outside your policy Build blocked Or passes to release

掌握哪些版本受到影響

每當有新漏洞公開,CRACI 都會持續重新評估受監控的 SBOM,建置歷史會在您方案的保存期限內,顯示哪些建置含有該有漏洞的相依套件,而資產清冊檢視則顯示哪些軟體版本部署到哪些產品。資安團隊會研判每一項檢測結果,並將其轉交給負責修正的團隊。對於 CRA 範圍內的產品,CRACI 會準備 CRA 通報的內容,再由貴公司的人員透過單一通報平台(Single Reporting Platform)提交。

Vulnerability tracking after release After a release ships, its SBOM stays monitored. When a new vulnerability is published, CRACI re-evaluates the monitored SBOMs, finds the affected releases, and the security team triages the finding and routes it to the team that owns the fix. The inventory view shows which software versions are deployed to which products. Release shipped SBOM monitored Later New advisory published Re-evaluated automatically Finding: critical, in 2 releases 1. Triage 2. Route to owner 3. Team fixes Policy gates can block a build on findings · VEX supported Inventory: deployed versions Product Version Web app v4.12.0 Mobile API v2.3.1

不會外洩機密的建置

每個作業都在專屬的隔離虛擬機器中執行,並受對外連線政策規範。此政策可設定為預設拒絕,會在作業開始前驗證,並採失效即封鎖(fail closed)。在預設拒絕政策下,連往建置不需要之主機的連線會遭到封鎖,並觸發警示。

An egress policy on the build network A build job connects to hosts in its egress policy, such as package registries and Git, and a connection to a host outside the policy is blocked. The policy is validated before the job starts and fails closed, and a violation sends an alert. Egress policy Default deny Validated before the job starts Fails closed · 24 source presets Build job on a CRACI runner npm registry allowed PyPI allowed Git over HTTPS allowed Unapproved host blocked Alert on policy violation Connections are recorded in the job's network trace

CRACI 不適用的情況

CRACI 是為打造軟體的團隊而設計。它不適合以下情況:

  • 不適合船舶營運者與船東:若您要找的是船上網路監控、入侵偵測、船舶層級的 E26 合規,或安全管理系統所需的文件,CRACI 並不適合。CRACI 是為打造軟體的人而設計,而不是為執行軟體的船隊。
  • 不是 MED 設備製造商的 CRA 方案:帶有 wheel mark 的設備不在 CRA 範圍內。不過,只要相關軟體建置在 GitHub Actions 上執行,CRACI 仍可為 E27 與客戶要求記錄這些建置。
  • 不適合不在 GitHub Actions 上建置的供應商,也不適合需要 Windows 或 macOS 建置機器,或需要在自己雲端帳戶內執行執行器的供應商。CRACI 目前在歐洲基礎架構上執行代管的 Linux 執行器;其他 CI 系統、Windows 與 macOS 執行器,以及客戶自行託管的執行器,皆已列入產品藍圖。
  • 不處理硬體物料清單。CRACI 記錄的是軟體;它不管理硬體 BOM。
  • 不提供 E27 資安功能,也不是船級核准。CRACI 不實作身分驗證、惡意軟體防護或其他產品功能,不簽署軟體,不替您撰寫安全開發生命週期文件,也不代您與船級協會往來。
  • 不是修補指標工具:CRACI 不回報平均修補時間或修補期限。

海事網路安全說明

海事供應商對 CRA、IACS UR E26 與 E27 以及 IMO 指引的常見問題

Cyber Resilience Act 是否適用於海事設備?

不適用於屬於海事設備指令 2014/90/EU 適用範圍內的設備。CRA 第 2 條第 4 項明確將其排除。這涵蓋依 IMO 公約須經船旗國核准、帶有 wheel mark 的設備。其他銷售給船舶的連網產品與軟體,例如旅館系統、船員網路、感測器,以及安裝在船上的船隊管理軟體,仍可能受 CRA 規範。

哪些海事產品被排除在 CRA 之外?

屬於海事設備指令適用範圍內的設備:裝載於歐盟船舶上、依 IMO 公約須經船旗國核准的設備,例如雷達、ECDIS、AIS、航行資料記錄器、無線電通訊、防火與救生設備。請針對您的品項查閱最新的 MED 施行清單,並就混合型產品或其他船旗的船舶尋求法律意見。

什麼是 IACS UR E27?誰必須遵循?

UR E27 是國際船級協會(IACS)針對船上系統與設備網路韌性的統一要求。Rev.1 適用於 2024 年 7 月 1 日(含)以後簽訂建造合約的船舶,對於從事國際航行的客船、高速船與 500 GT 以上貨船,以及部分離岸裝置為強制性要求。涵蓋系統的供應商須透過船級協會遵循。

E26 與 E27 對設備供應商有哪些要求?

E27 要求供應商提供文件,包括列出每個軟體元件及其版本的資產清冊、取自 IEC 62443-3-3 的資安功能,以及包含 IEC 62443-4-1 控管措施(例如記錄安全性更新)的安全開發生命週期。E26 則是船舶層級的要求:船舶資產清冊採用相同欄位,並須在船舶整個使用期間保持更新。

UR E27 是否要求 SBOM?

否。E27 並未提及 SBOM。它要求的是列出每個軟體元件及其版本的資產清冊,以及相依元件與作業系統安全性更新的文件。每個版本的 SBOM 是產出這些資訊最精確的方式,但並非 E27 的要求。

IMO 網路風險管理指引是強制性的嗎?

否。IMO 海事網路風險管理指引是為船舶營運者提供的非強制性指引,已於 2026 年 5 月修訂。對營運者的期望來自 MSC.428(98) 號決議,要求他們在安全管理系統中處理網路風險,而指引現在也要求營運者訂定軟體與硬體供應鏈安全政策。

CRA 是否適用於銷售給航運公司的軟體?

通常適用:只要它以具數位元素產品的形式(安裝或下載)在歐盟市場銷售,且不是 MED 設備。純粹以服務形式提供的軟體不在 CRA 範圍內,除非它是產品的遠端資料處理,不過其供應商仍可能適用 NIS2。請確認每項產品的分類。

了解您的版本納入了哪些內容

預約示範,我們將展示您的建置取用的每一個元件,以及新漏洞會影響您的哪些版本。

預約示範