漏洞
CVE 修補：從資安公告到修正版建置出貨
新的 CVE 出現了。您的哪些產品含有這個有漏洞的套件？哪些版本已經出貨？修正何時會推出？CVE 修補就是回答這些問題的流程，而且 pull request 合併並不代表完成。修正版建置出貨，才算完成。
更新日期
CVE 修補流程
CVE 修補是從您執行或出貨的軟體中移除已公開揭露的漏洞。對您自己的程式碼而言，這代表套用修補程式。對開源相依套件而言（一般產品中大多數的 CVE 都來自這裡），則代表升級到已修正該漏洞的版本。無論哪一種，步驟都相同：
- 找出含有受影響套件與版本的每個產品、建置與版本。
- 評估該漏洞是否影響您，以及影響有多嚴重。
- 排定優先順序，與其他所有待處理項目比較。
- 修正：升級、套用修補程式、替換，或在沒有修正時採取緩解措施。
- 驗證新建置實際包含的是已修正的版本。
- 記錄受影響的範圍、您的決定，以及修正出貨的時間。
步驟 1：找出每個受影響的建置
資安公告發布後的第一個問題，是這個套件在哪裡。從原始碼儲存庫回答這個問題既慢又常出錯：lockfile 中的版本、建置解析出的版本，以及已發布容器映像檔中的版本，可能各不相同。遞移相依套件，以及建置在套件管理工具之外下載的套件，根本不會出現在 manifest 中。
可靠的答案來自每個版本的 SBOM，並持續與資安公告比對。如果這份 SBOM 是在建置期間記錄的，它列出的就是建置實際使用的內容，因此比對結果會告訴您哪些已出貨的建置含有有漏洞的版本，而不是哪些儲存庫提到了它。
步驟 2：依嚴重程度與遭利用情況排定優先順序
只看嚴重程度，會把太多漏洞列為緊急。多數團隊會結合三種訊號：
| 訊號 | 它告訴您什麼 | 發布者 |
|---|---|---|
| CVSS | 漏洞遭利用時的嚴重程度，評分為 0 到 10 | FIRST（標準制定者）；NVD 與廠商發布評分 |
| EPSS | 未來 30 天內遭利用的估計機率 | FIRST |
| KEV | 該漏洞是否已知在真實環境中遭到利用 | CISA 的 Known Exploited Vulnerabilities 目錄 |
接著加入您自己的情境：受影響的套件是會出貨給客戶，還是只在測試作業中執行？有漏洞的函式是否真的被使用？已出貨套件中的已知遭利用漏洞，應排在清單最前面。漏洞優先順序排定將這些訊號整理成一套方法。
修補時程
- CISA BOD 26-04。自 2026 年 6 月 10 日起，美國聯邦機關依四個問題設定每項期限：資產是否公開暴露、漏洞是否列於 KEV 目錄、利用能否自動化，以及是否能取得部分或完全控制權。答案從 3 天（最嚴重的情況需進行鑑識研判）到在下一次系統升級時修正不等。它取代了 BOD 22-01，後者對多數 KEV 項目給予兩週期限。
- 歐盟 Cyber Resilience Act（CRA）。製造商必須毫不延遲地處理並修補漏洞，包括透過安全性更新（附件 I 第 II 部分）。自 2026 年 9 月 11 日起，產品中遭積極利用的漏洞也會啟動通報時限：24 小時內提出早期預警、72 小時內提出通報，並在修正可用後 14 天內提出最終報告。
- 您自己的政策。多數資安計畫會依嚴重程度設定內部目標。無論目標為何，只有步驟 1 夠快，您才能達成。
步驟 3：選擇修正方式
| 選項 | 使用時機 |
|---|---|
| 升級 | 已有修正版本。優先選擇包含修正的最小升級，以減少破壞性變更。 |
| 升級上層套件 | 有漏洞的套件是遞移相依套件。直接相依套件的新版本通常會帶入修正。 |
| 覆寫 |
上層套件尚未發布修正。以 npm overrides、Yarn
resolutions 或 pnpm.overrides 強制指定遞移相依套件的版本，並加以測試。
|
| 修補或向後移植 | 您暫時無法改用已修正的主要版本。將上游的修正套用到您使用的版本。 |
| 替換 | 該套件已無人維護，或持續出現 CVE。改用替代方案。 |
| 緩解並記錄 | 目前尚無修正，或您的產品不受影響。降低曝險，並記錄評估結果，例如以 VEX 聲明的形式。 |
這個步驟大部分都能自動化，從選擇版本到建立 pull request 皆然。自動化漏洞修補說明哪些該自動化、哪些該留給人處理。
步驟 4：已合併的修正不等於已出貨的修正
pull request 已經合併，所以 CVE 已經結案了嗎？不一定。修正已進入儲存庫，但建置可能還原了過期的快取、基礎映像檔仍帶有舊套件，或是版本分支從未納入這項變更。工單顯示已修正，產品卻仍在出貨有漏洞的版本。
從另一端完成閉環：檢查下一次建置的 SBOM，確認有漏洞的版本已經消失。當這份 SBOM 記錄的是建置實際擷取的內容（包括從快取還原的套件）時，這項檢查就能回答客戶、稽核人員與主管機關真正在問的問題。
CRACI 如何支援 CVE 修補
- 找出。CRACI 記錄每個 GitHub Actions 作業擷取的套件，包括遞移相依套件與從快取還原的套件，並持續重新評估受監控的 SBOM。組織檢視會跨建置與儲存庫彙整發現結果，讓您看到新的 CVE 影響哪些建置。
- 指派。資安團隊會對每項發現進行分級研判，並交給負責修正的團隊。CRACI 支援以 VEX 記錄漏洞對您產品的影響。
- 驗證。每次新建置都有自己的 SBOM 與完整性狀態，因此您可以確認建置使用的是已修正的版本。
- 通報。對於 CRA 下遭積極利用的漏洞，CRACI 會準備通報內容，再由製造商的人員透過 Single Reporting Platform 提交。
完整功能請參閱漏洞追蹤。
CVE 修補：常見問題
什麼是 CVE 修補？
CVE 修補是從您執行或出貨的軟體中，移除以 CVE ID 識別的已公開揭露漏洞。對相依套件而言，通常代表升級到已修正該漏洞的版本；對您自己的程式碼而言，則代表套用修補。
如何決定先修補哪些 CVE？
結合嚴重程度與遭利用的證據。CVSS 描述漏洞有多嚴重，EPSS 估計它在未來 30 天內遭利用的可能性，CISA 的 Known Exploited Vulnerabilities 目錄則列出已遭利用的漏洞。已出貨套件中的已知遭利用漏洞應排在最前面。
CVE 需要多快修補？
取決於由誰提出要求。CISA 的 Binding Operational Directive 26-04 給予美國聯邦機關從 3 天到下一次系統升級不等的期限，視漏洞是否列於 KEV 目錄、資產是否公開暴露、利用能否自動化，以及能給攻擊者多少控制權而定。歐盟 Cyber Resilience Act（CRA）要求製造商毫不延遲地修補漏洞，且自 2026 年 9 月 11 日起，產品中遭積極利用的漏洞會啟動 24 小時的通報時限。
如果還沒有修正版本怎麼辦？
緩解並記錄。如果可以，停用受影響的功能、阻斷攻擊路徑或替換元件，並記錄您的評估結果，例如以 VEX 聲明的形式。接著留意修正版本的發布，並在推出時進行修補。
如何修補遞移相依套件中的 CVE？
先嘗試升級引入它的直接相依套件，因為新版本通常會帶入修正。如果還沒有新版本，多數套件管理工具都能讓您強制指定遞移套件的版本：npm 用 overrides，Yarn 用 resolutions，pnpm 用 pnpm.overrides。請測試結果，因為上層套件並非針對該版本建置。