【脆弱性管理とは】脆弱性診断・ASMとの違いと「見つけた後」の運用サイクル

脆弱性管理とは？なぜ今、運用の仕組みが問われるのか

脆弱性管理の定義

脆弱性管理とは、自社のIT資産に存在する脆弱性を検出し、危険度を評価して優先順位をつけ、修正と再確認までを継続的に回す運用プロセスです。一度の検査で弱点を洗い出して終わりにするのではなく、新たな脆弱性の発見やシステム環境の変化に合わせて、同じ工程を継続的に繰り返していくことが求められます。

脆弱性診断・ASMとの違いと役割分担

脆弱性診断とASM（Attack Surface Management）が弱点や資産を「見つける」手段であるのに対し、脆弱性管理は見つかった弱点を「継続的に修正し続ける」運用です。

関連記事：脆弱性診断は何を・どこまでやればいい？種類と範囲・頻度の決め方

関連記事：【ASMとは】攻撃対象領域を可視化する3つの型と運用でつまずく理由

公開される脆弱性の急増と「すべては直せない」現実

IPAの脆弱性対策情報データベース（JVN iPedia）に登録された脆弱性は、2025年は四半期ごとに1万件前後で推移し、年間で4万件を超えました。このように、公表された脆弱性をすべて即座に修正することは現実的ではないため、どこから対応すべきか優先順位をつける必要があります。

出典：IPA「脆弱性対策情報データベース JVN iPedia の登録状況」（2025年第1〜第4四半期）を基に作成

https://www.ipa.go.jp/security/reports/vuln/jvn/ipedia2025q4.html

膨大な脆弱性に優先順位をつける考え方

CVSSスコアによる優先順位づけの限界

CVSS（Common Vulnerability Scoring System）は脆弱性の深刻度を0.0から10.0の数値で示す指標です。しかし、その脆弱性が自社のどの資産にあるか、実際に攻撃へ使われているかまでは反映されません。そのため、CVSSスコアの高い順に対応すると、実際には攻撃に利用されていない脆弱性への対応に工数が割かれ、優先すべき脆弱性の対応が遅れることがあります。

リスクベースの評価

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、実際に攻撃へ悪用されたことが確認された脆弱性を、KEV（Known Exploited Vulnerabilities）カタログとして公開しています。掲載された脆弱性は攻撃手法がすでに出回っているため、CVSSスコアだけでなく、実際の悪用状況も考慮して優先的に対応すべき対象と考えられます。

資産の重要度と攻撃の可能性を掛け合わせる判断軸

優先度は、下記の2つの軸を掛け合わせて判断します。同じスコアの脆弱性でも、社内だけで使うサーバーとインターネットに公開されたサーバーとでは、対応の緊急度は変わります。

検出・評価・修正・再確認の運用サイクル

脆弱性管理を構成する4工程

脆弱性管理は、下記の4つの工程で構成されます。

• 検出：資産の棚卸しとスキャンによる脆弱性の洗い出し
• 評価：深刻度・悪用状況・資産の重要度を踏まえた優先順位づけ
• 修正：パッチ適用や設定変更による是正
• 再確認：修正後の再スキャンによる是正結果の確認

パッチ適用と適用できない場合の代替手段

脆弱性対応においては、修正プログラムを適用する「パッチ適用」が最も確実な方法です。しかし、動作検証やシステム停止の調整に時間がかかり、すぐにはパッチを当てられないケースも少なくありません。その場合は、代替手段として以下の2つのアプローチを検討します。

• 緩和策：該当機能の停止やアクセス制限による悪用条件の除去
• 代替コントロール：通信の制限やネットワーク分離による別経路での防御

継続的な運用サイクル

脆弱性は毎日のように新たに公表され、システムの構成変更によっても新しい弱点が生まれます。スキャンと結果確認を定例業務に組み込み、緊急度の高い脆弱性が出た場合の対応手順を決めておくと、サイクルが止まりにくくなります。

【状況別】自社の脆弱性管理はどこでつまずくか

脆弱性管理が止まる原因は企業によって異なり、最初に着手すべきことも変わります。

どこに何があるか把握できていない

管理台帳に載っていないサーバーやクラウド上の環境は、スキャンの対象に含まれず、脆弱性があっても検出されないまま残ります。部門が独自に契約したサービスや、稼働状況を確認していない検証環境まで含めて洗い出すことが、脆弱性管理を始める前提になります。

優先順位が定まらない

検出結果が数千件単位になると、どれも危険に見えて着手の判断がつかず、報告書が読まれないまま停滞します。対応する脆弱性と当面見送る脆弱性を分ける基準をあらかじめ決めておけば、件数が増えても運用は止まりません。

停止を恐れてパッチを見送っている

基幹システムでは、パッチ適用に伴う再起動や不具合が業務に直結するため、適用が繰り返し先送りされます。先送りそのものは判断の一つですが、放置と区別するために、いつまでに何を確認して適用するかを記録に残し、リスクを管理した状態を維持することが重要です。

兼任・人手不足で続かない

担当者が他の業務と兼任している場合、脆弱性情報の収集や修正後の再確認は後回しになり、サイクルが数か月単位で空くことがあります。判断が必要な作業を減らすため、スキャンの実行や報告の形式を定型化し、担当者が変わっても同じ手順で回せるようにしておくことが有効です。

「直す」だけでは守り切れない領域と検知・対応

既知の穴を塞ぐ「静的な防御」の限界

修正プログラムが公開されていないゼロデイ脆弱性や、正規の認証情報を使った侵入は、既知の脆弱性を塞ぐ取り組みではブロックできません。脆弱性管理を徹底しても、侵入後の動きを捉える仕組みがなければ、被害が広がるまで気づけないことも少なくありません。そのため、侵害を前提とした監視や検知の仕組みも必要になります。

EDRとの役割分担と運用負荷

脆弱性管理が既知の弱点を事前に塞ぐ「静的な防御」であるのに対し、EDR（Endpoint Detection and Response）は端末上の不審な動きをリアルタイムに検知する「動的な防御」です。ただし、EDRは導入すれば完結するものではなく、下記のような運用が日々発生します。

• 検知アラートの確認と、誤検知かどうかの切り分け
• 不審な端末の隔離と影響範囲の調査
• 検知ルールや除外設定の見直し

関連記事：今さら聞けない「EDR」とは？基本的な役割と導入後の運用課題をわかりやすく解説

検知から対応まで担うMDRという選択

このようなEDR運用における「人手不足」や「専門スキルの壁」を乗り越えるための解決策が、MDR（Managed Detection and Response）です。セキュリティの専門アナリストが24時間体制で監視し、脅威の検知から初動対応までを代行します。MDRを活用すれば、静的な防御では防ぎきれない領域を外部の専門体制でカバーすることが可能になります。

まとめ：脆弱性管理は「直して終わり」ではなく優先順位をつけて回し続ける運用

現代のセキュリティ運用において、脆弱性管理は単なるパッチ適用作業ではなく、リスクに応じた優先順位付けと、継続的なサイクルを回すマネジメントのプロセスです。CVSSスコアに加え「実際の悪用状況」を加味した優先順位づけを行い、検出・評価・修正・再確認というプロセスを「線」の運用として定着させることが不可欠です。

さらに、脆弱性管理という「静的な防御」だけでは未知のサイバー攻撃を完全に阻むことはできません。EDRやMDRといった「動的な防御（検知・対応）」を組み合わせ、多層的なアプローチで自社のシステムを堅守する体制を構築しましょう。