著者: Gene Moody(Action1 Field CTO)
AIによって、私たちはかつてないスピードで脆弱性を発見できるようになりました。しかし、脆弱性管理エコシステムの他の部分がそのペースに追いつけなくなったらどうなるのでしょうか。
脆弱性の量がシステムの処理能力を超える時
2026年4月、NISTはNVD運用に関する更新について声明を発表しました。これは、規模の拡大に対応するためのやむを得ない措置と言えます。CVEの件数は、現行のエンリッチメント(付加情報付与)モデルが想定していた処理能力を超えて増え続けています。この変更の一環として、2026年3月1日より前に公開された約30,000件の脆弱性が「Not Scheduled(処理予定なし)」に再分類されました。
優先順位付け、自動化、選択的な処理といった対応は、原則としては妥当な調整です。しかし実際には、この方針転換によって、必ずしも十分に理解されていない一連のリスクが生じます。特に、企業環境の防御を担う担当者にとってはなおさらです。
この圧力は決して机上の話ではありません。Action1の「2026年ソフトウェア脆弱性評価レポート」によると、分析対象となった企業向けソフトウェアカテゴリー全体で、2025年に公開された脆弱性は2024年比で92%増加しました。緊急(Critical)および重要(High)レベルの脆弱性はそれぞれ103%増加し、リモートコード実行(RCE)を可能にする脆弱性に至っては128%も増加しています。
今日、検証・エンリッチメント・優先順位付け、そして最終的な修正が必要な開示件数の多さは、より処理速度の遅かった時代向けに設計されたシステムに、かつてないほどの負荷をかけていると考えられます。
したがって、本質的な問題は単にバックログが存在すること自体ではありません。バックログは、急速な成長下にあるあらゆるシステムで生じる当然の結果です。むしろ問題なのは、そのバックログがどのように管理されているか、そしてより重要なことに、未処理の古い脆弱性よりも新しい脆弱性を優先するという判断が、どのようなシグナルを生み出すのかという点です。
エンリッチメントが追いつかなくなるとどうなるか
エンリッチメント作業を直近のCVEのみに集中させることで、このシステムは、すでに存在が判明し確認されている脆弱性——場合によってはベンダーや研究者の間ですでに活発に議論されているものの、NVDの完全なコンテキストを欠く脆弱性——を暗黙のうちに後回しにしてしまいます。
これは特に厄介な種類の情報非対称性を生み出します。情報の後半部分——実際に行動に移すために必要な部分——を欠いた、断片的なインテリジェンスです。NVDを標準化された脆弱性情報源として重視しているセキュリティチームは、不完全ないし遅延したデータを目にすることになるでしょう。
一方で攻撃者は、ベンダーのアドバイザリ、セキュリティ調査、パッチのリリース、エクスプロイト情報、そして公開された開示情報を関連付けるにあたり、標準化されたエンリッチメントを待つ必要はありません。
このギャップが重要なのは、エンリッチメントが単なる体裁の問題ではないからです。構造化されたメタデータ、影響を受けるプラットフォームの情報、深刻度スコア、構成に関する詳細、その他のコンテキスト情報があってはじめて、防御側はある脆弱性が実際に自社環境に該当するかどうか、そしてどれほど緊急に対応すべきかを判断できます。
こうした情報が欠落あるいは遅延している場合、組織は追加のコンテキストが提供されるのを待つか、断片的な情報のまま判断を下すかの二択を迫られることになりがちです。エクスプロイトが内部の検証・修正プロセスよりも速く進行し得る脅威環境において、どちらの結果も望ましいものではありません。
それだけではありません
さらに、定量化はしにくいものの同様に重要な二次的影響もあります。継続的に新規案件が流入する一方で選択的にしか処理されないバックログは、カバレッジに対する不確実性を生み出します。古い案件を明確な期限内に処理するというコミットメントがなければ、バックログは半永久的な状態と化してしまいます。
一部の脆弱性は迅速にエンリッチメントが行われる一方で、他は宙に浮いたままとなり、ある時点でどのCVEがどちらのカテゴリーに属しているのかを把握する手段は限られています。
これは、現場の担当者にとって優先順位付けを著しく複雑にします。CPEデータなど、影響を受ける製品に関する情報が不完全であったり、範囲が過度に広かったりすると、組織は誤検知(false positive)のリスクをより多く抱えることになります。チームは自社環境に該当しない脆弱性の調査に時間を費やす一方で、実際に該当するリスクを見落としてしまう可能性があるのです。
時間が経つにつれ、これは間違いなくデータセットへの信頼を損ない、組織を代替のインテリジェンス基盤の構築へと駆り立てるでしょう。それは追加のコスト、ツール、運用の複雑化につながり、また容易に予想できるとおり、失敗率の増加にもつながります。
脆弱性管理は変わりつつある
だからといって、NISTが無責任な対応をしているというわけではありません。規模の問題は現実のものであり、既存のモデルは現在エコシステムに流入している脆弱性情報の量を想定して設計されたものではありませんでした。しかし、今回導入されたトレードオフは、より多くの責任を下流へと押し付けることになります。
組織は今後、単一の権威ある情報源への依存を減らし、NVD、ベンダーのアドバイザリ、独立系の脆弱性インテリジェンスプロバイダー、脅威インテリジェンスプラットフォーム、そして社内の資産インベントリなど、複数の情報源を横断した相関分析により重きを置く必要が出てくるでしょう。
一歩引いて見ると、脆弱性管理は、精査済みのリストを単に消費するものから、不完全なデータからほぼリアルタイムで正確なインテリジェンスを組み立てる作業へと変化しつつあります。これには、すべての組織が現時点で備えているとは限らない成熟度、ツール、そしてプロセス上の規律が求められます。
この方向性が続くのであれば、NVDは今後も脆弱性管理エコシステムの重要な構成要素であり続けるものの、単独で包括的な基盤として機能することはなくなるでしょう。代わりに、数ある入力情報の一つとなり、現場でのエクスプロイトの実態から大きく遅れる可能性のある情報源となります。
そうなると、より重要な問いは単に「どんな脆弱性が存在するか」ではなく、「そのうちどれが自社に影響を及ぼすのか、どれが最大のリスクを表しているのか、そしてどれだけ迅速に対応できるのか」ということになります。
防御側はどう適応すべきか
第一の教訓は、脆弱性管理がもはや単一のエンリッチメント情報源に依存できないということです。NVDは依然として非常に価値のある存在ですが、セキュリティチームは、利用可能なデータを実用的なインテリジェンスへと集約するベンダーや組織の総合的な成果物を、ますます活用する必要に迫られています。
さらに重要なのは、追加のフィードを収集することは答えの一部にすぎないという点です。情報が増えることは、それ自体が新たな優先順位付けの問題を生みかねません。本当に目指すべきは、断片化した脆弱性インテリジェンスを一つの判断に変換することです。すなわち、「この脆弱性は自社に影響するのか、どれほど緊急性が高いのか、そして今何ができるのか」という判断です。
これは、Action1が脆弱性管理において採用しているモデルです。NVDのエンリッチメントのみに依存するのではなく、Action1はVulnCheck NVD++、NIST NVD、CISAのKEVカタログ、MicrosoftのMSRC独自データ、ベンダーのリリースノートなどの情報源からインテリジェンスを統合します。そのうえで、CVEデータ、CVSSの深刻度、CISA KEVステータス、ランサムウェアキャンペーンでの使用実績の有無に基づいて各脆弱性をスコアリングし、数分以内に初期の優先順位付けを提供します。
そのインテリジェンスはリアルタイムのエンドポイントデータと相関付けられるため、チームは自社環境に展開されているソフトウェアに実際に影響する脆弱性がどれかを判断し、それに応じて修正作業の優先順位を付けることができます。
影響を受けるエンドポイントが特定された後は、パッチ適用を開始するのに、別途のエクスポート作業や手作業での突き合わせ、あるいは長々とした引き継ぎ作業は必要ありません。
Action1は脆弱性評価と修正作業を同一のワークフローに統合しており、組織は単一のコンソールから、脆弱性の存在を把握する段階から実際のリスクエクスポージャーを削減する段階まで、はるかに速く移行できます。
AIが脆弱性を発見する時代を特徴づけるのは、ITおよびセキュリティチームがどれだけ速く欠陥を見つけられるかではなく、それらをどれだけ迅速に理解し、優先順位を付け、パッチを適用できるかです。発見のスピードが加速している以上、修正のスピードもそれに合わせて加速させなければなりません。
Action1がリアルタイムのOSおよびサードパーティ脆弱性インテリジェンスを自動修正機能とどのように連携させ、チームによるリスクエクスポージャーの削減を加速させるのか、ぜひご覧ください。
無料で始めることができ、準備が整い次第スケールアップも可能です。
