CVE 發布趨勢

2025 年共發布了 47,801 筆 CVE 紀錄，較前一年增加 20%。2026 年在還剩幾個月的情況下，已經達到 95,494 筆。

自 CVE 計畫啟動以來，數量每年都在成長，但成長速度在 2026 年急劇改變。您可以使用上方圖表，依月、季或年查看趨勢。

就在本頁。上方的圖表與數據，是每天從 CVE 計畫的 cvelistV5 儲存庫重新建立的 CVE 統計，與 CVE 計畫發布所用的來源相同。

內容涵蓋依 CVSS 嚴重程度、指派組織，以及依週、月、季或年區分的發布數量，並附上最近的重大紀錄。若要查看單一漏洞的詳細資訊，請點選任一識別碼前往 cve.org。

有三件事同時發生，而已發布的紀錄無法將它們區分開來。

現在有更多組織能指派 CVE ID，因此過去從未登錄的漏洞正在被記錄下來。自動化與 AI 輔助的漏洞發現，提高了每位研究人員能找到的數量。而 CISA 的補充計畫回填了較舊紀錄的細節，事後改變了歷史數據。

因此，CVE 數量上升本身並不能證明軟體越來越不安全。但它確實改變了人工流程所需的工作量：請參閱CVE 數量持續攀升時該自動化什麼。

CNA 是獲授權在其自身範圍內（通常是自家產品）指派 CVE ID 並發布紀錄的組織。此資料集中共出現 505 個 CNA。

廠商、開源專案、漏洞獎勵平台與各國 CERT 都可擔任 CNA。這裡最大的是 mitre，共有 39,628 筆紀錄。由於單一 CNA 改變流程就可能明顯影響總數，圖表可讓您一次篩選一個組織。

CVSS 以 0.0 到 10.0 為漏洞評分，並分為幾個區間：Low（0.1-3.9）、Medium（4.0-6.9）、High（7.0-8.9）與 Critical（9.0-10.0）。

分數描述的是漏洞本身的技術特性，例如如何觸及該漏洞，以及它會危及什麼。它並不衡量任何特定組織面臨多少風險。

2020 年以來發布的紀錄中，有 17.4% 在 CNA 自己的資料與 CISA 的補充資料中都沒有 CVSS 分數。

在 CVE 計畫的大部分歷史中，評分並非必要。自 2023 年起涵蓋率急遽提升，如今幾乎全面涵蓋，因此圖表上 Unknown 區塊縮小，反映的是通報作法的改變，而不是漏洞本身的變化。任何忽略未評分紀錄的分析，都會低估較早的年份。

漏洞是軟體中的缺陷。CVE 是指派給某個已揭露的特定漏洞實例的公開識別碼。

大多數漏洞從未取得 CVE：它們在內部被發現並修正，或不在任何 CNA 的範圍內。因此 CVE 數量衡量的是揭露活動，而不是實際存在的缺陷數量。

每個數據都依據 CVE 計畫官方的 cvelistV5 儲存庫建立，使用 2026年11月12日 UTC 擷取的快照。

紀錄依發布日期計算，而非依 CVE ID 中的年份，因為約有五分之一的紀錄是在與其識別碼年份不同的年份發布。已拒絕與已撤回的紀錄不列入計算。

單憑分數並不能這樣判斷。您出貨但從未呼叫之元件中的 Critical 漏洞，可能沒有您公開 API 上的 Medium 漏洞來得緊急。

真正的優先排序需要知道受影響的元件是否存在於您的軟體中、有漏洞的程式碼是否可觸及，以及該漏洞是否正遭到利用。CVSS 無法回答其中任何一項。

CRA 要求製造商在產品支援期間內處理漏洞，在得知遭積極利用的漏洞後 24 小時內向 ENISA 通報，並讓技術文件保持最新。

這些義務會隨著本圖表中的數量一同增加。每年要以人工方式將數萬筆新紀錄與您自己的軟體比對並分級研判並不實際，這也是為什麼 CRA 實際上預設了 SBOM 與自動化比對流程。

您需要一份準確記載軟體內容的資產清冊，再將這份清冊與 CVE 資料來源持續比對。

CRACI 從您的建置產生 SBOM，在新的 CVE 紀錄發布時進行比對，並只顯示會觸及您實際出貨程式碼的資安公告，同時提供 CRA 要求您保存的文件。

了解漏洞追蹤的實際運作方式、圍繞它該自動化什麼，以及如何減少剩餘內容中的雜訊。