CVE件数増加：NVDバックログとCVSSバージョン推移

2026.04.02

日々のセキュリティ監視・運用業務に携わる中で、以前にも増して脆弱性情報の公開量が増加していることを肌で感じます。本記事では、年々増え続けるCVEの構造的な背景や、NVDのバックログ問題、さらにCVSSバージョンの過渡期における変化について、実際のデータをもとに整理・解説します。

ライター：遠藤　大輔: 2020年からセキュリティアナリストチームメンバーとして活動中

保有資格：CEH、CISSP、安全確保支援士など

CVE件数の増加

　CVE（Common Vulnerabilities and Exposures）とは、米国の非営利団体MITREが提供する、脆弱性を一意に識別するための仕組みです。公開された脆弱性に「CVE-YYYY-NNNN」という形式の固有IDを採番することで、製品ベンダーやツール間で情報を統一的に扱うことができます。（※このNNNN、初めは年間9,999件までという4桁の制限がありました。しかし脆弱性が増えすぎて足りなくなる懸念から、現在では5桁以上のIDも発行できるよう更改されています）

　近年、このCVEの公開件数が著しく増加しており、2025年には4万件を大きく超えたことが話題となりました[1]。この数字から「脆弱性そのものが急増している」と捉えられがちですが、CVE件数はあくまで「IDが付番され公開された数」です。単純な脆弱性の増加だけでなく、運用ルールや発行体制の変化にも大きく影響を受けます。

　増加の背景の一つにあるのがCVEの付番と公開の実務を担うCNA（CVE Numbering Authority）の拡大です。CNAは、担当する製品・プロジェクトの範囲内でCVEを採番・公開できる権限を持つ組織です。CVEプログラム開始当初はMITREのみでしたが、体制拡充により2025年には400を超える組織がCNAとして登録されており[2]、これが公開件数増加の一因となっています。

　上記のグラフでは、CVE公開件数とその年にCVEを発行したCNAの数を年次推移でプロットしています。これを見ると、CVEの公開件数が増加するにつれて、その発行元となるCNAの数も比例して増えていることがわかります。

　2024年から2025年にかけての急激な件数増加には、特定のCNAによる発行数が大きく影響しているという構造的な要因があります。たとえば、WordPressプラグインの脆弱性を扱うPatchstackやWordfence、Linux Kernelを管理するkernel.org、脆弱性DBを運営するVulDB、そしてGitHub（Maintainer Security Advisories）といった組織です。

　PatchstackとWordfenceは2021年頃から活動を本格化させており、kernel.orgとVulDBは2024年に新たにCNAとして参加しました。これら特定のCNAによる発行数は著しく多く、2025年のCVE公開件数のうち、ここで挙げたCNAから発行されたものだけで2万件を超えています。

　このように、WordPressプラグインのような対象が膨大で脆弱性の単位が細かい領域や、オープンソースのように「修正パッチごとにIDを振る」という方法に近い運用がなされると、CVE件数が積み上がりやすい傾向があります。もちろん件数の増加は影響がないという意味ではありません。しかし、CVEという指標が、単なる脆弱性の増加でなく採番や公開の活発さにも強く依存していることを示しています。

　一方で、CVEの急増は課題も引き起こしています。次の節では、その影響の一つである「NVDのバックログ問題」について取り上げます。

NVDバックログの現状

　NVD（National Vulnerability Database）は、ソフトウェアやシステムの脆弱性情報を集約・提供する米国の公開データベースであり、世界中の多くの組織がセキュリティ対策のために参照しています。NVDは、CVEに登録された脆弱性情報をもとに、詳細な分析・評価情報やメタデータを付加して公開する役割を担っています。

　しかし、2024年2月頃からNVDでの脆弱性情報の処理遅延（バックログ）が報告されており、新たに公開されたCVE情報の反映が遅れるケースが常態化しています。これに対しNISTは、バックログの原因は単一ではなく、脆弱性そのものの増加や支援体制の変化といった複数の要因が重なって発生したと公表しています[3]。

　上記のグラフは、NVDの更新履歴（CVE Change History）をもとに、月ごとの「CVE公開数（Published）」と「NVDによる初期分析完了数（Initial Analysis completed）」、およびその差分から算出した「月末時点のバックログ（stock）」の推移を可視化したものです。

　上段の折れ線は月末時点のバックログ累積数を表しています。下段の棒グラフでは、当月に公開されたCVE件数をプラス（正）、NVDが初期分析を完了した件数をマイナス（負）としてプロットしています。

　ここから読み取れるのは、2024年2月頃にNISTの分析数が一時的に低下し、公開数との差が広がったことでバックログが急増したという事実です。その後、処理支援の導入などにより分析数は回復傾向にありますが、CVEの新規公開件数自体が高水準で推移しているため、バックログが解消されず、高止まりしやすい構造になっています。なお、現状の解析待ち件数についてはNVD Dashboardから確認可能です。

