本網站使用cookies以改善您的使用體驗，並提供更優質的客製化內容。若您未改變cookies設定並繼續瀏覽我們的網站(點擊隱私權政策以獲得更多資訊)，或點擊繼續瀏覽按鈕，代表您同意我們的隱私權政策及cookies的使用。
CRA合規
14.Sep.2026 / 活動期間：[2026.09.14 ~
]
弱點管理全流程實務指引
CRA 合規系列文章 第七篇（執行版）
弱點管理全程實務指引
整合 CRA、EN 40000-1-3、IEC 62443-4-1、ISO 30111/29147 的操作手冊
導讀：本篇定位
本篇是系列文章的收束篇，承接第四篇（SRP 通報）、第五篇（SBOM 建置）、第六篇（弱點管理政策），將前三篇建立的能力模組串聯為一個可持續運作的弱點管理全流程。
本篇針對執行團隊，提供七個階段的詳細操作規範、多標準交叉對照、RACI 矩陣、SLA 建議、以及工具鏈整合方案。
適用對象：PSIRT 成員、產品安全工程師、合規主管、研發主管、品保經理。
一、多標準交叉對照矩陣
以下矩陣展示弱點管理七個階段如何對應四個核心標準/法規的具體條款，便於執行團隊在建置流程時同時滿足多標準要求：
| # | 階段 | CRA Annex I Part II | EN 40000-1-3 | IEC 62443-4-1 | ISO 30111 / 29147 |
|---|---|---|---|---|---|
| 1 | 接收 | 義務 5：CVD 政策 | CVD 流程：回報管道、安全港 | Practice 7: Security Response（SR-1） | ISO 29147 §6: 接收弱點報告 |
| 2 | 驗證 | 義務 1：識別弱點含元件 | 資產盤點：SBOM/HBOM 比對 | Practice 6: DM-1 弱點接收分析 | ISO 30111 §7.1: 驗證 |
| 3 | 分級 | 義務 8：通報判定 | 事件應變：事件分類閾值 | Practice 6: DM-2 嚴重性評估 | ISO 30111 §7.2: 分級與優先排序 |
| 4 | 修補 | 義務 2：及時修補 | 修補管理流程 | Practice 6: DM-3 修補開發 | ISO 30111 §7.3: 修補 |
| 5 | 發布 | 義務 4：公開揭露 + 義務 6：分發機制 | 揭露協調 + 更新完整性驗證 | Practice 6: DM-4 公告 | ISO 29147 §7: 公開揭露 |
| 6 | 通報 | Art.14/16：24h/72h/14d | 事件應變：通報觸發流程 | —（非 IEC 62443 範圍） | —（非 ISO 30111 範圍） |
| 7 | 回饋 | 義務 3：定期測試審查 | 持續測試與監控 | Practice 6: DM-5 檢討改善 | ISO 30111 §7.4: 結案與回饋 |
二、七個階段的詳細操作規範
階段一：接收（Intake）
| 項目 | 操作規範 |
|---|---|
| 輸入來源 | (1) 外部 CVD 回報（研究人員、使用者、CERT）；(2) 內部安全測試發現；(3) SBOM 自動化弱點比對告警；(4) 供應商弱點通知；(5) 公開弱點資料庫（NVD/CVE）監控 |
| 處理流程 | (1) 在弱點追蹤系統中建立案件（建議使用 Jira、GitLab Issue 或專用工具如 DefectDojo）；(2) 記錄來源、初步描述、受影響產品/版本（若已知）；(3) 如為外部回報，48-72 小時內發送確認回覆；(4) 指派初步處理負責人 |
| 產出 | 弱點初始紀錄（Vulnerability Intake Record），含唯一追蹤編號 |
| SLA 建議 | 外部回報確認回覆：≤ 72 小時；案件建立：≤ 24 小時（工作日內） |
階段二：驗證（Verification）
| 項目 | 操作規範 |
|---|---|
| 核心活動 | (1) 重現弱點（在隔離測試環境中）；(2) 透過 SBOM 比對確認受影響的元件與版本範圍；(3) 分析根本原因（Root Cause Analysis）；(4) 判定弱點真實性：確認為真弱點、誤報（False Positive）、或不適用（Not Applicable） |
| SBOM 整合要點 | (1) 使用 SBOM 工具（Dependency-Track、Snyk 等）自動比對 CVE；(2) 確認弱點是否存在於直接依賴或間接依賴（transitive dependency）；(3) 評估弱點在產品實際使用情境下的可利用性（VEX 分析） |
| 產出 | 弱點驗證報告：含重現結果、受影響範圍、根因分析、VEX 判定 |
| SLA 建議 | 初步驗證完成：接收後 ≤ 5 個工作日；Critical 等級疑似弱點：≤ 2 個工作日 |
階段三：分級（Triage & Classification）
| 項目 | 操作規範 |
|---|---|
| 嚴重性評估 | (1) 使用 CVSS v3.1 或 v4.0 計算基礎分數；(2) 以環境分數（Environmental Score）反映產品實際使用情境；(3) 分級：Critical (9.0-10.0)、High (7.0-8.9)、Medium (4.0-6.9)、Low (0.1-3.9) |
| 通報判定 | (1) 判定弱點是否「被積極利用」（actively exploited）；(2) 如是，啟動 CRA Art.14/16 通報計時（24 小時）；(3) 如否，記錄判定理由並繼續正常修補流程；(4) 判定標準應事先定義並文件化 |
| 修補優先順序 | (1) Critical：立即啟動修補，目標 72 小時內提供緩解措施；(2) High：7 個工作日內完成修補規劃；(3) Medium：30 個工作日內安排修補；(4) Low：下一個定期更新週期處理 |
| 產出 | 風險評估報告（含 CVSS 分數、通報決定、修補優先順序） |
階段四：修補（Remediation）
| 項目 | 操作規範 |
|---|---|
| 修補策略選擇 | (1) 版本升級：更新受影響的元件至已修補版本（優先選項）；(2) Patch 開發：自行開發修補程式（當元件維護者尚未提供修補時）；(3) 替代方案：更換受影響元件為等效替代品；(4) 緩解措施：當正式修補開發中時，提供臨時的配置變更或 workaround |
| IEC 62443-4-1 整合 | (1) 依照 Practice 5（安全驗證與確認測試）執行修補後的回歸測試；(2) 確認修補未引入新弱點或功能回歸；(3) 測試覆蓋安全功能測試、模糊測試、已知弱點掃描 |
| 更新包準備 | (1) 安全更新與功能更新分離打包；(2) 更新包加上數位簽章（確保完整性）；(3) 更新 SBOM 以反映元件變更；(4) 準備安全公告草稿 |
| 產出 | 經測試驗證的安全更新包（含數位簽章）+ 更新後的 SBOM + 安全公告草稿 |
| SLA 建議 | Critical：30 天內正式修補（72h 內提供緩解）；High：60 天；Medium：90 天；Low：下一個定期更新 |
階段五：發布（Release & Disclosure）
| 項目 | 操作規範 |
|---|---|
| 安全更新分發 | (1) 透過安全通道發布更新（HTTPS、簽章驗證）；(2) 可自動更新的產品：建議預設啟用自動安全更新；(3) 需手動更新的產品：提供清楚的安裝指引；(4) 支援回滾機制，防止更新失敗導致產品不可用 |
| 安全公告發布 | (1) 公告內容：弱點描述、CVE 編號（如適用）、影響範圍、修補方式、緩解建議；(2) 公告模板建議依照 CSAF（Common Security Advisory Framework）格式；(3) 發布管道：產品安全公告網頁、Email 通知訂閱使用者；(4) 如有與外部回報者協議靜默期，確認靜默期結束後再公開 |
| ISO 29147 對齊 | (1) 揭露政策應公開於產品官網；(2) 揭露時機：修補完成後合理時間內公開；(3) 如弱點影響第三方元件，通知該元件的維護者；(4) 與回報者協調聯合公告 |
| 產出 | 已發布的安全更新 + 安全公告 + 使用者通知紀錄 |
階段六：通報（Regulatory Reporting）
| 項目 | 操作規範 |
|---|---|
| 觸發條件 | (1) 弱點被積極利用（actively exploited vulnerability）；(2) 重大安全事件影響產品安全性；(3) 適用於 CRA 範圍內的所有產品，2026/09/11 起生效 |
| 三階段通報 | (1) 24 小時：早期預警（Early Warning）— 弱點概述、是否被利用、初步影響評估；(2) 72 小時：弱點通知（Vulnerability Notification）— 詳細技術資訊、受影響產品清單、初步修補計畫；(3) 14 天（修補完成後）：最終報告（Final Report）— 完整分析、修補措施、影響範圍、改善建議 |
| 通報平台 | ENISA Single Reporting Platform (SRP)。需事先完成帳號註冊與授權設定。詳見第四篇文章。 |
| 產出 | ENISA SRP 通報紀錄（三階段文件）+ 內部事件紀錄 |
階段七：回饋（Feedback & Improvement）
| 項目 | 操作規範 |
|---|---|
| SBOM 更新 | (1) 將安全更新反映到 SBOM；(2) 確認受影響元件已更新至修補版本；(3) 更新 VEX 紀錄 |
| 流程檢討 | (1) 案件結案後進行回顧（post-mortem / retrospective）；(2) 評估各階段 SLA 達成情況；(3) 識別流程瓶頸與改善機會；(4) 記錄經驗教訓（lessons learned） |
| 安全開發回饋 | IEC 62443-4-1 整合：(1) 將弱點根因分析結果回饋至安全開發流程；(2) 更新安全需求或設計規範以防止同類弱點再現；(3) 累積弱點知識庫，優化未來的威脅建模 |
| 產出 | 更新後的 SBOM + 案件結案報告 + 流程改善紀錄 + 知識庫更新 |
三、RACI 職責矩陣
以下 RACI 矩陣定義各階段的角色分工。R = 負責執行（Responsible），A = 最終負責（Accountable），C = 諮詢（Consulted），I = 通知（Informed）。
| 階段 | PSO | PSIRT | 研發 | 品保 | 法務 | 客服 |
|---|---|---|---|---|---|---|
| 接收 | A | R | I | I | C | I |
| 驗證 | A | R | C | C | — | — |
| 分級 | A/R | R | C | C | C | — |
| 修補 | A | C | R | R | — | — |
| 發布 | A | R | C | I | C | R |
| 通報 | A/R | R | C | — | C | I |
| 回饋 | A | R | R | R | I | I |
PSO = Product Security Officer。在中小企業中，PSO 可由研發主管或品保主管兼任，但建議正式指定並記錄於弱點管理政策文件中。
四、工具鏈整合建議
弱點管理全流程涉及多種工具。以下依階段整理建議的工具選項：
| 階段 | 工具類別 | 開源選項 | 商用選項 |
|---|---|---|---|
| 接收 | 弱點追蹤系統 | DefectDojo、GitLab Issue | Jira + Security Plugin、ServiceNow |
| 驗證 | SBOM 弱點比對 | Dependency-Track、Trivy | Snyk、Black Duck、Mend.io |
| 驗證 | SCA / SAST / DAST | Semgrep、OWASP ZAP | Checkmarx、Veracode、Fortify |
| 分級 | CVSS 計算 | FIRST CVSS Calculator | 整合於 SCA/弱點管理平台 |
| 修補 | CI/CD 安全整合 | GitHub Actions、GitLab CI | Jenkins + Security Plugins |
| 發布 | 安全公告管理 | CSAF Tools、OpenVEX | SecurityBridge、自建公告平台 |
| 通報 | 通報平台 | ENISA SRP（官方平台） | — |
| 全流程 | SBOM 管理 | Dependency-Track、GUAC | SPDX-based、CycloneDX-based 平台 |
工具選擇原則：優先選擇能與現有 CI/CD 和開發流程整合的工具，避免另建獨立系統。中小企業可從開源工具起步，隨成熟度提升再評估商用方案。工具的詳細選擇方法請參閱第五篇文章。
五、SLA 建議總表
以下彙整弱點管理全流程中各項活動的建議 SLA（Service Level Agreement），供團隊在制定弱點管理政策時參考：
| 活動 | Critical | High | Medium | Low |
|---|---|---|---|---|
| 外部回報確認回覆 | ≤ 24h | ≤ 48h | ≤ 72h | ≤ 72h |
| 弱點驗證完成 | ≤ 2 工作日 | ≤ 5 工作日 | ≤ 10 工作日 | ≤ 15 工作日 |
| 緩解措施提供 | ≤ 72h | ≤ 7 工作日 | 如需要 | — |
| 正式修補發布 | ≤ 30 天 | ≤ 60 天 | ≤ 90 天 | 下一定期更新 |
| 安全公告發布 | 修補後 ≤ 24h | 修補後 ≤ 72h | 修補後 ≤ 7 天 | 修補後 ≤ 14 天 |
| 案件結案回顧 | ≤ 14 天 | ≤ 30 天 | 季度彙整 | 季度彙整 |
以上 SLA 為建議值，各組織應依據產品特性、客戶合約要求、及資源狀況進行調整。重點是明確定義並持續追蹤達成率，而非追求最嚴格的數字。
六、弱點管理成熟度模型
以下成熟度模型可協助團隊評估當前狀態並設定改善目標：
| 等級 | 名稱 | 特徵描述 |
|---|---|---|
| Level 1 | 被動回應 | 無正式流程。弱點處理依靠個人經驗，無追蹤機制，無對外回報管道。修補時程不確定。 |
| Level 2 | 基礎建置 | 已建立 CVD 政策與弱點回報管道。有基礎的弱點追蹤（如 Excel 或 Issue Tracker）。SBOM 為靜態文件。修補有排程但 SLA 未定義。 |
| Level 3 | 流程定義 | 七階段流程完整定義並文件化。RACI 明確。SBOM 動態更新。CVSS 分級機制就位。SLA 已定義。PSIRT 團隊運作中。CRA 合規推定可達成。 |
| Level 4 | 量化管理 | SLA 達成率定期量測並回報。弱點處理指標（MTTR、弱點發現率、修補覆蓋率）持續追蹤。流程瓶頸有數據支撐的改善。 |
| Level 5 | 持續優化 | 弱點處理回饋機制完善，根因分析持續改善安全開發流程。主動性弱點研究。弱點預防能力（Proactive Security）。多市場合規持續更新。 |
CRA 合規的最低要求約為 Level 3。建議在第一年以達到 Level 3 為目標，後續再依組織需求向 Level 4-5 演進。
七、DEKRA Onward Security 的端到端服務對照
DEKRA Onward Security 的弱點管理服務可依組織的成熟度等級與導入路徑，彈性組合：
| 服務 | 內容 | 適用成熟度 |
|---|---|---|
| 合規差距分析 | 現狀評估 → 差距識別 → 改善路線圖 → 優先順序建議 | Level 1-2 → Level 3 |
| PSIRT 建置顧問 | 團隊設計 + CVD 政策 + 通報流程 + 角色定義 + 演練 | Level 1-2 → Level 3 |
| 弱點管理流程設計 | 七階段全流程客製化 + RACI + SLA + 文件模板 | Level 2-3 |
| SBOM 建置與監控 | SBOM 產出 + 工具導入 + 動態弱點比對 + VEX 分析 | Level 1-3 |
| 安全測試服務 | SCA + SAST + DAST + 滲透測試 + 持續監控 | Level 2-4 |
| 流程優化顧問 | 指標設計 + 瓶頸分析 + 流程改善 + 多標準整合優化 | Level 3-4 → Level 5 |
| CRA 符合性評估 | 弱點管理政策驗證 + 技術測試 + 合規證書 | Level 3+（合規驗證） |
下一步行動
-
DEKRA Onward Security 提供免費的弱點管理成熟度初步評估，協助您確認組織目前的等級，並規劃從現狀到 CRA 合規的最短路徑。
聯繫方式：DEKRA Onward Security — CRA 合規服務團隊
Email: [email protected]
Email: [email protected]
CRA 合規系列文章導覽
第四篇：CRA 第一階段通報合規準備（SRP 通報義務）
第五篇：SBOM 建置與工具選擇（軟體物料清單）
第六篇：弱點管理政策與合規框架（CRA Annex I Part II + EN 40000-1-3 ）
第七篇(本篇)：弱點管理全流程實務指引（整合 CRA + EN 40000-1-3 + IEC 62443 + ISO 30111）
───────────────────────────────────────────
CRA 合規系列文章導覽
問題意識篇（為什麼要關注）
第一篇：從波蘭能源攻擊事件看台灣製造商的產品安全缺口與 CRA 合規策略
第二篇：從波蘭能源攻擊事件看 OT 資產擁有者的六項優先行動
第三篇：CRA 來了，你的產品規格準備好了嗎？——PM/RD 的安全規格變更清單
合規操作篇（怎麼做）
第四篇：CRA 第一階段通報合規準備（高層版 + 執行版）
第五篇：SBOM 建置與工具選擇（高層版 + 執行版）
第六篇：弱點管理政策與合規框架（高層版+ 執行版）
第七篇：弱點管理全流程實務指引（高層版 + 執行版）
Email: [email protected]
網站: www.onwardsecurity.com