AI時代のNVD：複数ソースによる脆弱性インテリジェンスが必要な理由

20年以上にわたり、世界のセキュリティコミュニティは、業界が必要とするペースでソフトウェアの脆弱性を追跡、分析、エンリッチメントするために、単一の集中的な公開ソースが役立つという、ある意味で安心できる前提のもとに活動してきました。

National Vulnerability Database（NVD）が設立された当時、オープンソースの脆弱性対応は現在とはまったく異なるペースで進んでいました。オープンソースのエコシステムはより小規模で、リリースサイクルは遅く、公開される脆弱性の数も、中央集約型のエンリッチメントで管理しやすいものでした。

しかし、現代のソフトウェアエコシステムは、もはや従来のパラダイムでは対応できない規模に達しています。2026年4月15日、National Institute of Standards and Technology（NIST）は運用方針を見直し、長年掲げてきたすべての脆弱性をエンリッチメントするという方針を変更しました。処理しきれないほどの登録が寄せられるなか、同機関は優先順位に基づくトリアージモデルを発表し、現在のリソースではすべてのCVEを完全にエンリッチメントすることは現実的な目標ではないと明言しました。

Snykへの影響

全体的な影響：独立した運用

Snykは脆弱性のエンリッチメントをNVDだけに依存していないため、NISTの発表によって脆弱性インテリジェンスへのアプローチが変わることはありません。むしろ、これは私たちが何年も続けてきたアプローチを裏付けるものです。以前「SnykユーザーがNVDの遅延を回避する方法」で説明したとおり、NVDは重要な情報源ですが、複数の脆弱性情報源、セキュリティアナリストによる検証、オープンソースのコンテキストを含む、より広範なインテリジェンスエコシステムの一部です。

このアプローチにより、公開情報のエンリッチメントモデルが変化しても、お客様は十分な情報に基づいて優先順位を判断し続けることができます。

公共機関による検証プロセスだけに頼るのではなく、Snykのデータは多層的な社内プロセスを通じてエンリッチメントされています。該当する場合は、NVDのCVSSベクトルとSnyk独自のCVSS評価を併記し、複数の情報源で脆弱性がどのように評価されているかを把握できるようにしています。Snyk Intelligenceは、CVEの有無だけでなく、オープンソースソフトウェアの文脈において何を意味するのかをお客様が理解できるよう設計されています。脆弱性のあるパッケージバージョン、修正プログラムの有無、各情報源でのリスク評価、修正の優先順位を明確に把握できます。

Snykは多様な情報源から脆弱性アドバイザリを収集するだけでなく、以下を通じてセキュリティデータベースを強化し、継続的に再評価・更新しています。

• 社内セキュリティリサーチ

• 脅威インテリジェンスの統合：エクスプロイトの動向、ソーシャルメディアでの言及、PoCの公開など、幅広いシグナル

• コミュニティからの貢献：独立系研究者やプロジェクトメンテナーなど、オープンソースコミュニティからの責任ある脆弱性開示

• 学術機関・研究機関との連携

• 顧客を中心とした優先順位付け：生の脆弱性データを、開発者やAppSecチームの優先順位付けワークフローに役立つ、実行可能なインテリジェンスへと変換

• AI支援と人による検証を組み合わせたインテリジェンス：脆弱性が増加するなか、SnykはAI支援ワークフローと自動化を活用し、大量の脆弱性シグナルを大規模に収集、絞り込み、優先順位付け、エンリッチメントしています。しかし、自動化だけでは十分ではありません。Snykは人が関与するアプローチを維持し、訓練を受けたセキュリティアナリストがAI生成の提案を検証・承認することで、信頼できる正確で実用的な脆弱性インテリジェンスをお客様に提供できるようにしています。

脅威データの新時代

今回の変更の内容とは？

NVDはリスクベースのトリアージモデルへ移行し、すべての脆弱性を迅速にエンリッチメントするという従来の目標から転換しました。この構造的な変化は、特にCVSSスコアや優先度が下がったソフトウェアのエンリッチメントをNVDのデータに大きく依存する従来型のスキャナーにおいて、業界に重大な盲点を生む可能性があります。新たに導入されたこのアプローチでは、以下のいずれかに該当するCVEが完全なエンリッチメントの優先対象となります。

• CISAの既知の悪用された脆弱性（KEV）カタログに掲載されたCVE（受領から1営業日以内のエンリッチメントを目標とします）。

