跳至主要內容
返回技術博客

· 約 4 分鐘閱讀 ·

歐盟 CRA 通報義務上路兩個月:24 小時的時鐘,外包合約要先寫清楚

歐盟 Cyber Resilience Act 的漏洞與事件通報義務從 9 月 11 日起適用,ENISA 的單一通報平台 11 月 4 日升級到 1.3 版。整理目前確定的規則、還沒說清楚的地方,以及接案與外包專案該在合約裡補上的幾件事。

  • Cyber Resilience Act
  • 資安
  • 外包合約
  • 趨勢
本文目錄
  1. 一、目前確定的規則
  2. 二、還沒說清楚、或這篇沒處理的地方
  3. 三、對接案與外包的意義
  4. 四、合約與交付該補上的清單

歐盟 CRA 通報義務上路兩個月

歐盟《網路韌性法》(Cyber Resilience Act,CRA)第 14 條的通報義務,從 2026 年 9 月 11 日起適用。同一天,ENISA 上線了 CRA Single Reporting Platform(SRP);SRP 頁面也註明平台在 11 月 4 日升級到 1.3 版,相關文件仍在更新中。歐盟執委會的 CRA reporting 說明頁整理了通報流程與時限。

這篇不是法律意見。我想談的是:當你的客戶把產品賣進歐盟,而產品是你(或你的團隊)開發的,這個 24 小時的時鐘會怎麼落到交付流程和合約上。

一、目前確定的規則

依據執委會說明頁:

  • 誰要通報:「具數位元素產品」(products with digital elements)的製造商。
  • 通報什麼:正被主動利用的漏洞(actively exploited vulnerabilities),以及影響產品安全的嚴重事件。
  • 時限:知悉後 24 小時內提出早期預警;72 小時內提出完整通報;漏洞在修正措施可用後 14 天內交最終報告,嚴重事件則在 72 小時通報後一個月內交最終報告。
  • 怎麼通報:透過 SRP 通報一次,送到製造商主要營業據點所在國的 CSIRT,ENISA 同步收到。
  • 開源管理者(open-source software stewards):通報義務從 2027 年 12 月 11 日才適用。

另外兩份律師事務所的整理補充了幾個重點。Hogan Lovells 在 9 月 11 日的文章與 Jones Day 在 7 月的 alert 都引用執委會的指引指出:

  • 已經在歐盟市場上的舊產品也適用,不是只有新上市的產品。
  • 9 月 11 日之前已知的漏洞利用不需要追溯通報。
  • 「知悉」指的是經初步評估後,有合理程度的確定性認為漏洞正被利用,或嚴重事件已經影響產品安全。
  • 製造商必須通知受影響的使用者,適當時通知所有使用者(Hogan Lovells 註明是第 14 條第 8 項)。
  • Jones Day 提到,違反規定的罰款上限為 1,500 萬歐元或全球年營業額 2.5%,取較高者。

CRA 其他大部分要求(包含產品本身的資安要求)要到 2027 年 12 月 11 日才全面適用。現在先上路的只有通報這一塊。

二、還沒說清楚、或這篇沒處理的地方

  • 你的產品在不在範圍內,要看產品型態與用途,這篇沒辦法替你判斷。純 SaaS、內部系統、硬體韌體的情況差很多,請找熟悉 CRA 的律師確認。
  • 「製造商」是誰,在外包情境特別容易模糊。我的理解是以「用自己名義把產品放上市場的一方」為主,通常是客戶而不是接案方,但這是我的讀法,不是法律結論。
  • 我沒有直接讀到執委會 7 月發布的完整指引,上面關於舊產品與「知悉」的說明來自兩家律師事務所的整理。
  • SRP 的文件還在跟著 1.3 版更新,Hogan Lovells 也提到自願通報(第 15 條)在上線版本還沒有。細節可能還會變。

三、對接案與外包的意義

規則寫的是製造商,但 24 小時內要回答「這個漏洞有沒有影響我們的產品、影響哪些版本、有沒有在被利用」,靠的是開發方的資訊:

  • 產品用了哪些套件、哪些版本?
  • 哪個版本部署在哪些客戶那裡?
  • 半夜接到通知,誰能在幾小時內判斷影響範圍?
  • 修正要多久才能出?

如果這些資訊只存在接案工程師的腦袋裡,或專案結案後就沒人維護,客戶的 24 小時時鐘會直接撞牆。這也是為什麼我一直主張交付要從架構和可維護性開始:能交接、能追蹤的東西,在這種時候才有用。

反過來說,對接案方這也是機會。能在合約裡清楚寫出「漏洞發生時我們怎麼配合」的團隊,對要賣進歐盟的客戶會更有說服力。

四、合約與交付該補上的清單

  1. **元件清單列為交付物。**每次正式發布都附上相依套件與版本清單(SBOM 格式最好,例如 CycloneDX 或 SPDX),而不是只交程式碼。
  2. **寫明漏洞通知時限。**接案方發現或收到漏洞資訊後,要在幾小時內通知客戶的指定窗口。這個時限必須比 24 小時短得多,客戶才有時間評估與通報。
  3. **定義維護期與維護方式。**結案後誰負責安全更新、持續多久、怎麼計費。可以參考我寫過的接案合作模式,把維護做成 retainer。
  4. **版本與部署紀錄要能追溯。**哪個版本、哪一天、部署到哪個環境,要有紀錄,不能只靠記憶。
  5. **約定聯絡窗口與升級路徑。**雙方各留主要與備援聯絡人,寫清楚非上班時間怎麼找到人。
  6. **一年做一次演練。**拿一個真實的 CVE 走一次流程:判斷影響、通知、修正、出版本,看看實際要花多久。另外,Hogan Lovells 引述 ENISA 的建議:負責人員先設好 EU Login 與多因素驗證,真的需要通報時再註冊為 Assigned Representative。

CRA 的通報義務只是第一步,2027 年底還有更完整的產品要求。現在把元件清單、通知時限和維護期寫進合約,成本不高,事情發生時卻差很多。如果你正在規劃要賣進歐盟的產品,或想替外包合約補上資安交付條款,歡迎預約 30 分鐘初談。

SUBSCRIBE

新文章寄到你的信箱

每月約 2–4 篇,主題是 AI 導入、Web 工程與維運。只在有新文章時寄出,隨時可以退訂。

送出後會收到一封確認信,點擊確認才會開始寄送。確認信可能被歸到垃圾郵件,請留意一下。

用 RSS 訂閱

習慣用 Feedly、Inoreader 或其他閱讀器?加入這個網址即可。

https://www.8plus.app/feed.xml
開啟 RSS

想把文章裡的想法落地?

預約一場諮詢,讓我們針對你的系統與流程一起討論可行的做法。