漏洞優先排序：如何決定先修補哪些漏洞

為什麼只看嚴重程度行不通

預設做法是依 CVSS 排序，從 critical 往下處理。這看似客觀，卻有三個原因讓它失效：

• CVSS 衡量的是嚴重程度，而非風險。它描述的是漏洞一旦遭到利用會有多嚴重，但不會告訴您是否有人正在利用它，或它對您的產品是否重要。
• 清單中太多項目都很緊急。許多已公開的 CVE 評分為 high 或 critical，因此依 CVSS 排序的佇列會把數百個檢測結果排在最前面，卻無從在其中做選擇。
• 清單的品質取決於資產清冊。讀取 lockfile 的掃描工具會回報從未出貨的開發用相依套件，卻漏掉建置在套件管理工具之外下載的套件。這兩者在排序開始前就已扭曲了結果。

優先排序補上了缺少的問題：它是否正遭到利用、遭到利用的可能性多高，以及一旦遭到利用，對您會有什麼影響。但排序只能為眼前的清單排順序，因此請先減少雜訊：您未出貨元件的檢測結果、重複項目，以及沒有負責人的檢測結果。

各項訊號

訊號	它回答的問題	來源
CVSS	一旦遭到利用有多嚴重？評分為 0 到 10。	FIRST（標準制定者）；NVD 與廠商公布評分
EPSS	未來 30 天內遭到利用的可能性有多高？以 0 到 1 的機率表示。	FIRST，每日更新，免費
CISA KEV	它是否已在真實環境中遭到利用？	CISA 的 Known Exploited Vulnerabilities 目錄
SSVC	綜合遭利用情況、影響與您的任務，您應該怎麼做：追蹤（track）、關注（attend）還是行動（act）？	CERT/CC 與 CISA 的決策樹
您的脈絡	有漏洞的版本是否會出貨？是否對外暴露？產品有多重要？是否有修正版本？	您的資產清冊、架構與資產記錄

公開的訊號描述的是漏洞本身。只有您的脈絡能描述您的風險，而這正是多數團隊從最不可靠的來源取得的部分。

實用的優先排序方法

多數計畫最後都會採用某種形式的分級。請依您的政策與客戶要求設定時程。

1. 立即修補：已知遭到利用，且存在於您出貨的軟體中。任何列於 KEV 清單、或有其他遭利用證據，且存在於已發布建置中的漏洞。作為比較，CISA 的 BOD 26-04 對於公開暴露系統上的 KEV 項目，給美國聯邦機構的期限最短僅 3 天。
2. 接著修補：可能遭到利用且嚴重。EPSS 分數高，加上 CVSS 為 high 或 critical，且位於已出貨並對外暴露的元件中。請選擇一個能讓佇列長度是團隊實際消化得了的 EPSS 門檻。
3. 例行修補：其餘所有會出貨的項目。將它們併入定期的相依套件升級，而不是把每個檢測結果都當作資安事件處理。
4. 記錄：不受影響。有漏洞的套件存在，但有漏洞的程式碼並未被使用，或該元件不會出貨。將理由記錄為 VEX 聲明，讓同一個檢測結果不會再回來等待審查，也讓提出詢問的客戶能看到原因。

然後持續重新排序。原本位於第三級的漏洞，可能在被加入 KEV 或 EPSS 分數驟升後，一夜之間升到第一級。

您永遠沒機會排序的漏洞

每一種優先排序方法，都只能排序眼前的檢測結果。掃描工具從未看到的有漏洞套件不會產生任何檢測結果，因此永遠不會得到 CVSS 分數、EPSS 分數或 KEV 比對結果。它不是被排在後面，而是根本沒有被排序，卻照樣出貨。

這種情況比聽起來更常發生，因為多數掃描工具是從檔案推算您的軟體包含什麼：lockfile、manifest，或建置的產出。建置所取用、卻沒有列在任何 lockfile 中的內容，就是隱藏相依套件，而以檔案為基礎的工具會漏掉它：

• 安裝掛鉤。由 npm preinstall 與 postinstall 腳本下載的程式碼，也就是 Shai-Hulud 蠕蟲所利用的途徑。
• 建置腳本。例如在建置時下載程式碼的 Rust 建置腳本。
• 基礎映像檔。容器建置的基礎映像檔及其作業系統層。
• 快取。從 CI 快取還原、而非依 lockfile 安裝的套件。

事後掃描產出也無法填補這個缺口。完成的二進位檔，特別是 Rust 這類編譯後的程式碼，只會讓掃描工具去猜測裡面放了什麼。而且由於建置預設無法重現，日後重新建置同一個 commit，也無法保證得到相同的相依套件。

建置時 SBOM 則從另一端著手。CRACI 執行您的 GitHub Actions 作業，並看到進入每次建置的流量，因此能記錄作業實際取用的每個套件，包括隱藏相依套件。每份 SBOM 都帶有完整性狀態，說明何時有內容無法被看到。實務上，CRACI 曾找到 Snyk 與 Aikido 未回報的有漏洞套件，因為它們的掃描漏掉了這些元件。這些正是優先排序方法根本沒機會排序的檢測結果。

脈絡：掃描工具無法替您評分的部分

有漏洞的版本真的會出貨嗎？