• 米国連邦政府で使用されているソフトウェアのCVE。

• 大統領令14028で定義された重要ソフトウェアのCVE。

これらのカテゴリに含まれないCVEは、すべて「優先度最低—即時のエンリッチメント予定なし」に分類されます。この対象範囲のギャップを数字で見ると、2025年だけで48,185件の固有のCVEが公開された一方、CISAの既知の悪用された脆弱性（KEV）カタログに同年末までに追加された項目は約245件です。2026年の脆弱性件数とKEVの動向については、2025年にCISAの既知の悪用された脆弱性が20%増加をご覧ください。
この公開フレームワークだけに依存すると、組織はスキャナーを、政府が承認した対象を厳選したリストに合わせて調整することになります。その結果、現在は重要または積極的に悪用されていると分類されていなくても、現代のアプリケーションセキュリティを支える膨大なオープンソースパッケージについて、重要なコンテキストを見落とすおそれがあります。

さらに、2026年3月1日より前に公開された過去のCVEのかなりの部分が「予定なし」に分類され、さらに多くが「エンリッチメント後に変更」とされています。これは、従来のモデルなら再評価されていたようなケースでも、必ずしも再評価されないことを意味します。更新されたエンリッチメントモデルの一環として、以前から滞留していた脆弱性が再分類されたことを示しており、新たなアプローチにおいてバックログ管理が占める規模の大きさを浮き彫りにしています。

重要なのは、重複作業を減らすため、NISTがスコアリングや変更の取り扱いについても大幅な運用変更を導入したことです。

• 深刻度スコアの効率化：提出元のCVE Numbering Authority（CNA）（ソフトウェアベンダーやパッケージメンテナーなど）がすでにスコアを提供している場合、NISTは別個の深刻度スコアを通常は付与しなくなります。

• 変更されたCVEの取り扱い：従来の方針に従って変更されたCVEをすべて再分析するのではなく、エンリッチメントデータに重大な影響を及ぼす変更を把握した場合にのみ、NISTは再分析を行います。

この変化により、セキュリティチームは脆弱性エンリッチメントの情報源と背景を理解する必要性が高まっています。NISTが独立した深刻度スコアを追加で提供しない場合、組織はCNAが提供するスコア、ベンダー提供のメタデータ、その他のエンリッチメント情報源への依存を強める必要があるかもしれません。CNAが提供するデータは価値があり、影響を受けるソフトウェアを最もよく知るメンテナーによるものであることも多い一方、スコアリング手法、リスクの解釈、脆弱性開示の動機、修正期限やSLAへの期待といった運用上のプレッシャーに違いが生じる可能性もあります。
だからこそ、情報源の透明性、独立した検証、複数ソースによる脆弱性インテリジェンスがこれまで以上に重要です。

これは避けられなかった

この変化は一夜にして起きたものではありません。脆弱性管理を支える事実上の仕組みに長年かかっていた負荷が、ついに限界に達した結果です。年間のCVE登録件数が2020年の約18,000件から2025年には48,000件超へと263%増加したことで、NVDの処理体制は計算上、成り立たなくなりました。これはCVEシステムの構造的な変化によるものです。CVEの割り当ては中央集権型から連合型へ移行し、事務処理上のボトルネックが解消される一方で、より幅広く多様な割り当て機関が公開脆弱性の登録に参加できるようになりました。同時に、AIは脆弱性リサーチのペースも変えています。AIは、脆弱性の発見や検証から概念実証（PoC）の作成、報告まで、リサーチプロセスの複数の段階を研究者がより速く進めるのを支援しています。AIが生成するレポートのすべてが高品質というわけではありませんが、脆弱性に関するシグナルの量と速度が今後も増加する可能性は高いでしょう。

NISTの発表は、この現実を反映したものです。2025年には約42,000件のCVEをエンリッチメントしました。これは過去最高だった年を45%上回る数字ですが、それでもNISTは、生産性の向上だけでは増え続ける登録に追いつけなかったと説明しています。

新しいリスクベースモデルは、NISTが最も重大なCVEに注力し、プログラムを安定させるとともに、長期的な持続可能性に必要な自動化システムとワークフローの改善を進めることを目的としています。そのため、脆弱性管理のパイプラインに質の高いデータを入力する責任はソフトウェアの供給者や脆弱性報告者に戻る一方で、データ全体を読み解く負担はエンドユーザーと、そのために使うツールにかかります。

