團隊規模不大時，如何因應持續增加的 CVE 數量

改變了什麼：CVE 的數字

以下數據來自 CVE Program 本身的記錄，每天在我們的 CVE 公開趨勢頁面上重新建置。截至 2026年11月12日 UTC 的快照：

• 2025 年共公開了 47,801 筆記錄，比前一年增加 20%。
• 2026 年至今已公開 95,494 筆記錄，每天 303 筆，比 2025 年的每日速度高出 +131%。
• 其中 每天 155 筆被評為 High 或 Critical。
• 自 2020 年以來的所有記錄中，有 17% 沒有 CVSS 分數，無論是來自指派單位或 CISA 的補充分析。涵蓋率已有改善：2026 年的比例為 6%。
• 這些記錄由 505 個組織指派，其中前 20 大組織占了 75%。

• High 或 Critical
• 其他嚴重程度與未評分

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

各年度公開記錄的每日平均值；* 表示當年度至今。資料來源：CVE Program 的 cvelistV5 記錄，2026年11月12日 UTC 的快照。依月份、嚴重程度與指派單位篩選：CVE 公開趨勢。

這不是單一季度的異常。數量自 2020 年以來逐年上升，而且有幾項結構性的變化讓它持續增加：

• 更多指派單位，指派範圍也更廣。Linux 核心專案於 2024 年 2 月成為 CVE Numbering Authority（CNA）。其公開的政策是：只要某個錯誤修正一進入穩定版核心、且可能是漏洞，就為其指派 CVE，因為修正合併時往往無法確定是否可被利用。光是核心 CNA，此後就已公開了 18,221 筆記錄。
• AI 輔助的漏洞發現。2024 年 11 月，Google 的 Project Zero 與 DeepMind 發表，其 Big Sleep 代理程式在 SQLite 發布前就找到了一個可被利用的記憶體安全錯誤，他們認為這是 AI 代理程式在廣泛使用的軟體中做到這一點的首個公開案例。這類工具提高了單一研究人員能找到的漏洞數量。
• NVD 已無法補充分析所有內容。NIST 表示，National Vulnerability Database 自 2024 年初起累積了大量尚未補充分析的 CVE，而且隨著提交數量持續增加而無法消化。2026 年 4 月，它改採以風險為基礎的模式：列於 CISA Known Exploited Vulnerabilities 目錄中的 CVE，以及聯邦或關鍵軟體中的 CVE 會優先補充分析，其餘則列為不排入立即補充分析。仰賴單一資料庫受影響產品資料的流程，如今只能等待，或是漏掉。
• 應變時間更短。Mandiant 測得 2018 與 2019 年的平均利用時間為 63 天。其 M-Trends 2026 報告估計 2025 年為負七天：利用行為如今經常在修補程式發布之前就已開始。
• 法規時限。依據歐盟 Cyber Resilience Act（CRA），製造商必須在 24 小時內針對遭積極利用的漏洞提出早期預警、在 72 小時內提出通報，並在修正可用後 14 天內提出最終報告（CRA 的要求）。三人團隊與三百人團隊面對的時限完全相同。

這並不代表軟體變得更不安全，而是代表團隊需要檢視的項目數量年年增加，團隊本身卻沒有變大。

小型團隊的流程在哪裡失靈

數量增加之所以讓漏洞管理失靈，並不是因為要修正的漏洞變多，而是因為每個人工步驟都會隨著每個 CVE 重複一次。

人工步驟	為何在目前的數量下會失靈
以人工建立資產清冊	試算表，或在稽核前製作的 SBOM，在下一個版本發布後的隔天就已過時。
閱讀漏洞資訊來源	每天有 155 筆 High 或 Critical 記錄，沒有人跟得上。
詢問工程團隊「我們有用 X 嗎？」	每個 CVE 都要向同一群忙碌的人問同樣的問題。這個問題本身就是瓶頸。
每個儲存庫的每個 CVE 各開一張工單	一個共用函式庫的 CVE，會變成數十張重複的工單，淹沒待辦清單。
逐一回覆每位客戶	詢問量隨客戶數量增加，而不是隨漏洞數量增加。
以 PDF 或 wiki 呈現的文件	客戶的工具無法將 PDF 與其資產清冊比對，因此每位讀者都會再問一次。
不會延後的期限	利用時間不斷縮短，而人工流程卻隨著數量增加而變慢。

資產清冊。多數以人工維護元件清單的團隊，會在稽核或客戶問卷之前更新它。在這些時間點之間，它描述的是已不再出貨的軟體。於是每個 CVE 問題，都得從重建該版本包含了什麼開始。

