產品團隊的漏洞管理生命週期：階段、角色、時程與指標

什麼是漏洞管理生命週期？

漏洞管理生命週期是產品廠商處理其所交付軟體中漏洞時，可重複執行的流程：接獲或發現漏洞、驗證、釐清影響範圍、修正、發布修正並通知客戶。在廠商組織中，這通常由產品資安事件應變小組（PSIRT）負責執行，再由工程團隊進行修正。

本頁說明的是廠商端。IT 漏洞管理（掃描並修補組織所運作的伺服器與筆電）使用相同的術語，但沒有相同的難處。廠商必須為客戶手上每個仍受支援的版本負責，也必須公開其發現。

生命週期的各個階段

接獲或發現。漏洞可能來自外部研究人員透過您的漏洞揭露計畫通報、來自客戶、來自國家級 CSIRT 等協調機構，也可能來自您自己的監控：開源相依套件中的新 CVE、掃描工具的發現或內部測試。為每一項建立追蹤 ID，並回覆外部通報者已收到通報。
驗證與分級研判。重現問題或確認相依套件比對無誤，判斷它是否為您產品中的漏洞，並評定其嚴重性與急迫性。關閉不適用的項目，並附上日後可出示的理由。EPSS 與 CISA KEV 目錄等優先排序訊號，有助於為剩下的項目排序。
評估受影響的產品與版本。找出所有包含該有漏洞程式碼或元件的產品、版本與受支援分支，以及執行這些版本的每個客戶部署。這個步驟決定了修正與資安公告的範圍。
修補。負責的團隊開發並測試修正：升級相依套件、修改程式碼，或在尚無法修正時採取緩解措施，例如變更設定。
發布修正。透過客戶可信任的管道，為每個受影響的受支援分支交付更新版本。
發布公告與揭露。發布資安公告，說明受影響的範圍、嚴重程度與因應方式，指派或引用 CVE ID，並致謝通報者。CSAF 與 VEX 等機器可讀格式，讓客戶能自動處理資安公告。
監控與學習。留意遭利用的情況與新資訊，更新資安公告，並將根本原因回饋到開發流程，避免同類缺陷再次被交付。

ISO/IEC 30111 與 ISO/IEC 29147

有兩項國際標準為廠商描述了這個生命週期，並以組織的邊界將其劃分：

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
標題	漏洞處理流程（Vulnerability handling processes）	漏洞揭露（Vulnerability disclosure）
涵蓋範圍	組織內部的作業：驗證、調查、排定優先順序與修補	對外介面：接收通報與發布資安公告
主要內容	政策與組織、PSIRT 職責、處理階段、供應鏈考量	利害關係人角色、通報處理、資安公告內容、協調、揭露政策
對象	處理所接獲漏洞通報的廠商	接收通報並揭露漏洞的廠商

這兩項標準設計為搭配使用。ISO/IEC 30111 定義了六個處理階段：準備、接收、驗證、修補開發、發布與發布後。它也要求進行流程監控、確保漏洞資訊的機密性，並關注供應鏈，因為許多漏洞存在於非您撰寫的元件中。兩項標準皆為現行版本，已在 ISO 最近一次審查中確認，並已列為待修訂。

其他框架也採用相同的架構。FIRST PSIRT Services Framework 將工作分為漏洞發現、分級研判與分析、修補及揭露，而 IEC 62443-4-1 則在其工業產品安全開發生命週期中納入了安全更新與缺陷管理。

角色

PSIRT 或產品資安團隊：負責整個流程，接收通報、分級研判、協調修正並發布資安公告。請參閱適用於 PSIRT 團隊的 CRACI，以及 PSIRT 與 CSIRT 的差異。
產品與工程團隊：負責程式碼，開發並測試修正，並交付版本。
版本發布管理：決定哪些受支援分支要獲得修正，以及何時修正。
客戶支援與溝通：處理客戶的問題，並面向資安公告的讀者。
法務：就揭露、合約與法規通報提供建議。
外部各方：通報者、CERT/CC 或國家級 CSIRT 等協調機構、受影響元件的上游維護者，以及必須部署修正的客戶。

時程與 SLA

並沒有單一的強制時程。多數廠商依嚴重性設定內部目標，並在揭露政策中公布對外承諾的時程。常見的架構如下：

確認收到外部通報：數個工作天內。
分級研判：數天內完成，讓通報者與負責團隊了解目前進度。
修補：依嚴重性與遭利用情況設定時限，重大發現與任何已知遭利用的漏洞時限最短。
揭露：在修正可用時進行；若修正延誤，則於約定的期限揭露。

外部壓力決定了時限的上限。研究人員常會設定揭露期限（Google Project Zero 給廠商 90 天），而法規也加入了自己的要求：歐盟 Cyber Resilience Act（CRA）要求製造商「不得無故延遲」地修補漏洞，並為遭積極利用的漏洞設定通報期限（請參閱 CRA 的要求）。當漏洞已遭利用時，例如零時差漏洞，每個階段都必須以最短的時限進行。

生命週期在哪裡卡關

大多數的延誤並不在撰寫修正，而是來自不知道自己交付了什麼。

