脆弱性データベースだけではリスクを判断できない時代
セキュリティチームや MSP は、それぞれの環境における実際のリスクに基づいて、脆弱性に優先順位を付ける必要があります。このブログでは、その理由を解説します。
2026 年 9 月 8 日、Manu Santamaría Delgado 著
NIST（米国国立標準技術研究所）による国家脆弱性データベース（NVD）の運用方法が変更され、組織がこの主要な脆弱性情報データベースを活用して脆弱性を管理する方法が、根本的に変わりました。これまで NVD では、CVSS スコア、影響を受ける製品、CWE による分類、参照リンクなど、脆弱性に関する詳細な補足情報が提供されていました。しかし、NIST は現在、こうした詳細情報を優先度の高い脆弱性に絞って提供する方式へと移行しています。具体的には、CISA の KEV カタログに掲載されている脆弱性、米国連邦政府が使用するソフトウェアに影響を及ぼす脆弱性、または重要なソフトウェアに関連する脆弱性が対象となります。
この変更の背景には、脆弱性の件数が急増する一方で、NVD が現在の要求に対応しきれなくなっているという問題があります。だからといって、脆弱性が公開データベースからなくなるわけではありません。むしろ、多くの脆弱性については、その深刻度や影響を受ける製品、対処の緊急性を判断するための情報が、これまでのように一元的に提供されなくなります。
その結果、組織は、どの脆弱性へのパッチ適用を優先すべきか判断する際に、外部のデータベースや一律のスコアだけに頼ることはできなくなります。脆弱性は、一見すると優先して対処すべきものに見えても、重要性の低い資産や十分に保護された資産に影響するものであれば、実際の脅威は限定的かもしれません。逆に、あまり注目されていない脆弱性でも、インターネットに公開されたシステムやビジネスに不可欠なシステムに影響していたり、不審なアクティビティの兆候が見られたりする場合は、より迅速な対応が必要になる可能性があります。
MSP の場合、インフラ、優先度、エクスポージャのレベルが異なる複数の顧客を管理するため、この複雑さはさらに増します。まったく同じ脆弱性でも、外部に公開されたサービスを利用している顧客にとっては緊急に対応すべき問題である一方、対象資産の重要性が低かったり、補完的なセキュリティ対策が講じられていたりする別の顧客にとっては、優先度の低い問題である可能性もあります。
実際のリスクに基づいて脆弱性の優先順位を判断する方法
外部から得られるコンテキスト情報が不足している場合、優先順位の判断基準は、脆弱性そのものだけに注目するのではなく、対象となる資産、エクスポージャ、観測されたアクティビティに基づくものへと変える必要があります。そのために、セキュリティチームや MSP は、次の明確なプロセスに従う必要があります。
- 最新の資産インベントリを維持する：
最初のステップは、組織がどのようなシステムを保有しているのか、それらがどこに存在し、どのような役割を担い、どのサービスを支えているのか、そしてどの程度エクスポージャがあるのかを正確に把握することです。この基盤がなければ、どのような判断も不完全なものになってしまいます。 - 実際にシステムに影響する脆弱性を特定する：
どのエンドポイント、サーバー、アプリケーションに対処が必要なのか、どのようなパッチが利用できるのか、またパッチを適用することでどのような影響が生じる可能性があるのかを把握することが重要です。このステップにより、単なる CVE の一覧を見るだけでなく、どのシステムに対応が必要で、どのような対策を講じられるのかを具体的に把握できるようになります。 - 資産が実際にどの程度さらされているかを評価する：
隔離されたシステムに存在する脆弱性と、インターネットに公開されている資産、機密性の高いネットワークに接続されたシステム、あるいは外部にサービスを公開しているシステムに存在する脆弱性とでは、対応の緊急性が同じではありません。 - 脆弱性とエンドポイントのテレメトリを関連付ける：
影響を受けるシステムで異常なアクティビティ、悪用の試み、不審なプロセスの実行、または侵害の痕跡（IoC）が確認された場合、その脆弱性の優先度を引き上げ、対処を急ぐ必要があります。 - レイヤーをまたいだテレメトリを関連付ける：
脆弱性、資産、ネットワーク、エンドポイント、アイデンティティ、観測されたアクティビティに関する情報を組み合わせることで、どの資産が影響を受けているのか、どの程度のリスクにさらされているのか、そしてどのような対策を講じればリスクを最も効果的に低減できるのかといった、運用上の疑問に答えられるようになります。 - リスクに応じて適切な対応を判断する：
優先順位を決めることは、必ずしもパッチを最優先で適用することを意味するわけではありません。場合によっては、パッチを適用することが最適な対応となります。一方で、正式なパッチが提供されるまでは、デバイスを隔離したり、接続をブロックしたり、外部に公開しているサービスを停止したり、アクセスを制限したり、監視を強化したりするほうが適切な場合もあります。 - リスクが低減されたことを確認する：
チケットをクローズしたり、パッチを適用したりするだけでは十分ではありません。対象資産が脆弱なままになっていないこと、不要なエクスポージャが解消されていること、そして不審なアクティビティが継続していないことを確認することが重要です。
脆弱性の優先順位付けを統合プラットフォームで簡素化する
統合型のセキュリティプラットフォームを利用すれば、サイロ化された複数のツールから得られるデータを手作業で関連付ける必要がなくなり、優先順位付けを簡素化できます。インベントリはある場所で、エンドポイント、ネットワーク、パッチ、アラート、アクセス制御は別の場所で確認する、といった作業は不要になります。各レイヤーのテレメトリを単一の運用フレームワークに集約できるためです。これにより、セキュリティチームや MSP は、どの資産が影響を受けているのか、そのエクスポージャレベルはどの程度なのか、関連する異常なアクティビティがないか、そしてどの脆弱性に直ちに対応する必要があるのかを迅速に把握できます。
さらに、脆弱性の優先順位付けを、対応待ちの脆弱性を並べた静的なリストにしておくのではなく、具体的なリスク低減策につなげることができます。パッチ管理は修正プログラムを特定して適用し、エンドポイントセキュリティは挙動に関するテレメトリと封じ込め機能を提供します。ネットワークの可視性によって、エクスポージャ、不審なトラフィック、管理対象外の資産を検出し、XDR による相関分析によって、個々のツールから得られたばらばらのイベントを、優先度の高いインシデントとして捉えられるようになります。
MSP の場合、このフレームワークに MDR サービスを組み合わせることで、脆弱性の状況、ビジネスへの影響、環境のコンテキストに基づいて、特に重要な資産の監視やトリアージを強化することもできます。その結果、優先順位付けを、単独のアラートや 1 つのスコアだけに頼るのではなく、リスクをより包括的に把握したうえで行えるようになります。これにより MSP は、すべてを社内リソースだけで一から構築することなく、高度な検知と対応機能を顧客に提供できます。このモデルは、ウォッチガードの Rai のように、プラットフォームに標準で組み込まれた AI エージェントによって、さらに強化できます。Rai はバックグラウンドで動作し、統合プラットフォームのテレメトリを活用して、各資産のリスクプロファイルに応じた適切な対応を実行します。
NIST と NVD の最近の変更により、外部のデータベースから得られるコンテキスト情報が限られる中、組織自身がコンテキストを構築することが不可欠になっています。セキュリティチームや MSP は、統合された視点を得ることでノイズを減らし、不要な手作業によるレビューをなくすとともに、それぞれの環境に最も大きな影響を及ぼす脆弱性に注力できるようになります。