歐盟 CRA（Cyber Resilience Act）漏洞處理

Julian Meroi · 發布日期 2026年11月9日 · 最近校閱 2026年11月9日

網路韌性法案要求製造商在產品的支援期間內，持續處理產品的漏洞。實務上，這代表要有一套流程，能接收通報、找出受影響的版本、依風險決定如何修補、交付安全更新、告知使用者必要的資訊，並記錄每項決定。

本指南說明如何建立這套流程，並與團隊現有的工單、工程及發行工具銜接。CRA 並未要求專用平台或獨立的資安部門。

製造商需要備妥的事項

CRA 的漏洞處理包含八個部分。製造商必須：

1. 掌握產品所含的內容，包括製作軟體材料清單（SBOM）；
2. 依風險不遲延地處理並修補漏洞；
3. 定期測試並審查產品的安全性；
4. 在更新可供取得後，公布已修補漏洞的相關資訊；
5. 建立並落實協調式漏洞揭露政策；
6. 讓漏洞通報更加便利，包括提供聯絡地址；
7. 安全地散布更新，並於適用時以自動方式為之；
8. 不遲延且免費地散布安全更新，並隨附給使用者的建議。

附件 I 第二部分。

這些義務自產品投放市場時開始，並持續整個支援期間。義務涵蓋自 2027 年 12 月 11 日起投放市場的產品。在該日期之前投放市場的產品，僅在 2027 年 12 月 11 日當日或之後經實質修改時才受規範。

通報是另一項義務，適用時程也不同。自 2026 年 9 月 11 日起，製造商必須就適用範圍內的所有產品（包括較舊的產品）通報遭積極利用的漏洞及重大資安事件，且支援期間結束後，這項義務仍持續存在。我們的 CRA 通報要求指南 有詳細說明。本指南則說明兩項流程的交會之處。

讓通報容易接收並分派

漏洞通報的來源很多：內部測試、資安研究人員、客戶、供應商的安全公告，以及公開漏洞資料庫。接收機制必須涵蓋所有來源，並將每份通報送交能夠評估的人員。

使用者找得到的聯絡窗口。 CRA 要求提供通報漏洞的聯絡地址，以及使用者易於辨識的單一聯絡窗口。使用者必須能選擇偏好的聯繫方式，您也不得將其限於聊天機器人等自動化工具。請在產品隨附的資訊中載明聯絡窗口，並說明可在何處找到您的揭露政策。第 13 條第 17 項。

確實執行的政策。 協調式漏洞揭露政策告訴發現漏洞的人（通報者）如何通報，以及通報後會如何處理。CRA 要求您建立並落實這項政策，因此背後的流程必須如政策所述運作。ETSI 的協調式漏洞揭露指南建議，基本政策應涵蓋：

• 您希望對方如何聯繫，以及如何安全地溝通；
• 通報應包含哪些資訊，例如受影響的產品與版本、說明、重現步驟及影響；
• 通報者在通報後可以預期的處理過程；
• 哪些項目屬於或不屬於政策範圍。

此大綱是依據 ETSI TR 103 838 的實作範例。CRA 要求建立並落實協調式漏洞揭露政策，但並未規定政策內容或通報欄位。

在網站的 /.well-known/security.txt 放置 security.txt 檔案，是公布聯絡窗口與政策的常見方式。若您發布此檔案，RFC 9116 要求包含 Contact 欄位與 Expires 日期。CRA 並未要求此檔案；它是讓聯絡窗口容易被找到的一種方式。

分派與保密。 為每份通報編號、確認收件，並轉交負責該產品的團隊。決定案件從收到第一份通報到結案由誰負責。尚未修補之漏洞的細節應予保密，並在處理案件期間持續向通報者更新進度。

依實際出貨的產品進行分流

通報只能告訴您產品可能存在漏洞。分流要確認該漏洞是否影響您已投放市場的版本，以及在這些版本中的嚴重程度。請就下列各問題分別記錄答案：

• 涉及哪個產品、版本與組態？ 使用 SBOM 與發行紀錄，找出所有包含受影響組件或程式碼的版本，包括仍在支援期間內的舊版本。我們的 CRA SBOM 要求指南 說明如何將安全公告與各版本比對。
• 漏洞是否存在且可觸及？ 確認有漏洞的程式碼是否在建置版本中，以及在產品的使用方式下是否能被觸及。
• 實務上是否可利用？ 若攻擊者在實務運作條件下能有效利用某項漏洞，CRA 即視其為可利用漏洞。有些漏洞只能在實驗室中遭到利用。
• 影響為何？ 考量攻擊者能對產品及其連接的系統做什麼。
• 是否有證據顯示漏洞正遭利用？ 若有，通報義務即適用，詳見下文。