漏洞資訊來源。閱讀資安公告是團隊最先做的步驟，也是最先崩潰的步驟。我們聽過仍以人工處理的團隊，其中一個團隊的漏洞掃描，指的就是由人員閱讀 CVE 論壇。這種做法一直有效，直到某天失效為止，而那一天不會有任何預兆。

詢問工程團隊。「我們有用這個函式庫嗎？是哪個版本？」每遇到一個可能適用的 CVE，就會打斷一位開發人員。一個兩人的產品資安團隊告訴我們，他們的工作就是不停按按鈕，只為了跟上進度，完全沒有時間改善流程。

工單。當共用函式庫出現 CVE，而每個儲存庫都各自開立工單時，待辦清單會把同一個決策重複計算許多次。團隊學會忽略待辦清單，然後就漏掉了真正重要的那張工單。

回覆客戶。在廣受報導的漏洞或供應鏈攻擊之後，客戶會問「我們有受到影響嗎？」。逐一回覆，會在時間最少的那一天耗費最多的時間。

文件。PDF 聲明或 wiki 頁面必須由客戶端的人員閱讀。客戶的掃描工具，以及越來越多的主管機關，期望 SBOM、VEX 與資安公告採用機器可以比對的格式。

期限。必須在 24 小時內提出的早期預警，或是比修補程式更早出現的漏洞利用程式，都不會等待佇列清空。

依序該自動化什麼

每個步驟都會減少下一個步驟的工作，因此順序比工具的選擇更重要。

1. 掌握您出貨的內容。 每次建置都產生 SBOM，讓「我們有受到影響嗎？」變成一次查詢。
2. 持續比對，而且不只比對一個來源。 新的 CVE 會與每一份已儲存的 SBOM 比對，因此沒有人需要閱讀漏洞資訊來源。
3. 降低雜訊。 與您未出貨內容相關的檢測結果，以及重複的項目，永遠不會送到人員手上。
4. 半自動分級研判。 事實資料會自動填入；由人員做出決策。
5. 讓一切都機器可讀。 每個決策只做一次，所有讀者都能重複使用。
6. 公開回覆一次。 從未發生的詢問，不會耗費任何成本。

1. 自動為每次建置產生 SBOM

取代的是：試算表，以及詢問工程團隊。在建置時產生的 SBOM，描述的是建置實際使用的內容；為每個已出貨版本保留一份，代表您不只能回答 main 分支的問題，也能回答去年發布版本的問題。客戶執行的是舊版本，您的資產清冊必須涵蓋它們。

最低限度的做法：在 CI 中為每次發布建置產生 SBOM，並與發布的建置產物一起儲存。更好的做法：直接從建置本身記錄 SBOM，而不是事後從鎖定檔（lockfile）推斷，讓套件管理工具之外取用的元件也包含在內（建置時 SBOM、SBOM 自動化）。

成本：最低限度的做法需要一到兩天的管線工作，之後每次發布都不再需要額外投入。成效指標：對任何一個發布版本，您都能不必詢問任何人就列出其元件。

2. 持續比對多個漏洞來源

取代的是：閱讀漏洞資訊來源。比對是機器的工作：每個新的 CVE 都要與每一份已儲存的 SBOM 比對，而不只是剛完成那次建置的 SBOM。一個出貨時乾淨的舊版本，在其某個元件公開 CVE 的那一天就受到影響。

單一來源並不足夠。NVD 補充分析的積壓，意味著受影響產品資料可能延遲送達，甚至根本不會送達。GitHub Advisory Database 與 OSV 等生態系資安公告往往更快，並以該生態系自己的用語說明哪些套件版本受到影響。ENISA 的 EU Vulnerability Database 則補充了歐盟的脈絡。

最低限度的做法：一個排程作業，每天將每一份已儲存的 SBOM 與彙整後的來源重新掃描，並回報新的比對結果。成效指標：您會在客戶告訴您之前，就得知某個發布版本受到影響。請參閱漏洞追蹤，了解這在 CRACI 中的樣貌。

3. 在任何人檢視之前降低雜訊

取代的是：以人工審查無關緊要的檢測結果。大部分的雜訊在上游就已產生：資產清冊列出了您未出貨的內容、多個工具回報同一個 CVE，以及沒有人需要的相依套件。修正資產清冊，依套件 URL（PURL）、版本與 CVE 讓每項檢測結果只計算一次，減少出貨的相依套件，然後再加入來自 CISA KEV、EPSS 與 VEX 的可利用性脈絡。如何降低漏洞雜訊會逐一說明這些手段。成效指標：每個已出貨版本的檢測結果數量下降，而且原因都有記錄。

4. 半自動分級研判

取代的是：由人員為每項檢測結果蒐集事實資料。請精確地分工：