不知道哪些版本包含某個元件。某個函式庫出現了新的 CVE。去年的哪些版本包含它？哪些客戶在執行這些版本？如果沒有每個版本的紀錄，團隊只能重新建置舊標籤或手動搜尋儲存庫，而資安公告中的受影響版本清單只是猜測。
遞移相依套件。許多有漏洞的套件並不是您選擇的。它們以多層之下的遞移相依套件形式進入，因此搜尋您的資訊清單檔（manifest）會遺漏它們。
開發用相依套件的雜訊。讀取 lockfile 的掃描工具會回報永遠不會交付的測試框架與建置工具。每一項都耗費分級研判的時間，也淹沒了真正重要的發現。
套件管理工具以外的元件。由建置腳本下載的二進位檔、基礎映像檔與廠商元件，根本不會出現在 lockfile 中。
權責不清。沒有團隊負責的發現只能等待。只有當修正有了負責人，分級研判才算完成。
修正沒能維持。有漏洞的版本透過另一個相依套件或舊分支再次出現，因為沒有任何機制阻止它進入下一次建置。

小型團隊最先碰到這些卡關，因為每一項都會在每個 CVE 上重演。漏洞管理自動化依序說明該自動化哪些工作，而如何減少漏洞雜訊則處理那些淹沒重要發現的開發用相依套件、重複項目與無人負責的發現。

指標

指標	它顯示什麼
確認收到所需時間	通報者是否在您政策承諾的時間內獲得回覆
分級研判所需時間	一項發現要等多久，才有人知道它是否重要
各嚴重性的修補所需時間	從接獲通報到提供修正版本，修正交付的速度有多快
發布資安公告所需時間	修正後客戶要等多久才能取得資訊
達標比例	內部 SLA 是否守住，特別是重大與遭利用的發現
依存在時間分類的待辦項目	哪些發現卡住了，卡在哪裡
未受影響比例	有多少分級研判心力花在不適用的發現上

請分別衡量每個階段。修補所需時間過長，往往其實是找出受影響版本所需的時間過長。

以交付內容的紀錄來執行生命週期

分級研判之後的每個階段，都取決於您是否知道每個版本包含什麼。CRACI 在自己的執行器上執行您的 GitHub Actions 建置，並記錄每個作業實際取得的套件，包含遞移相依套件、從 CI 快取還原的套件，以及沒有列在任何 lockfile 中的相依套件。每份 SBOM 都附有完整性狀態，並可匯出為 CycloneDX 或 SPDX。

CRACI 會持續重新評估受監控的 SBOM，並跨建置與跨儲存庫加以彙整；您也可以加入廠商的 SBOM，讓外購元件與您自己的元件一起受到監控。當新的 CVE 出現時，建置歷史會顯示過去哪些建置包含有漏洞的相依套件（無論直接或遞移），讓您知道受影響的期間，而資產清冊檢視則顯示哪些產品部署了哪些軟體版本。資安團隊在 CRACI 中分級研判發現結果，並將其送交負責修正的團隊；CRACI 支援 VEX，政策關卡也能封鎖包含特定 CVE 的建置，讓已修正的漏洞不再回來。請參閱漏洞追蹤。

漏洞管理生命週期：常見問題

漏洞管理生命週期有哪些階段？

對產品廠商而言：接獲或發現漏洞、驗證並分級研判、找出受影響的產品與版本、開發修補、發布修正、發布資安公告，接著持續監控與學習。ISO/IEC 30111 將各階段定義為準備、接收、驗證、修補開發、發布與發布後。

什麼是 ISO/IEC 30111？

ISO/IEC 30111:2019 是漏洞處理流程的國際標準。它為廠商處理與修補其產品及服務中所接獲的漏洞通報，提供要求與建議，範圍從政策與 PSIRT 的角色，到各處理階段與供應鏈考量。

ISO/IEC 30111 與 ISO/IEC 29147 有什麼不同？

ISO/IEC 29147 涵蓋對外的部分：接收通報與發布資安公告。ISO/IEC 30111 涵蓋兩者之間的內部處理：驗證、調查、排定優先順序與修正。兩者設計為搭配使用。29147 的部分請參閱協同漏洞揭露。

什麼是漏洞分級研判？

分級研判是資安團隊確認所接獲或發現的漏洞確實存在、判斷它對您產品的嚴重性與急迫性，並將它送交負責修正之團隊的步驟。良好的分級研判也會關閉不適用的發現，並記錄理由。

產品漏洞管理與 IT 漏洞管理有什麼不同？

IT 漏洞管理是修補組織所運作的系統。產品漏洞管理則處理組織建置並交付給他人之軟體中的缺陷，因此多了 IT 團隊沒有的步驟：釐清哪些已發布版本受影響、將修正交付給客戶，並透過資安公告告知他們。

漏洞處理流程應追蹤哪些指標？

確認收到通報所需時間、分級研判所需時間、修補所需時間與發布資安公告所需時間（皆依嚴重性分類），再加上達成內部目標的發現比例、依存在時間分類的未結待辦項目，以及有多少發現因未受影響而關閉。

軟體廠商的漏洞管理生命週期