漏洞可能經由多種途徑成為已知：公開漏洞資料庫、協調式揭露、內部測試或顯著的媒體報導。歐盟執委會的指引期待製造商迅速調查，並確認漏洞是否真實存在且適用於其產品。掃描工具給出的高分或新的 CVE 項目，本身都無法回答這些問題。答案尚不確定時，請繼續調查，並記錄尚未釐清的事項。在得到答案之前，不要將該版本視為未受影響。

疑似遭積極利用時，立即內部呈報。 若您在任何時點知悉產品的漏洞遭積極利用，通報義務即自該時點起算。通報與調查及修補同時進行，內部的分流期限也不會使其暫停。請將呈報機制納入分流：任何人看到遭利用的證據，都應直接轉交負責通報的人員。通報指南 說明何時構成知悉，以及必須提交哪些內容。

請記錄每項結論的證據與理由。您必須記錄所知悉的漏洞及第三方提供的相關資訊，並於適用時更新風險評估。我們的 CRA 風險評估指南 說明評估本身的做法。

選擇並協調修補方式

CRA 要求您依漏洞所帶來的風險，不遲延地處理並修補漏洞。歐盟執委會的 FAQ 說明，這並不表示每項發現都需要修補程式。視風險而定，修補方式可以是立即提供修補程式、先提供暫時緩解措施再以更新補足、提供停用受影響功能的組態指引，或更新使用者文件。若分析顯示漏洞無法被利用，例如產品從未呼叫有漏洞的函式庫功能，則記錄該漏洞，並在後續版本中移除未使用的程式碼，可能就已足夠。FAQ 4.3.1。

無論選擇哪種方式，都應記錄其為何與風險相稱，以及有哪些證據顯示其有效。

產品投放市場之前。 依據您的風險評估，產品於市場上供應時不得含有已知可利用的漏洞。若漏洞在發行前不久才成為已知，歐盟執委會的指引期待您考量其嚴重性、可利用性與影響，決定產品是否仍能安全地投放市場。產品投放市場後，處理義務仍持續適用。

來自供應商與開源專案的組件。 處理義務涵蓋整個產品，包括您所整合的組件。當您在整合的組件中發現漏洞時，必須通報製造或維護該組件的公司或專案。依歐盟執委會的指引，這僅適用於您所整合的版本，且僅限組件本身的漏洞，因此您無須通報因整合方式所造成的問題。若您能確認維護者已知悉該漏洞（例如維護者已自行發布安全公告），或該組件已無維護者，也無須通報。若您開發了修補該漏洞的軟體或硬體修改，必須將相關程式碼或文件分享予維護者，並於適當時採用機器可讀格式。您無須確保維護者接受該修改。第 13 條第 6 項。

供應商提供修補，並不代表工作已經完成。您仍須確認該修補能解決您版本中的漏洞、將其交付給使用者，並更新文件。若供應商在您的產品仍在支援期間內時停止支援某組件，FAQ 期待您以其他方式修補該漏洞，例如更換組件或自行開發修補程式。

產品不符合要求時。 若您知悉或有理由相信產品或您的流程不符合基本網路安全要求，必須立即採取必要的矯正措施使其回復符合狀態，或視情況將產品下架或召回。FAQ 認為下架或召回應屬例外情形，例如硬體產品的漏洞帶來非常重大的風險，且無法充分修補。

驗證並散布更新

測試修補結果。 確認更新能在每個受影響的版本與組態中消除或緩解漏洞，並對變更可能影響的部分執行迴歸測試。CRA 也要求在整個支援期間進行有效且定期的測試與審查。歐盟執委會的指引說明，這是指檢視新資訊（例如新發現的漏洞）是否需要新增或變更測試，並不是要以固定間隔重複相同的測試。

盡可能分開提供安全更新。 在技術上可行時，新的安全更新應與功能性更新分開提供，讓使用者不必接受新功能也能維持安全。若修補本身會改變功能，例如有漏洞的剖析器必須以更嚴格的剖析器取代，FAQ 接受合併提供更新。