• 自動：嚴重程度、是否已知遭到利用、哪些產品與版本包含該元件、負責的團隊、建議的優先順序與到期日。
• 人工：決策。修正、緩解、附到期日接受風險，或附上理由標示為不受影響。

不宜自動化的是：在沒有記錄理由的情況下，將檢測結果結案為不受影響。那是壓制警示，會在稽核或資安事件中再次浮現。排序規則請參閱 漏洞優先順序排定。

最低限度的做法：每天花 15 分鐘處理已排序並填妥資料的佇列。成效指標：每個決策都有記錄的理由，而且沒有任何項目在等待有人去查資料。

5. 讓一切都機器可讀

取代的是：必須由人員閱讀的 PDF、wiki 頁面與電子郵件。以 CycloneDX 或 SPDX 發布 SBOM（CycloneDX 與 SPDX 比較），以 VEX 發布不受影響的決策，並以 CSAF 發布資安公告。如此一來，客戶的掃描工具與主管機關不需要人工就能使用它們，每個決策只做一次，就能讓每位詢問者重複使用。

小型團隊的最低限度做法：從固定的位置依需求提供 SBOM 與 VEX；當客戶開始要求時再提供 CSAF。成效指標：客戶的工具不再標記您已經回答過的項目。

6. 公開回覆一次

取代的是：每位客戶一串電子郵件。為每個重大 CVE 發布資安公告或狀態頁面，列出受影響與已修正的版本，並準備一份連結至該頁面的回覆範本。如何回答「我們是否受到這個 CVE 影響？」的指南說明如何找出答案，而供應鏈攻擊後如何回覆客戶則提供回覆範本。成本最低的詢問，就是從未發生的詢問。成效指標：大多數詢問都能以一個連結回覆。

接著進行修正

自動化的相依套件更新 pull request 能讓例行工作持續推進；請依週或依發布版本批次處理，讓審查維持在可控範圍內。升級一個上游套件，往往能一次清除多個有漏洞的 遞移相依套件，而且比逐一修補更省成本（自動化漏洞修補）。接著，以會阻擋建置的政策關卡，防止新的已知有問題元件再次進入。

依團隊規模擬定的計畫

時數為供規劃參考的示意估算，並非基準數據。

	一人兼職	2 至 5 人的資安或 PSIRT 職能	規模較大的團隊
優先自動化	步驟 1 與 2：每次建置產生 SBOM 並持續比對	步驟 1 至 3，接著是步驟 4 中分派給負責人的部分	全部六個步驟，並在每條管線中設置政策關卡
維持人工	每項 High 或 Critical 檢測結果的決策；以範本回覆客戶	決策、VEX 理由說明、重大 CVE 的資安公告	決策、例外處理與流程本身
每週時間（示意）	2 至 4 小時	每人 4 至 8 小時	取決於決策數量，而非漏洞資訊來源

如果您已經設有 PSIRT，同樣的順序也適用；完整的流程模型請參閱 漏洞管理生命週期，而 擴展 PSIRT 則說明如何處理隨每個 CVE 倍增的客戶詢問。

如何判斷成效

• 依產品計算，從 CVE 公開到判定「受影響」或「不受影響」的時間。
• 以已公開資料回覆的客戶詢問比例。
• 每個已出貨版本的檢測結果數量，而不是每次掃描的數量。
• 附有記錄理由的決策比例。
• 每週投入漏洞工作的時數，以及它是否在下降。

請先測量您自己的基準值。這些指標並沒有可靠的業界基準，我們也不引用任何基準。

招募人力、採購工具，還是改變流程？

• 招募人力：當工作內容是修正您自己程式碼中的漏洞，或是需要判斷力、面對客戶的資安工作時。
• 採購工具：針對每個 CVE 都會重複的步驟，也就是步驟 1、2、3 與 5。
• 改變流程：針對責任歸屬與期限，也就是由誰決定、在何時之前決定。

請誠實面對最後一項。沒有負責人的工具，只會產生一個沒人看的儀表板。

CRACI 的定位

針對在 GitHub Actions 中建置的軟體，CRACI 能自動化步驟 1 與 2，以及步驟 3 與 4 的部分內容。它取代您的 GitHub 託管執行器，並在每個作業執行時記錄該作業實際取用的套件，包括從 CI 快取還原的套件，以及任何鎖定檔都未列出的隱藏相依套件。