這是最能減少雜訊的問題。lockfile 中的測試框架、鎖定在永遠不會發布之分支中的套件、會被捨棄的容器階段：這些都不會到達客戶手中。在建置過程中記錄的 SBOM，會根據版本發布建置實際使用的內容回答這個問題，而不是根據儲存庫宣告的內容。

哪些版本包含它？從何時開始？

在您出貨給客戶的產品中、且自去年春天以來每個版本都受影響的檢測結果，優先於內部工具中的同一個檢測結果。了解暴露期間，也能告訴您需要揭露什麼。

有漏洞的程式碼是否可被觸及？

可達性分析會追蹤您的程式碼是否能呼叫相依套件中有漏洞的函式。多款 SCA 工具提供這項功能，它能有效地將無法觸及的檢測結果往清單後方移。請把它當作其中一項輸入：它只能看到分析能追蹤的程式碼路徑，而可被觸及的函式不等於可被利用的函式。

它是否對外暴露？是否有修正版本？

面向網際網路的服務，排序高於私有網路上的批次作業。有修正版本的漏洞，處理成本低於需要緩解措施的漏洞。這兩者會改變順序，但不會改變它是否要被處理。

以風險為基礎的漏洞管理

以風險為基礎的漏洞管理，是同一個概念在計畫層級的名稱：依遭利用證據、可能性、嚴重程度與業務脈絡排序，衡量風險最高的檢測結果多快被處理完畢，並接受低風險的檢測結果可能維持未處理。衡量指標也隨之改變。與其追蹤未處理漏洞的總數，不如追蹤已出貨軟體中有多少已知遭利用的漏洞仍未處理，以及它們未處理的時間有多長。

漏洞優先排序工具

目前大部分的排序工作由三類工具負責：

• 基礎架構漏洞管理平台，例如 Tenable、Qualys 與 Rapid7，以建立在漏洞利用情資上的自有風險評等，為主機、端點與雲端資產評分。
• SCA 與應用程式資安工具，例如 Snyk、Endor Labs 與 Semgrep，為相依套件的檢測結果排序，其中多款具備可達性分析。
• 開源工具，例如會在檢測結果中附上 EPSS 與 KEV 資料的 Grype，以及持續分析 SBOM 的 Dependency-Track。

漏洞管理工具比較逐一介紹這些工具。

CRACI 如何支援優先排序

CRACI 從排序最常出錯的地方著手：資產清冊。它執行您的 GitHub Actions 作業，並記錄每個作業實際取用的套件，包括遞移相依套件、從快取還原的套件，以及沒有列在任何 lockfile 中的隱藏相依套件。

• 針對已出貨內容的檢測結果。受監控的 SBOM 會持續重新評估，組織檢視會彙整各建置與各儲存庫的檢測結果。每個套件都會顯示其資安公告、嚴重程度，以及帶入它的套件。
• 暴露期間。建置歷史會顯示哪些過去的建置包含有漏洞的相依套件（無論直接或遞移），讓您知道哪些版本受到影響、影響多久。
• 分級研判與分派。資安團隊研判檢測結果，並將每一項送交負責修正的團隊。CRACI 支援以 VEX 記錄某個漏洞不會影響您的產品。
• 關卡。政策關卡可依檢測結果封鎖建置，包括封鎖含有特定 CVE 的建置。

CRACI 未提供可達性分析。如果這是您最需要的訊號，請選擇提供該功能的 SCA 工具。完整功能請參閱漏洞追蹤。

漏洞優先排序：常見問題

什麼是漏洞優先排序？

漏洞優先排序是決定哪些已知漏洞要先修補、哪些可以等待，以及哪些根本不會影響您。它依漏洞遭到利用的可能性，以及在您的環境中可能造成多大的損害來排序檢測結果，而不是只看嚴重程度。

如何排定漏洞的優先順序？

從準確的資產清冊開始，讓您排序的是實際出貨軟體中的漏洞。將列於 CISA Known Exploited Vulnerabilities 清單的項目排在最前面，其餘則依遭利用可能性（EPSS）與嚴重程度（CVSS）排序，並依您的脈絡調整：暴露程度、產品的重要性，以及是否有修正版本。將不會影響您的漏洞記錄為 VEX 聲明。

只靠 CVSS 足以排定漏洞優先順序嗎？

不夠。CVSS 衡量的是漏洞有多嚴重，而不是它遭到利用的可能性，也不是它對您有多重要。只依 CVSS 排序，會把待辦清單中很大一部分標為 high 或 critical，而其中大多數漏洞從未遭到利用。

什麼是以風險為基礎的漏洞管理？

以風險為基礎的漏洞管理，是依漏洞對組織構成的風險來排序與修補，綜合遭利用證據、可能性、嚴重程度與業務脈絡，而不是依 CVSS 分數或時間長短逐一處理。

EPSS 與 KEV 有什麼不同？

EPSS 是一種預測：某個 CVE 在未來 30 天內遭到利用的估計機率。KEV 是一份記錄：CISA 收錄有證據顯示已在真實環境中遭到利用的漏洞目錄。KEV 項目是事實；EPSS 分數是可能性。請先看 KEV，再用 EPSS 排序其餘項目。

可達性分析能取代優先排序嗎？

不能，它只是多一項輸入。可達性分析檢查您的程式碼是否能呼叫相依套件中有漏洞的函式。它能排除無法被觸發的檢測結果，但無法說明遭到利用的可能性，而且只涵蓋分析能追蹤的程式碼。