セキュリティの世界で長年「当たり前」として使われてきたインフラが、静かに変わり始めている。米国立標準技術研究所（NIST）は2026年4月15日より、National Vulnerability Database（NVD）における低優先度CVEへの重要度スコア付与・詳細情報付加を事実上停止した。日本のセキュリティ担当者にとって、これは見逃せない変化だ。

NVDとは何か、なぜ重要か

NVDはソフトウェア・ハードウェアの既知脆弱性を集約した公開データベースで、CVE IDに対してNISTが独自の分析を加えることで真価を発揮してきた。具体的には以下を付加していた：

  • CVSSスコア（深刻度の数値化）
  • 影響を受ける製品バージョンの特定
  • CWE分類（脆弱性の種類の分類）
  • パッチや勧告へのリンク

これらの情報があるからこそ、SIEMやVMツールが「このCVEは自社環境に該当するか」「どれを先に対応すべきか」を自動判断できる。単なるIDリストでは機械処理できないのだ。

何が変わったか

今後NISTが詳細分析を行うのは、以下の条件を満たすCVEのみとなる：

  • CISAの「Known Exploited Vulnerabilities（KEV）」カタログに掲載されているもの
  • 米連邦政府のソフトウェアに影響するもの
  • 大統領令14028で定義される「重要ソフトウェア」に関わるもの

それ以外のCVEは「Not Scheduled」に分類され、CVE番号の登録は行われるがNISTによる重要度評価は付与されない。CNAが独自に付けたスコアのみが残る形だ。

この判断の背景には、提出件数の急増がある。NISTは最近の263%増という数値を挙げており、2025年に42,000件を処理したものの、2026年に入っても増加が続き対応限界に達したと説明している。要請があれば低優先度CVEも個別に対応する（nvd@nist.gov）という逃げ道は残されているが、組織的なカバーは期待できない。

実務への影響

脆弱性管理ツールの評価基準が変わる

Tenable、Qualys、Rapid7、Microsoft Defender for Vulnerabilityといった主要VMツールは、NVDのデータを取り込んでスコアリングを行っている。NVD由来のCVSSスコアが欠落したCVEが増えると、これらのツールが「スコアなし＝低リスク」と誤解釈する可能性がある。ツールベンダーがどう対応するか、リリースノートを注視する必要がある。

KEVカタログの重要性がさらに高まる

CISAのKEVカタログは今後もNISTの優先対応対象であり続ける。日本のIT管理者はKEVカタログを直接参照する習慣をつけるべきだ。KEVに掲載されたCVEは「実際に攻撃に使われている」ことが確認済みのものだけが並ぶ、より実践的な指標だ。

CNAスコアへの依存リスク

CVE番号を割り当てるCNAにはベンダー自身も含まれる。自社製品の脆弱性を自社がスコアリングするという構造には、利益相反のリスクが内在する。「ベンダーがつけたスコアをそのまま信じる」運用は再考が必要だ。

SBOMとの連携がより重要に

ソフトウェア部品表（SBOM）を整備し、利用コンポーネントとCVEのマッピングを自動化しておくことで、「自社に影響があるCVEか」を自力で判断できる体制を整えることが求められる。NVDへの依存度を下げる構造的な対応だ。

筆者の見解

セキュリティ担当者の間では「NVDの遅延は2024年から続いていた」という声も多く、今回の正式宣言は既定路線の明文化とも言える。とはいえ、これを単なる「NISTのリソース問題」として片付けるのは危険だ。

本質的な問題は、CVEの発行数が人間の処理能力を超えた速度で増加し続けているという構造にある。2025年の42,000件という数字自体、毎営業日約160件を処理し続けたことを意味する。AIによる脆弱性発見・報告の自動化が進む中、この傾向は今後さらに加速するだろう。

日本の現場に目を向けると、NVDのCVSSスコアを「絶対的な判断基準」として脆弱性管理プロセスに組み込んでいる組織が多い。しかしそれは、特定の外部サービスが正常稼働することを前提にした設計であり、今回のような変化に対して脆弱だ。

正しい方向性は、単一のスコア源に依存しない多層的な評価体制の構築だ。KEVカタログ、ベンダーアドバイザリ、EPSS（悪用可能性スコア）を組み合わせ、自社環境のコンテキストで優先度を判断できる仕組みを作ること。それはゼロトラストの考え方と同じで、「信頼できる単一の源泉があれば安心」という発想から脱却することでもある。

NVDは引き続き存在し続け、高優先度CVEについては引き続き詳細情報が提供される。パニックになる必要はない。ただ、この変化を契機に自組織の脆弱性管理の依存構造を見直す良い機会ととらえ、次の一手を打っておきたい。

出典: この記事は NIST to stop rating non-priority flaws due to volume increase の内容をもとに、筆者の見解を加えて独自に執筆したものです。