NIST、CVEの全件enrichmentを断念 — 2026年からの脆弱性管理はどう変わるか

はじめに

2026年4月15日、NIST は NVD（National Vulnerability Database）の運用方針を大きく変えた。これまで登録された CVE のほぼ全件に対して付与してきた CVSS スコアや CPE、CWE などの補足情報（enrichment）を、すべての脆弱性に対して自動的に行うのをやめる、という発表である。世界中の脆弱性管理プロセスが「NVD を見れば CVSS が付いている」という前提で組まれてきたことを考えると、地味に見えて影響は大きい。本記事では何が変わったのか、なぜ変わらざるを得なかったのか、そして運用現場で何を見直すべきかを整理する。

何が起きたのか — NIST の新方針

NIST は今後、すべての CVE ではなく以下 3 カテゴリに絞って独自の enrichment を行う、と発表した。

CISA の KEV（Known Exploited Vulnerabilities Catalog）に掲載されている CVE
米国連邦政府で実際に使用されているソフトウェアに関する CVE
大統領令 14028 の「重要ソフトウェア」定義に該当するもの（OS、ブラウザ、エンドポイントセキュリティ、VPN、ファイアウォール等の広いリスト）

それ以外の CVE は NVD に登録はされるものの、CVSS の独自算出を含む enrichment は行われない。NVD 公開日が 2026 年 3 月 1 日より前で未処理のものは、KEV 掲載分を除いて「Not Scheduled」に移される。加えて、CVE Numbering Authority（CNA）側ですでに CVSS スコアが付けられている場合、NIST 側で独自の再スコアリングも行わない方針になった。

数字を追うと、この転換の必然性は明らかだ。Help Net Security によれば 2020〜2025 年の 5 年間で CVE 発行数は 263% 増加、NIST は 2025 年だけで約 42,000 件を enrichment した（前年比 +45%）のに、2026 年 Q1 時点の新規 CVE はさらに前年同期比で 3 分の 1 以上増 のペースで伸びている。手作業が前提の enrichment 体制では、どれだけ人を増やしても追いつかない規模に達してしまった。

技術的な背景 — NVD / CVSS / KEV の役割分担を理解する

CVE、NVD、CVSS、KEV、Vulnrichment といった用語が入り乱れるので、役割を一度整理したい。

CVE（Common Vulnerabilities and Exposures）: MITRE を中心に運用される脆弱性の識別子。CVE-2026-XXXXX の形で、脆弱性ごとに ID だけを払い出す。
NVD（National Vulnerability Database）: NIST が運用する、CVE に「使える情報」を肉付けするデータベース。ここで CVSS スコア、影響を受けるプロダクトを示す CPE、脆弱性分類である CWE などが紐づいてきた。これまで「NVD = 脆弱性管理ツールが参照する一次ソース」だった理由はこの enrichment にある。
CNA（CVE Numbering Authority）: ベンダーや OSS プロジェクトなどの CVE 払い出し権限を持つ組織。CVE 登録時に自ら CVSS を付けることもある。
KEV（Known Exploited Vulnerabilities Catalog）: CISA が運用する、実際に悪用が観測された脆弱性のリスト。数は少ないが「今まさに攻撃されている」ことが保証された、実運用上もっとも優先度の高い CVE 群。
Vulnrichment: CISA が 2024 年に始めたプログラムで、2025 年 1 月からは CVE の JSON に「ADP（Authorized Data Publisher）」コンテナという形で SSVC（Stakeholder-Specific Vulnerability Categorization）や CWE を埋め込んでいる。NVD を補完する代替エンリッチメント源である。

今回の変更を一言で言うなら、「enrichment のデフォルト供給元が NIST から 各 CNA + CISA Vulnrichment の分散構成に変わる」ということだ。単一の信頼できるデータソースは実質的に消え、脆弱性管理は複数ソースを束ねる前提で再設計する必要がある。ベンダー自身が CVSS を付けるケースが増えれば、スコアが意図的に低めに付けられるリスク（自社製品の深刻度を軽く見せたい動機）も無視できない。

エンジニアへの影響 — 明日から何を変えるか

セキュリティ担当でなくても、CI に npm audit や trivy、grype を仕込んでいるエンジニアは全員この変更の当事者である。これらのツールの多くは NVD の CVSS を優先度判定の根拠にしているため、未 enrichment の CVE が急増すれば「Unknown Severity」扱いで alert が鈍るか、逆にベンダー付与スコアに振り回されてノイズが増える可能性が高い。

実務で取るべき対応はおおむね次のようになる。

KEV を最優先のシグナルに格上げする: CISA KEV に掲載された CVE は「今攻撃されている」ことが確認されているため、従来の CVSS ≥ 9.0 ベースのルールより強い優先度として扱う。多くのスキャナーは KEV フラグを扱えるので、無効なら有効化する。
Vulnrichment（ADP）対応の有無を確認する: CISA の SSVC/CWE を読める脆弱性管理ツールかどうかを確認し、対応していないならアップデートまたは乗り換えを検討する。
ベンダー CVSS を鵜呑みにしない: 影響プロダクトが自社の攻撃面に晒されているかは自分たちで判定する前提に切り替える。攻撃ベクトル（AV）・攻撃条件（AC）・権限要件（PR）を見て、自社環境に当てはめて再評価するワークフローを整備する。
Firebase/GCP の API キー事案のような”運用起因の露出”も併せて見る: NVD だけでは拾えない「設定ミスで外に出たキー」の類は別系統（Secret Manager、commit hook、GitHub Secret Scanning など）で防ぐ必要がある。4 月 18 日時点で国内でも 13 時間で約 900 万円の請求という実例が話題になっており、脆弱性と運用ミスの両面で守りを組む時期にきている。

まとめ

NIST NVD の enrichment 縮小は、単なる運用変更ではなく「CVE 数の爆発に対して手作業の一次ソースが耐えきれなかった」という構造的な転換点である。これからの脆弱性管理は、CISA KEV を最上位シグナルに置き、Vulnrichment の ADP データを補完として組み合わせ、ベンダー付与 CVSS は参考値として扱うという多層構造に移っていく。ツールまかせだった脆弱性トリアージを、自社環境の前提で再評価できる体制を持てるかどうかが、今年後半の差になると見ている。

今日のその他のニュース

Claude Opus 4.7 の新トークナイザでコストが 20〜30% 増えるという実測

Anthropic が Claude Opus 4.7 を公開した直後、Claude Code Camp の実測レポートが Hacker News で 316pts を獲得。新トークナイザにより、同じ作業でもセッションあたりのトークン消費が 20〜30% 増えるという結果が出ている。Claude Code を常用している場合、Haiku / Sonnet へのフォールバック方針を事前に決めておくと安全。

Google API キー漏洩で 13 時間・約 900 万円請求の事案

Qiita に投稿された事例で、漏洩した Google API キーにより 13 時間の間に約 900 万円が課金された。Firebase / GCP を使うプロジェクトでは、Secret Manager 化、課金上限アラート、commit hook でのキー検出を最低ラインとして組み込んでおきたい。

MySQL の `deleted_at` に雑にインデックスを貼ると本番 DB が死ぬ

論理削除用の deleted_at にそのままインデックスを貼ると、MySQL のオプティマイザが誤判定してプランが崩れるアンチパターン。Zenn の記事で実例付きで解説されており、論理削除を採用している既存プロジェクトは一度実行計画を確認しておくと安全。