安全交付，並於適用時自動進行。 更新必須透過安全機制散布。於適用時，安全更新應預設於適當期間內自動安裝。使用者需要清楚且易於使用的退出方式、可用更新的通知，以及暫時延後更新的選項。FAQ 依據 CRA 的 Recitals 說明，主要用於整合至其他產品的產品，或使用者不會合理預期自動更新的情形，例如更新可能干擾運作的專業網路與工業環境，都不預期提供自動更新。FAQ 並指出，使用者未安裝更新時，製造商無須負責。

不遲延且免費地散布。 安全更新可供取得後，應不遲延且免費地散布，並隨附建議訊息，告知使用者需要採取的行動。唯一的例外是您與商業使用者就客製化產品另有約定。附件 I 第二部分第 (8) 款。

讓每項更新維持可取得。 在支援期間內提供的每項安全更新，於發布後至少應維持可取得 10 年，或維持至支援期間結束，以較長者為準。第 13 條第 9 項。

舊版軟體。 若您已將軟體產品後續經實質修改的版本投放市場，可僅在最新版本中修補漏洞。前提是舊版本的使用者能免費取得最新版本，且無須額外負擔調整硬體或軟體環境的成本。其他處理義務（例如揭露政策與通報聯絡窗口）仍涵蓋所有版本。第 13 條第 10 項。

協調揭露並告知使用者

處理漏洞涉及四種溝通。各有其對象、觸發條件與詳細程度，其中一項延後，並不會使其他項目延後：

• 與通報者或供應商：依揭露政策確認收到通報、提出問題、分享進度並協調修補。
• 與主管機關：知悉遭積極利用的漏洞或重大資安事件時，透過通報流程進行。
• 與受影響的使用者，並於適當時與所有使用者：知悉遭積極利用的漏洞或重大資安事件後，告知其該漏洞或事件，並於必要時告知其可採行的措施。於適當時，應以結構化且機器可讀的格式提供。您可能必須在尚無修補方式時就這麼做。歐盟執委會的指引允許您在公開細節可能有助於攻擊者時，將詳細資訊限於相關使用者。第 14 條第 8 項。
• 與公眾：安全更新可供取得後，公布已修補漏洞的相關資訊。

公開安全公告。 安全更新可供取得後，應分享並公開揭露已修補漏洞的相關資訊：漏洞的描述、可供使用者辨識受影響產品的資訊、影響與嚴重性，以及關於如何修補的清楚指引。於有正當理由的情形，若您認為公開所生的安全風險大於其效益，得延後公開，直到使用者已有機會套用修補程式為止。附件 I 第二部分第 (4) 款。

就公開安全公告而言，CRA 並未規定識別碼、評分或格式。您可以加上 CVE 編號、CVSS 分數或機器可讀的 CSAF 版本，協助使用者處理。ETSI 指出，單憑 CVE 項目並不是揭露漏洞的方式。安全公告也應省略會使漏洞更容易遭利用的細節，例如概念驗證程式碼（PoC）。

範例：閘道器 2.1 的供應商函式庫

「範例閘道器 2.1」是一款假設的建築閘道器，並搭配行動應用程式。假設其於 2027 年 12 月 11 日之後投放市場，且仍在支援期間內。目前的韌體為 2.1.0。較舊的裝置仍執行韌體 2.0.4，該版本同樣仍在支援期間內。

某開源 MQTT 用戶端函式庫的維護者發布安全公告：在 4.2.0 至 4.2.2 版中，來自訊息代理伺服器（broker）的格式錯誤訊息可能使函式庫當機，並可能讓攻擊者執行程式碼。4.2.3 版已修補此問題。目前沒有已知的遭利用情形。

團隊開立案件並逐步處理：