なぜ今なのか？

CVEが急増した根本的な要因は、2文字で表せます。AIです。
「AI時代の脆弱性リサーチ」の詳しい解説で取り上げたように、人工知能は脆弱性発見の経済性を一変させました。AIを活用した自動検出ツールは、コードベースを自律的に分析して欠陥を見つけ、人間の研究者が同じ成果を出すのに必要な時間のほんの一部で、何千もの脆弱性レポートを生成できます。
この結果、AI検出ツールが既存のコードベースを大規模かつ徹底的にスキャンし、脆弱性に関するデータを前例のない規模で生み出すという、継続的なフィードバックループが発生しています。

しかし、この増加はAIだけが原因ではありません。脆弱性の報告方法における大規模な運用の変化も影響しています。急増は、連合型CVEモデルが拡大した数年前にすでに始まっていました。2018年、このプログラムはCVE Numbering Authority（CNA）のネットワークを急速に拡大し、分散化されました。かつては少数の組織がデータ登録を担っていましたが、現在はソフトウェアベンダー、パッケージメンテナー、クラウドプロバイダーを含む500を超える独立したCNAが、世界の公開データベースに同時に脆弱性情報を直接公開しています。

Snykは、これも脆弱性インテリジェンスの進化が必要な理由の一つだと考えています。課題は、単にデータを増やすことではありません。本当に重要なのは、データにコンテキストを加え、検証・エンリッチメントし、優先順位を付けることです。そうすることで、セキュリティチームと開発チームは、本当に重要な問題に集中できます。

ノイズより品質を

セキュリティチームと開発チームには、信頼でき、理解し、行動に移せる脆弱性インテリジェンスが必要です。

Snykは、精密な脆弱性マッピングを重視しています。オープンソースプロジェクト全体にリスクを割り当てるのではなく、Snyk Open Sourceは可能な限り、影響を受ける特定のパッケージ、脆弱なバージョン範囲、関連コンポーネントやコードパス、利用可能な修正、アドバイザリの根拠を特定します。これにより不要なノイズを減らし、実際に修正が必要なものについて、開発者や修正エージェントに明確な指針を提供できます。

先述のとおり、AIが生成するレポートは有用な手がかりを見つけるのに役立ちます。しかし、私たちの経験では、不完全な分析、重複する指摘、慎重な検証が必要な質の低いシグナルも頻繁に生み出します。根拠が不十分な脆弱性レポート、影響評価が不明確なレポート、最終的にメンテナーの審査に耐えられない指摘が生成されるケースを、私たちは何度も確認しています。たとえば、プロジェクトメンテナーが脆弱性レポートを却下した場合、Snykは追加のレビューを行ったうえで、その内容をSnykの脆弱性インテリジェンスに反映するか、どのように反映するかを判断します。

エビデンス、帰属、検証に意識的に焦点を当てることで、アラート疲れを軽減し、エンジニアリングチームとAppSecチームが、正確で関連性が高く、実行につながる脆弱性に集中できるようになります。

今後の展望

NVDの更新は、脆弱性管理が新たな段階に入ったことを明確に示しています。CVEは引き続き重要な共通識別子であり、NVDも脆弱性情報を補完する重要な公開ソースです。しかし、脆弱性の数が増加し、AIによって脆弱性の発見、検証、報告が加速するなか、セキュリティチームは単一の情報補完ソースや固定的な深刻度スコアだけに頼ることはできません。

今後の脆弱性インテリジェンスを形作るのは、コンテキスト、優先順位付け、そして実用性です。もはや目標は、脆弱性を一つずつ評価することではありません。攻撃対象領域を継続的に更新し、最も重要なリスクと、全体的なリスク露出の低減に最も効果的な対策を明らかにすることで、人とAIエージェントを支援することです。

Snykにとって、インテリジェンスが目指すべき方向はまさにここです。Snykは、複数ソースからの情報補完、オープンソースエコシステムのコンテキスト、AIを活用したワークフロー、そして人間のセキュリティ専門知識を組み合わせ、お客様が膨大な脆弱性情報から、十分な情報に基づく優先順位付けと対策へと移行できるよう支援します。

脆弱性を取り巻く状況が進化し続けるなか、脆弱性インテリジェンスもそれに合わせて進化しなければなりません。情報の補完や深刻度の評価にとどまらず、より迅速で的確なセキュリティ判断の基盤となる必要があります。