　このグラフは、CVEの公開日からNVDによる「Initial Analysis」が付与されるまでの経過日数を、公開月ごとに区分して可視化したものです。（ただし、以下の点に注意してください）
※データ取得時点で90日以上経過しても付与されていないものは、すべて「≥90日」に含まれています。
※2025年12月のデータは、取得時点からまだ90日が経過していないため、見かけ上「31-90日」の割合が多くなっています。

　バックログ問題が顕在化した時期以降、「≤30日（30日以内）」の比率が低下し、以前にはほとんど見られなかった「≥90日（90日以上）」の比率が大きく増加していることが分かります。これは、NVDによる情報付加において優先度付けが行われるようになり、「短期間で処理される案件」と「長期にわたり処理されない案件」の二極化が進んでいることを示唆しています。

　実際にNISTは、遅延対策として重要な脆弱性を優先して分析する方針を公表しており、こうした優先順位付けの結果、分析完了までの所要日数が偏るようになったと考えられます。

　バックログの拡大は、脆弱性管理の実務における「優先順位付け」と「自動化」に影響を及ぼします。例えば、パッチ適用のSLA管理やアラート抑制の基準にCVSSスコアを用いている場合、「Initial Analysis」の付与が遅れるとNVD由来の評価情報が欠損することになります。その結果、組織はそれぞれのCNAやベンダーが独自に付与したスコアに依存せざるを得なくなり、対応方針の一貫性が保てなくなるリスクがあります。

　次の節では、実際に付与されているCVSSバージョンがどのように推移しているかについて解説します。

CVSSバージョンのトレンド

　CVSS（Common Vulnerability Scoring System）[4]は、ソフトウェア等の脆弱性の特性と深刻度を、共通の形式で評価・伝達するためのオープンなフレームワークです。米国の非営利団体FIRSTが管理しており、評価結果は0.0〜10.0の範囲のスコアとして算出されます。

　2023年11月1日にFIRSTよりCVSS v4.0が正式リリースされました。これに伴い、近年ではベンダーから提供されるCVSSスコアでもv4.0が付与されるケースが増加しています。各年で実際にどのバージョンが採用されているのか、その推移を見てみましょう。

　このグラフは、CVEの公開年を軸に、当該レコードにどのCVSSバージョン（v2.0 / v3.0 / v3.1 / v4.0）が含まれているかを集計したものです。これは「いつ採点されたか」を直接示すものではありませんが、データセットの中に各バージョンがどのように混在しているかという状況を捉えることができます。

　依然としてv3.1が主流であるものの、近年はv4.0が付与されるCVEも出現しており、その比率は徐々に上昇しています。特に2025年に公開されたCVEでは、v4.0のみが割り当てられるものや同一CVE内でv3.xとv4.0が併存するものなど、全体としてバージョンの混在が増加傾向にあります。これはまさにCVSSバージョンの移行期であることを示しており、今後v4.0のエコシステム対応が進むにつれて、この傾向はより強まると考えられます。

　ここで注意すべき点は、NVDが付加したメトリクスに限定しても、必ずしもv3.1とは限らないということです。実データを見ると、主流はv3.1ですが、件数は少ないもののv4.0が付与されている事例も確認されています（例：CVE-2025-3067）。つまり現時点では、NVDのスコアであってもバージョンが混在し得る状況です。加えて、CNAによっては複数のバージョンでスコアを提供することもあるため、以前にも増して「数値だけ」を単一基準として優先度を決めることが難しくなっています。

　バージョンが異なれば、評価体系やメトリクスの設計思想も異なるため、スコアの単純比較はできません。運用上は少なくとも、(1)どのバージョンのスコアか、(2)誰による評価か（NVD / CNA / ベンダー / 第三者）を区別して扱う必要があります。その上で、既知の悪用状況やエクスプロイトの有無など、別軸の指標と併用する判断ロジックへの転換が求められます。

まとめ

　CVEの公開件数が増加し続ける中、人手で逐一脆弱性の影響を確認し判断する運用はスケールしにくく、もはや現実的な選択肢ではなくなりつつあります。また、NVD側の解析遅延（バックログ）により情報のタイムラグが生じるため、判断材料を複数のソースで補うアプローチが不可欠です。

　例えば国内では、JVN iPedia[5]を活用して国内外の対策情報を横断的に参照できます。また、米国のCISA Vulnrichment[6]では、CVEレコードに対してSSVC（Stakeholder-Specific Vulnerability Categorization）の主要な決定点を付与し、NVDの情報を補完する取り組みが行われています。さらに、実際の悪用が確認された脆弱性カタログであるCISA KEV[7]や、今後30日以内の悪用確率を推定するFIRSTのEPSS[8]なども、CVSS以外の重要な判断材料となります。

　本稿では、CVE件数の増加とNVD解析遅延の現状を可視化し、CVSSバージョンの混在も含めて、従来の読み方だけでは判断が難しくなっている点を整理しました。今後は単一の指標やデータソースに依存せず、複数ソースを前提に事実を把握し、自組織のリスク観点に合わせて情報を取捨選択していく姿勢が求められます。

参考URL