1. 受影響的版本。 韌體 2.1.0 的 SBOM 列出該函式庫為 4.2.1 版。韌體 2.0.4 的 SBOM 列出 4.1.8 版，不在受影響範圍內。應用程式未使用該函式庫。
2. 適用性。 有漏洞的剖析程式碼已編譯進韌體 2.1.0，並會處理來自雲端 broker 的每則訊息。能冒充或入侵 broker 的攻擊者可能觸及該程式碼。團隊將風險評為高。
3. 上游（維護者）。 維護者已自行發布安全公告，因此團隊能確認其已知悉該漏洞。無須向上游通報。
4. 修補。 團隊在韌體 2.1.1（僅含安全修補的版本）中將函式庫更新至 4.2.3，並對訊息功能執行迴歸測試。
5. 散布與安全公告。 韌體 2.1.1 透過閘道器經簽章的自動更新管道交付。更新可供取得後，團隊發布安全公告，說明漏洞、受影響的韌體版本、影響與嚴重性，以及更新方式。
6. 後續工作。 團隊更新風險評估與技術文件，發布新的 SBOM，並在下表尚待釐清的問題得到答案後結案。

這是依據 CRA 附件 I 第二部分及歐盟執委會指引與 FAQ 的實作範例。這些紀錄欄位、狀態與工作流程選擇並非 CRA 所強制要求，各列僅為樣本。處理漏洞、加以記錄及告知使用者的義務仍具拘束力。

供應商的修補並未讓案件結束。團隊仍須確認自身哪些版本受影響、測試修補、交付更新並發布安全公告，而客戶建置版本的問題也尚待釐清。

若團隊在過程中知悉該漏洞正遭利用，案件處理會繼續進行，通報流程也自該時點起同時展開。

保存紀錄並檢討流程

技術文件應包含的內容。 技術文件必須說明您的漏洞處理流程，包括 SBOM、協調式漏洞揭露政策、已提供通報聯絡地址的證明，以及為安全散布更新所選定的技術解決方案。案件紀錄、風險決定與測試結果可證明流程確實運作。我們的 CRA 技術文件指南 說明如何整理文件。附件 VII。

三個不同的期間。 請勿混淆：

• 支援期間：您在此期間處理漏洞；
• 每項安全更新的可取得期間：發布後至少 10 年，或至支援期間結束，以較長者為準；
• 技術文件的保存期間：產品投放市場後至少 10 年，或支援期間，以較長者為準。

檢討流程本身。 定期檢查通報是否送達正確的人員、案件是否停滯，以及相同的根本原因是否反覆出現。ETSI 建議將經驗回饋至開發工作，讓您同時解決根本原因與個別漏洞。

運用標準評估並改善流程

EN 40000-1-3。 這是依 CRA 正在制定、針對漏洞處理的協調標準。其已公布的範圍與第二部分的要求相對應：識別組件與 SBOM、修補與安全更新、測試與審查、揭露已修補的漏洞、揭露政策、資訊分享與聯絡地址，以及安全且及時地散布更新。2026 年 11 月 8 日，CEN 專案紀錄 顯示其正在核准中，並載明預期將刊登於《歐盟官方公報》。協調標準只有在其出處刊登於《歐盟官方公報》後，才產生符合性推定，且僅限於標準所涵蓋的要求。

您不必等到最終文本才開始。請將現有流程對照八項要求，並確認每一項都能產生證據：

此對照是依據 CRA 附件 I 第二部分及 prEN 40000-1-3 已公布範圍的實作範例。所列流程步驟、證據與缺口均為實作選擇，並非 CRA 所強制要求。此對照並未重現該標準的要求，相關要求須以正式發布的版本為準。

標準發布後，請將您的流程與其實際要求及評估準則比較，並確認其出處是否已刊登於《歐盟官方公報》、涵蓋哪些要求，再據以主張符合性。我們的 CRA 風險評估指南 說明 EN 40000 各部分如何搭配，符合性評估指南 則說明標準如何影響程序的選擇。

其他參考資料。 ISO/IEC 29147 涵蓋漏洞揭露，包括接收通報與發布資訊。ISO/IEC 30111 涵蓋調查與修補所通報漏洞的流程。許多組織已採用這些標準，它們也能支援 CRA 流程。採用這些標準本身並不會產生符合性推定。標準必須是出處已刊登於《歐盟官方公報》的協調標準，才會產生該推定，且僅限於其所涵蓋的要求。ETSI TR 103 838 是免費且實用的協調式漏洞揭露建置指南。其建議屬於良好實務，CRA 並未要求。

Meroi Security 如何協助

Meroi Security 可依 CRA 評估您目前的漏洞處理流程，界定接收、工程、發行與通報之間的明確交接，將 SBOM 與發行紀錄連結至每個案件，改善您的揭露政策與安全公告做法，並準備技術文件所需的流程文件。歡迎了解我們的 CRA 合規服務。