脆弱性管理（VM）とは？脆弱性診断との違い
「脆弱性診断を実施した」「スキャナーを導入した」という企業が増える一方で、発見した脆弱性を継続的に追跡・修正する仕組みが整っていないケースは多い。脆弱性管理（Vulnerability Management、以下VM）とは、組織のIT資産に存在する脆弱性を継続的に発見・評価・修正・検証するサイクル全体を指す概念であり、一度きりのスキャンや診断とは根本的に異なる。
脆弱性診断とVMの違い
観点 | 脆弱性診断（単発） | 脆弱性管理（継続） |
|---|---|---|
実施頻度 | 年1〜2回、要件対応時のみ | 継続的（週次・月次スキャン） |
スコープ | 対象を限定して深掘り | 全資産を広くカバー |
成果物 | 報告書（スナップショット） | ダッシュボード・トレンド推移 |
主な目的 | 現時点のリスク把握 | リスクの継続的低減 |
担当者 | セキュリティ専門家（外部含む） | 内部チーム＋ツールで運用 |
脆弱性診断は「今この瞬間」の状態を深く把握するための手段であり、VMは「常に安全な状態を維持する」ための継続プロセスである。両者は補完関係にあり、VMサイクルの中に定期的な精密診断を組み込む形が理想的だ。
2026年現在、クラウドネイティブ環境・コンテナ・IaCの普及により、管理対象資産は動的に変化し続けている。スキャン間隔が週次であっても、新たにデプロイされたインスタンスやコンテナイメージに未知の脆弱性が混入するリスクは常に存在する。VMはこの変化の速さに追随するための運用フレームワークとして、多くの企業でセキュリティプログラムの中核に位置づけられている。
脆弱性管理のサイクル（発見→評価→優先順位→修正→検証→報告）
VMは6つのフェーズで構成されるサイクルとして捉えると設計しやすい。
フェーズ1：資産の可視化（Asset Discovery）
管理できないものは守れない。VMの出発点は「何があるか」を把握することだ。物理サーバー・仮想マシン・クラウドインスタンス・コンテナ・ネットワーク機器・エンドポイント・IoTデバイスまで、スコープを定義したうえで資産台帳と連携させる。CMDBや構成管理ツールと統合することで、スキャン対象の漏れを防ぐ。
フェーズ2：脆弱性スキャン（Scanning）
認証スキャン（エージェントベースまたは認証情報を使ったリモートスキャン）と非認証スキャンを用途に応じて使い分ける。エージェントレスのネットワークスキャンはカバレッジが広い反面、OSレベルの設定ミスや内部の細かいパッチ状態を把握しにくい。エージェントベースのスキャンは精度が高く、オフラインのエンドポイントにも対応できる。
スキャン頻度の目安は以下のとおり。
- インターネット公開資産：週次以上
- 内部サーバー・重要システム：月次以上
- エンドポイント（PC等）：エージェントによる常時収集
- クラウドワークロード：CI/CDパイプラインへの組み込みを推奨
フェーズ3：評価と優先順位付け（Assessment & Prioritization）
スキャン結果には数百〜数千件の脆弱性が含まれることが多い。すべてを同列に扱っていては修正が追いつかない。評価の詳細は次章で解説する。
フェーズ4：修正（Remediation）
パッチ適用が最も一般的な修正手段だが、パッチが存在しない場合や適用にシステム停止が必要な場合は、以下の代替手段（ワークアラウンド）を検討する。
- WAFルールやIDS/IPSシグネチャによる攻撃ブロック
- ネットワーク分離・アクセス制御の強化
- 脆弱なサービス・機能の無効化
- 設定変更（デフォルト資格情報の変更、不要ポートのクローズ等）
修正作業はIT運用チームとの連携が必須であり、変更管理プロセス（Change Management）に沿った実施が求められる。
フェーズ5：修正の検証（Verification）
パッチ適用後は、再スキャンまたは手動確認により修正が完了したことを証明する。「適用済み」と記録されていても実際には適用されていなかったというケースは珍しくない。特にCritical脆弱性については、修正後24〜48時間以内に再スキャンを実施することを推奨する。
フェーズ6：報告とメトリクス（Reporting & Metrics）
VMの成熟度は「脆弱性を発見する能力」ではなく「修正完了率と修正速度（Mean Time to Remediate：MTTR）」で評価される。経営層向けにはリスク低減のトレンドを、技術チーム向けには未修正件数と優先度別の内訳を報告する体制を整える。
優先順位の付け方（CVSS単独の限界・EPSSとKEVの活用）
CVSSスコアだけでは不十分な理由
CVSS（Common Vulnerability Scoring System）はNVDをはじめとする脆弱性データベースで広く使われるスコアリング指標であり、脆弱性の深刻度を0〜10の数値で表す。しかしCVSS単独で優先順位を付けると以下の問題が生じる。
- Critical（9.0以上）が大量に検出される：CVSSはあくまで「最悪シナリオでの深刻度」を示すため、実環境で実際に悪用されるかどうかは考慮されていない。
- 環境要因が無視される：インターネット公開資産と内部ネットワーク深部にある同じ脆弱性を同等に扱ってしまう。
- 攻撃者の動向が反映されない：CVSSスコアが低くても実際に多くの攻撃者に悪用されているケースがある。
EPSS（Exploit Prediction Scoring System）
EPSSはFIRSTが提供する指標で、「今後30日以内にこの脆弱性が野外で悪用される確率」を0〜1の値で示す。機械学習モデルをベースとし、脅威インテリジェンス・Exploitコードの公開状況・SNS上の言及などを組み合わせて算出される。
EPSSが0.9以上の脆弱性はCVSSスコアに関わらず緊急対応の候補となる。逆にCVSS 9.5であってもEPSSが0.01未満であれば、実際の悪用リスクは極めて低いと判断できる。
KEV（Known Exploited Vulnerabilities）カタログ
CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が管理するKEVカタログは、実際に野外で悪用が確認されたCVEの一覧である。米国連邦政府機関への適用義務があるが、民間企業にとっても「今すぐ攻撃者に使われている脆弱性」を把握するための実践的リストとして機能する。
KEVに掲載された脆弱性は、CVSSスコアや自社環境への影響度に関わらず、最優先での修正を原則とする。
優先順位付けフレームワーク（推奨）
以下のマトリクスを活用することで、限られたリソースを最も効果的な修正に集中できる。
優先度 | 条件 | 推奨対応期限 |
|---|---|---|
P0（緊急） | KEV掲載 かつ 自社資産に存在 | 24〜72時間以内 |
P1（Critical） | CVSS 9.0以上 かつ EPSS 0.5以上 | 7日以内 |
P2（High） | CVSS 7.0〜8.9 かつ EPSS 0.1以上、またはインターネット公開資産 | 30日以内 |
P3（Medium） | CVSS 4.0〜6.9 かつ 内部資産 | 90日以内 |
P4（Low） | CVSS 3.9以下 かつ EPSS 0.01未満 | 計画的対応（次回メンテナンス等） |
この優先度はあくまで基準であり、自社のビジネス文脈（対象資産が何を処理しているか、規制要件の有無）によって調整する必要がある。たとえば個人情報や決済情報を扱うシステムに存在するMediumの脆弱性は、他のHighより先に対応すべき場合もある。
パッチ管理SLAの設計（Critical/High/Medium別対応期限）
SLA（Service Level Agreement）を設定することで、脆弱性修正の「努力目標」を「測定可能なコミットメント」に変える。SLAなしのVM運用は、形式的なスキャン実施に終わりがちであり、実際のリスク低減につながらない。
SLA設計の基本原則
1. 深刻度別の期限設定
深刻度 | CVSS目安 | 標準SLA | インターネット公開資産 |
|---|---|---|---|
Critical | 9.0〜10.0 | 14日以内 | 7日以内 |
High | 7.0〜8.9 | 30日以内 | 14日以内 |
Medium | 4.0〜6.9 | 90日以内 | 30日以内 |
Low | 0.1〜3.9 | 180日以内または計画対応 | 90日以内 |
Informational | 0.0 | 次回レビュー時に検討 | 次回レビュー時に検討 |
2. 例外処理（リスク受容）プロセス
パッチ適用が技術的に困難または事業上の制約から不可能な場合は、リスク受容（Risk Acceptance）プロセスを設ける。具体的には以下の要素を文書化したうえで、CISO等の承認を得る。
- 修正できない理由（ベンダーサポート終了、システム停止不可等）
- 代替的な緩和策の内容
- リスク受容の有効期限（最長でも90日ごとに再評価）
- 承認者の署名
リスク受容を無期限に放置することは、実質的なリスクの隠蔽につながる。有効期限と定期レビューの義務化がガバナンスの要である。
3. KPIによる進捗管理
- 脆弱性修正率（SLA内に修正完了した件数の割合）：目標80%以上
- MTTR（Mean Time to Remediate）：Critical脆弱性で10日以内を目標
- 再発率（修正済みとして記録されたが再スキャンで同じCVEが検出された件数）
- 脆弱性残存期間の分布（30日・60日・90日超の件数推移）
主要VMツール比較（Tenable・Qualys・Rapid7など）
VMプラットフォームは多数存在するが、エンタープライズ向けの主要製品の特徴を以下に整理する。
主要VMツール比較表
ツール | 主な強み | スキャン方式 | クラウド対応 | 価格帯（目安） | 向いている組織 |
|---|---|---|---|---|---|
Tenable Vulnerability Management（旧Tenable.io） | 広範な資産対応・Nessusエンジンの信頼性 | エージェント＋リモート | AWS/Azure/GCP統合 | 中〜大規模向け | オンプレとクラウドの混在環境 |
Tenable Security Center（旧SecurityCenter） | オンプレ完結・コンプライアンス管理 | エージェント＋リモート | 限定的 | 中〜大規模向け | データ持ち出し制限のある組織 |
Qualys VMDR | CMDB統合・ワークフロー自動化 | エージェント＋リモート | マルチクラウド | 中〜大規模向け | IT資産管理と脆弱性管理を一元化したい組織 |
Rapid7 InsightVM | 攻撃者視点のリスクスコア・可視化 | エージェント＋リモート | AWS/Azure/GCP | 中〜大規模向け | リスクベースの優先順位付けを重視する組織 |
Microsoft Defender 脆弱性の管理 | Microsoft 365/Intune統合 | エージェント（MDE） | Azure中心 | E5ライセンスに含む | Microsoft環境が中心の組織 |
Wiz（クラウドネイティブ） | エージェントレス・コンテナ/IaC対応 | エージェントレス | マルチクラウド | クラウド規模依存 | クラウドネイティブ・コンテナ環境 |
Trivy（OSS） | コンテナイメージ・IaC・SBOMスキャン | CI/CD組み込み | CI/CDパイプライン | 無料（OSS） | DevSecOps実践中の開発組織 |
ツール選定のポイント
資産の種類で絞り込む
- オンプレ中心：Tenable Security Center、Qualys VMDR
- クラウドネイティブ：Wiz、Orca Security、Prisma Cloud
- Microsoft環境：Microsoft Defender 脆弱性の管理
- コンテナ・CI/CD重視：Trivy（OSS）＋SCAツールの組み合わせ
運用体制で絞り込む
少人数でのVM運用には、ダッシュボードとレポートが充実した SaaSベースのプラットフォームが適している。Tenable Vulnerability ManagementやQualys VMDRはウィザード形式のスキャン設定と豊富なコンプライアンステンプレートを備えており、VMを初めて本格導入する組織でも比較的立ち上げやすい。
コスト構造の確認
多くのエンタープライズVMツールは管理対象資産数（IP数・エンドポイント数）に応じた課金モデルを採用している。資産数が急増するクラウド環境では、コストが予想以上に膨らむケースがある。クラウドワークロードについては、エージェントレスでワークロード単位の課金が可能なツール（Wiz等）との組み合わせも検討に値する。
組織に脆弱性管理を定着させる方法
ツールを導入しただけではVMは機能しない。運用定着のために取り組むべき課題を以下に整理する。
1. 責任分担の明確化（RACI）
脆弱性管理が失敗する最大の原因のひとつは「誰が修正するのか」が不明確なことだ。セキュリティチームはスキャンと優先順位付けを担うが、実際のパッチ適用はITインフラチームや開発チームが行う。双方の役割をRACIマトリクスで明文化し、経営層の承認を得ることで修正対応の遅延を防ぐ。
役割 | セキュリティチーム | ITインフラ/SRE | 開発チーム | CISO |
|---|---|---|---|---|
スキャン実施 | 実施（R） | 協力（C） | 協力（C） | 承認（A） |
優先順位付け | 実施（R） | 情報提供（I） | 情報提供（I） | 承認（A） |
パッチ適用（インフラ） | 確認（C） | 実施（R） | — | — |
パッチ適用（アプリ） | 確認（C） | — | 実施（R） | — |
リスク受容の承認 | 提案（R） | — | — | 承認（A） |
2. 修正フローとチケット管理の統合
脆弱性管理ツールとJira・ServiceNow・Azure DevOpsなどのチケット管理システムをAPI連携させることで、修正タスクの自動起票・進捗追跡・SLA管理を一元化できる。手動でのスプレッドシート管理は抜け漏れが生じやすく、大規模環境では現実的ではない。
Tenable VMやQualys VMDRはJiraや ServiceNowへのネイティブ連携機能を備えており、優先度付きのチケットを自動生成する設定が可能だ。
3. 開発プロセスへの組み込み（Shift Left）
Webアプリケーションやクラウドインフラを内製している組織では、本番環境でのVM実施だけでなく、CI/CDパイプライン内でのSCA（Software Composition Analysis）・SAST・コンテナイメージスキャンを導入することで、脆弱性の「作り込みを防ぐ」仕組みを構築できる。
本番で検出してから修正するコストと、開発段階で検出して修正するコストには大きな差がある。Shift Leftはコスト効率の面でもVMの成熟度向上において重要な取り組みだ。
4. 定期レビューとエスカレーション基準
月次または四半期ごとにVMの進捗レビューを経営層向けに実施する。報告内容には数値（MTTR・修正率・残存Critical件数）だけでなく、対応できていない理由とその対策も含める。数字を見せるだけでなく「なぜ改善が進んでいないか」を説明できる体制がないと、レビューが形骸化する。
エスカレーション基準として、以下のような条件をあらかじめ設定しておく。
- SLA期限を過ぎたCritical脆弱性が3件以上：CISO通知
- KEV掲載脆弱性が72時間以内に未修正：インシデント対応プロセスに移行
- 修正率が2ヶ月連続で60%を下回る：VM運用改善の緊急レビュー
5. 成熟度モデルを活用した段階的改善
VMを一度に完璧に運用しようとすると挫折しやすい。以下のような段階的な成熟度モデルを参考に、現状を客観的に評価し次のステップを設定する。
レベル | 状態 | 主な取り組み |
|---|---|---|
Lv.1 初期 | スキャンが散発的・結果が共有されない | 定期スキャンの定常化・報告フローの確立 |
Lv.2 管理 | スキャンは定期実施・修正対応は個人依存 | SLA設定・チケット管理との連携 |
Lv.3 定義 | プロセスが文書化・部門横断の連携あり | RACI整備・KPI測定・優先順位付けの標準化 |
Lv.4 定量 | MTTRが測定され目標値がある | 自動化の推進・リスクベース優先順位付けの実装 |
Lv.5 最適化 | 継続的改善・Shift Left実装・経営指標との連動 | EPSS/KEV活用・DevSecOps統合・脅威インテリジェンス連携 |
多くの国内企業はLv.1〜Lv.2の段階にある。まずLv.2〜Lv.3への移行を目指し、プロセスの文書化とSLAの設定から着手することが現実的だ。
AEVUSの脆弱性管理支援・定期診断
脆弱性管理プログラムの構築は、ツールの選定と導入だけでは完結しない。運用設計・プロセス定義・組織への定着支援まで含めたトータルサポートが必要だ。
AEVUSでは以下の支援を提供している。
VMプログラム設計支援
組織の現状（資産規模・既存ツール・運用体制）をアセスメントし、実行可能なVMプロセスとSLAを設計する。導入するツールの選定から運用手順書の策定まで一貫して対応する。
定期脆弱性診断（外部からの視点）
VMツールによる継続スキャンは内部からの視点が中心だ。これに加えて、外部のセキュリティ専門家による定期的なペネトレーションテスト・脆弱性診断を組み合わせることで、自動スキャンでは検出しにくいロジック上の問題や設定不備を補完できる。
CVSS/EPSS/KEVを活用した優先順位付けコンサルティング
大量の脆弱性を抱えた状態から「何から手をつけるか」を整理するための優先順位付け支援も提供する。スキャン結果データをもとに、自社環境に即した修正ロードマップを作成する。
脆弱性管理の強化に関心がある場合は、AEVUSのサービスページから詳細を確認するか、無料相談フォームよりお問い合わせを。