• 每次建置都有 SBOM。每個作業的 SBOM 都以 PURL 識別每個元件，並附有完整性狀態，讓您知道哪些內容無法被看到。建置歷史會保留每一次過去的建置及其 SBOM，因此您可以看出哪些建置包含有漏洞的相依套件，無論是直接或遞移相依。
• 持續比對。受監控的 SBOM 會持續重新評估，檢測結果也會跨建置與儲存庫彙整，因此共用函式庫的 CVE 會呈現為一個問題，而不是四十個。
• 通知與關卡。CRACI 會將漏洞及其嚴重程度通知相關人員，政策關卡也能即時停止建置，包括包含特定 CVE 的建置。
• 分級研判與分派。資安團隊在 CRACI 中對檢測結果進行分級研判，並將每一項分派給負責修正的團隊。
• 機器可讀的 SBOM。SBOM 可匯出為 CycloneDX 或 SPDX，CRACI 也支援 VEX。

CRACI 不發布資安公告，不提供可達性分析，也不掃描您自己的程式碼。它只依建置分鐘數收費：每 vCPU 分鐘 $0.002（預設 2 vCPU 執行器為 $0.004），按秒計量，沒有月費、不按 SBOM 收費，目前也沒有授權費。請參閱價格方案。

今天就自動化前兩個步驟：在 CRACI 上執行您的建置。在正式上市之前，我們會親自協助每個團隊完成導入。

CRACI 不適合的情況

• 您的軟體不是在 GitHub Actions 中建置。GitLab CI 與 Jenkins 已列入產品藍圖。
• 您的風險主要來自基礎設施：伺服器、端點與雲端組態。基礎設施漏洞管理工具會更適合。
• 您整合的是並非由您建置的第三方韌體。二進位檔分析工具會更適合。
• 您的待辦清單大多是您自己程式碼中真實、可被利用的檢測結果。那是修補能量的問題，而不是自動化的問題。

漏洞管理自動化：常見問題

為什麼現在的 CVE 多了這麼多？

指派 CVE 的組織變多了，有些組織的指派範圍也很廣：Linux 核心在 2024 年成為 CVE Numbering Authority，會為任何可能是漏洞的錯誤修正指派 CVE。AI 輔助工具也讓每位研究人員找到更多錯誤。2025 年共公開了 47,801 筆記錄，2026 年則以每天 303 筆的速度增加。這個趨勢已經持續多年。

小型團隊如何跟上新的 CVE？

不要去閱讀它們。為每次建置產生 SBOM，自動將新的 CVE 與每一份已儲存的 SBOM 比對，降低雜訊，再讓人員只針對剩下的項目做決策。小型團隊跟上進度的方法，是移除每個 CVE 都會重複的步驟，而不是工作得更快。

漏洞管理中應該先自動化什麼？

資產清冊：在 CI 中為每次發布建置產生 SBOM，並與發布版本一起儲存。之後的每個步驟都仰賴它，而它能讓「我們有受到影響嗎？」從詢問工程團隊的問題，變成一次查詢。其次才是將這些 SBOM 持續進行比對。

處理漏洞需要資安團隊嗎？

一開始不需要。只要資產清冊、比對與雜訊降低都已自動化，一位兼職負責此流程的人員就能運作它。比起一個團隊，您更需要的是明確的負責人與期限。當工作變成修正您自己的程式碼，或是面對客戶的資安工作時，再招募人力。

如何知道哪些新的 CVE 會影響我們的產品？

為每個已出貨版本保留 SBOM，並在新的 CVE 公開時，以不只一個漏洞來源重新檢查所有 SBOM。當某個 CVE 符合您實際出貨的元件與版本時，您就受到影響。接著再由可利用性脈絡與 VEX 說明它是否重要。

對 SBOM、VEX 與資安公告而言，「機器可讀」是什麼意思？為什麼重要？

意思是採用工具可以解析的標準結構化格式：SBOM 使用 CycloneDX 或 SPDX，不受影響聲明使用 VEX，資安公告使用 CSAF。客戶的掃描工具不需要任何人閱讀，就能將它們與其資產清冊比對，因此您只做一次的決策，能讓每位客戶與每個工具重複使用。

分級研判中有多少可以安全地自動化？

蒐集事實資料的部分：嚴重程度、是否遭到利用、哪些產品與版本包含該元件、負責人、建議的優先順序與到期日。決策本身應由人員負責。絕對不要在沒有記錄理由的情況下，自動將檢測結果結案為不受影響。

面對 critical 等級的 CVE，我們有多少時間應變？

比大多數流程所假設的更少。Mandiant 的 M-Trends 2026 估計 2025 年的平均利用時間為負七天，也就是在修補程式出現之前就已遭到利用。依據歐盟 Cyber Resilience Act，遭積極利用的漏洞必須在 24 小時內提出早期預警。請依嚴重程度與利用狀況設定您自己的期限，並以此衡量成效。