脆弱性管理|ツール・選び方・優先順位付け・運用・事例

投稿日時: 更新日時:

脆弱性管理は、企業が保有するIT資産を把握し、OSやソフトウェア、ネットワーク機器、クラウド環境などに存在する脆弱性を検出・評価して、対応の優先順位付けから修正状況の確認まで継続的に管理する取り組みです。

脆弱性対応では、CVEを一覧化したり、CVSSスコアが高い順にパッチを適用したりするだけでは十分とは限りません。実際の攻撃で悪用されているか、インターネットから到達できる資産か、侵害された場合にどこまで重要システムへ到達できるか、業務影響が大きいかなどを組み合わせて判断する必要があります。

実際、2026年に公表されたデジタル庁のガバメントソリューションサービス(GSS)への不正アクセスでは、VPN機器の脆弱性が侵入経路となりました。その後の追加情報では、悪用された脆弱性の当初のCVSS評価が「Medium」だったことも明らかになっています。CVSSだけでは組織にとっての実質的なリスクを十分に表せないことを考えるうえで重要な事例です。

このページでは、脆弱性管理の基本から、実際に悪用された脆弱性の事例、脆弱性管理ツールの比較・選び方、CVSS・KEV・EPSSなどを使った優先順位付け、脆弱性診断やASM、SBOMとの違い、パッチをすぐに適用できない場合の考え方までまとめて紹介します。

脆弱性管理とは

脆弱性管理とは、企業が保有するIT資産の脆弱性を継続的に把握し、組織へのリスクを評価して優先順位を付け、修正・緩和・再確認まで管理する取り組みです。

一般的には、次のような流れで進めます。

資産把握 → 脆弱性検出 → リスク評価 → 優先順位付け → 修正・緩和 → 再確認

脆弱性診断を実施して問題を発見しただけでは、脆弱性管理は完了しません。どの資産が影響を受けるのか、誰が対応するのか、いつまでに修正するのか、修正できない場合にどのような緩和策を取るのかまで追跡する必要があります。

管理対象には、サーバー、PC、ネットワーク機器、VPN、Webアプリケーション、クラウド、SaaS、OSS・ライブラリ、コンテナ、ファームウェア、インターネット公開資産などがあります。

脆弱性管理の基本プロセスや、脆弱性診断・パッチ管理との違いについては、脆弱性管理とは?脆弱性診断・パッチ管理との違い、優先順位付けと運用プロセスを解説で詳しく紹介しています。

なぜ企業に脆弱性管理が必要なのか

企業が対応しなければならない脆弱性は、単純に「Criticalだけ対応する」という運用では処理しきれない規模になっています。

Microsoftは2026年7月の定例セキュリティ更新で569件の脆弱性を修正しました。Criticalは56件でしたが、それとは別に、AD FSのCVE-2026-56155とSharePoint ServerのCVE-2026-56164は更新プログラム公開前から実際の攻撃で悪用されていました。

特にSharePoint ServerのCVE-2026-56164はCVSS 5.3で、深刻度の数字だけを見れば最優先に見えない脆弱性でした。しかし、実際には攻撃で悪用されていました。

詳細は、Microsoft、2026年7月定例パッチで史上最多569件の脆弱性を修正-AD FSとSharePointの2件がゼロデイ攻撃で悪用済みで整理しています。

Oracleでも2026年7月のCritical Patch Updateで1,449件の新規セキュリティパッチが公開され、334製品にまたがる1,434件の固有CVEが対象となりました。大量の脆弱性が一度に公表される状況では、すべてを同時に処理するのではなく、自社が利用している製品、資産の公開状況、実際の悪用状況、業務への影響を組み合わせて対応順序を決める必要があります。

詳しくは、Oracle、四半期セキュリティ更新(2026年7月CPU)で1,449件のパッチを公開をご覧ください。

さらに、脆弱性の公開から実際の悪用までの時間が短いケースもあります。

Palo Alto NetworksのPAN-OSに存在したGlobalProtect認証回避脆弱性CVE-2026-0257では、公開からわずか4日後に実際の悪用が観測されました。その後、この脆弱性がQilinランサムウェアによる侵入にも悪用され、境界のファイアウォールからドメイン全域の暗号化にまで到達した事例も報告されています。

Citrix NetScaler ADC/GatewayのCVE-2026-8451では、公式アドバイザリと検知ツールの公開から24時間以内に実際の悪用が観測されました。

詳しくは、新たなCitrix Bleed系脆弱性、公開から24時間以内に悪用開始-CVE-2026-8451で紹介しています。

こうした事例を見ると、脆弱性管理では「重大な脆弱性が公表されたら担当者がニュースを見つけて対応する」という運用だけでは間に合わない可能性があります。

資産と製品バージョンをあらかじめ把握し、新しい脆弱性情報と継続的に照合しながら、実悪用や資産の重要度を踏まえて対応対象を絞り込める体制が必要です。

デジタル庁GSSへの不正アクセスから見る脆弱性管理の課題

2026年9月11日、デジタル庁はガバメントソリューションサービス(GSS)への不正アクセスにより、職員や業務関係者の個人情報を含むファイルの一部が外部へ漏えいした可能性があると公表しました。

セキュリティ対策Labでは、公表当日に事案の時系列、侵入経路、漏えい対象、初動対応を整理しています。

デジタル庁 GSSへの不正アクセス、VPN脆弱性を悪用 職員等約24.6万件の個人情報漏えいの可能性

最初に確認された異常は2026年6月25日でした。GSSの保守運用担当者のアカウントを利用し、サーバー上の大量のファイルへアクセスする動きが検知され、調査が開始されました。

その後、7月9日に第三者がネットワーク接続機器であるVPNの脆弱性を利用してシステムへ侵入していたことが判明しました。同日、不正アクセスに利用された保守運用担当者のアカウントが停止され、侵害された機器と外部との通信も遮断されています。公表資料では、VPNへのパッチ適用も初動対応として示されています。

外部専門事業者と調査を進めた結果、GSS上で取り扱っていた個人情報を含むファイルの一部について、外部へ漏えいした可能性があることが確認されました。

漏えいした可能性がある個人情報は約24.6万件です。

項目 内容
公表日 2026年9月11日
最初の異常検知 2026年6月25日
侵入経路判明 2026年7月9日
侵入経路 VPN機器の脆弱性
漏えいした可能性がある個人情報 約24.6万件
氏名 約23.6万件
メールアドレス 約23.1万件
電話番号 約9.4万件
住所 約0.1万件
初動対応 VPNへのパッチ適用、対象アカウント停止、侵害機器と外部との通信遮断など
再発防止 脆弱性管理方法の見直し、外部からの接続方法の改善など

一方、VPN機器のメーカーや製品名、CVE番号は公表されていません。また、悪用された脆弱性が侵入前から公開されていた既知脆弱性だったのか、侵入時点ですでに修正版が提供されていたのかについても公表情報からは確認できません。

そのため、本件を「既知のVPN脆弱性を長期間放置したことが原因」と断定することはできません。

この事案について、セキュリティ対策Labでは追加情報を踏まえ、VPNからの侵入だけではなく、侵入後に保守運用担当者のアカウントを利用して大量のファイルへアクセスされた点についても分析しています。

デジタル庁GSSへの不正アクセス、問題は「侵入されたこと」だけではない 保守運用アカウントの権限とゼロトラスト設計を検証

追加情報では、攻撃に悪用されたVPN機器の脆弱性について、当初公表されていたCVSS評価が「Medium」だったことも明らかになっています。

この点は、脆弱性管理を考えるうえで重要です。

CVSSは脆弱性そのものの技術的な深刻度を比較するための有用な指標ですが、組織にとっての実質的なリスクを単独で表すものではありません。

例えばVPNやファイアウォールなどの境界機器は、CVSSがMediumであっても、

  • インターネットから直接到達できる
  • 社内ネットワークへの入口になる
  • 認証基盤や管理系ネットワークへ接続している
  • 侵害後に重要な権限を取得できる
  • 多数の利用者やシステムへ影響する

といった条件によって、組織にとっての対応優先度が高くなる場合があります。

また、GSSではVPNから侵入した後、保守運用担当者のアカウントを利用して大量のファイルへアクセスする動きが検知されています。

そのため脆弱性管理では、単に「パッチを適用したか」だけではなく、脆弱だった期間にすでに侵害されていないかを確認することも重要です。

GSS事例から脆弱性管理で確認したいポイントを整理すると、次のようになります。

観点 GSS事例から考えられるポイント
CVSS Mediumでも実際の侵入に悪用される場合がある
資産の露出 VPNなど外部公開された境界機器は優先度が高くなり得る
資産の役割 外部から内部システムへ接続する入口となる機器は影響が大きい
侵入後の権限 保守運用アカウントなど高権限アカウントまで考慮する
検知 大量ファイルアクセスなど侵入後の挙動も監視する
パッチ後の確認 修正しただけでなく、すでに侵害されていないか確認する
再発防止 脆弱性管理を単純なパッチ適用から実質的なリスク管理へ広げる

つまり、脆弱性管理では「CVSSが何点か」だけではなく、

どの資産に存在するか → 外部から到達できるか → 実際に悪用されているか → 侵害後にどの権限や情報へ到達できるか

まで確認する必要があります。

実際に悪用された脆弱性から見る優先順位付けの必要性

セキュリティ対策Labで継続的に追跡している脆弱性を見ても、「CVSSが高いものから順番に対応する」だけでは十分ではありません。

事例 状況 脆弱性管理で見るポイント
デジタル庁GSS 当初CVSS MediumだったVPN脆弱性が侵入経路 外部公開、資産の役割、侵入後の権限
Microsoft 2026年7月 569件修正。SharePointのCVSS 5.3を含む2件は悪用済み 大量CVEから実悪用を優先
PAN-OS CVE-2026-0257 公開4日後に悪用、その後Qilinランサムウェアでも利用 境界機器、悪用速度、事業影響
Citrix CVE-2026-8451 公開から24時間以内に悪用 境界機器、即時対応
FortiOS CVE-2025-25249 修正済み脆弱性が後から実攻撃に悪用 未更新資産、侵害痕跡確認
Defender CVE-2026-33825 ランサムウェアキャンペーンで悪用 KEV、ランサムウェアとの関連

FortiOS/FortiSwitchManagerのCVE-2025-25249は、すでに修正版が提供されていた脆弱性でしたが、2026年に実際の攻撃で悪用され、CISA KEVにも追加されました。

対象環境では「パッチが出ているか」だけではなく、どの資産が未更新なのか、外部から到達できるのか、すでに侵害の痕跡がないかまで確認する必要があります。

詳しくは、FortiOSの修正済み脆弱性CVE-2025-25249がサイバー攻撃に悪用、PivotC2を展開 CISA KEVに追加で紹介しています。

Microsoft DefenderのCVE-2026-33825「BlueHammer」はCVSS 7.8でしたが、ランサムウェアキャンペーンでの悪用が確認されています。

Microsoft Defenderの脆弱性BlueHammer(CVE-2026-33825)がランサムウェア攻撃に悪用

このような事例から、企業の脆弱性管理では、

脆弱性の技術的な深刻度 × 実悪用 × 資産の露出 × 資産の重要度 × 業務影響

を組み合わせて対応優先順位を決める必要があります。

CVSSだけで対応の優先順位を決めない

CVSSは、脆弱性そのものの技術的な深刻度を比較するための重要な指標です。

一方、組織にとってのリスクはCVSSだけでは決まりません。

例えば、

CVSS 9.8だが、外部から到達できず、限定されたネットワーク内に存在するシステム

と、

CVSS 6~7台だが、インターネットへ直接公開され、VPNや認証の入口になっている機器

では、後者を先に対応すべきケースがあります。

脆弱性管理では、次のような情報を組み合わせて優先順位を決めます。

判断材料 確認する内容
CVSS 脆弱性そのものの技術的な深刻度
CISA KEV 実際の攻撃で悪用が確認されているか
EPSS 悪用可能性を判断するための補助情報
ベンダー情報 悪用確認、PoC、回避策、パッチの有無
インターネット公開 外部から直接到達できるか
資産の役割 VPN、IdP、AD、バックアップなど重要なシステムか
権限 悪用された場合に取得できる権限
到達範囲 侵害後に重要システムへ移動できるか
業務影響 停止や情報漏えいが事業へ与える影響

こうした優先順位付けを、多数の資産へ継続的に適用するために脆弱性管理ツールが利用されます。

脆弱性管理ツールで確認すべき項目

脆弱性管理ツールでは、単に「何件の脆弱性を検出できるか」だけではなく、資産の把握から修正確認までを一連の運用として管理できるかを確認することが重要です。

確認項目 確認する内容
IT資産の把握 サーバー、端末、ネットワーク機器、クラウド、コンテナ、OSSなどを把握できるか
脆弱性の検出 CVE、設定不備、未適用パッチなどを検出できるか
優先順位付け CVSSだけでなく、KEV、実悪用情報、外部公開状況、資産重要度などを考慮できるか
担当者・期限管理 修正担当者、対応期限、ステータスを管理できるか
修正・緩和 パッチ適用、設定変更、隔離、暫定防御などの対応へつなげられるか
再確認 修正後の再スキャンや構成情報更新によって対応完了を確認できるか
例外管理 すぐに修正できない脆弱性やリスク受容を期限付きで管理できるか
外部システム連携 ITSM、CMDB、SIEM、EDR、クラウド、SBOMなどと連携できるか

特に資産数が多い企業では、「どの脆弱性が存在するか」よりも、どの資産に存在し、誰がいつまでに対応するのかを継続して追跡できることが重要になります。

脆弱性管理ツールの比較・選び方

脆弱性管理ツールを比較する際は、搭載している脆弱性データベースや検出件数だけではなく、自社のIT資産と運用プロセスに合っているかを確認します。

企業内には、Windows・Linuxサーバー、VPNやファイアウォールなどのネットワーク機器、AWS・Azureなどのクラウド、コンテナ、OSS、Webアプリケーション、開発環境など異なる種類の資産が存在します。

1つの製品ですべてを管理する方法もあれば、脆弱性スキャナー、SCA、ASM、クラウドセキュリティ製品など複数の結果を脆弱性管理基盤へ集約する方法もあります。

また、検出後に「誰が、いつまでに、何を修正するのか」を管理できなければ、脆弱性を発見しても対応が進まない可能性があります。

実悪用情報やKEV、EPSSなどを優先順位へ反映できるか、修正担当者や期限を管理できるか、再スキャンによって修正を確認できるかも重要な比較項目です。

具体的な製品と比較項目については、脆弱性管理 ツール 比較6選|NCSC・CISAの公的基準から機能・優先順位付け・選び方を解説で詳しく紹介しています。

脆弱性管理と脆弱性診断の違い

脆弱性診断は、Webアプリケーション、サーバー、ネットワーク機器、クラウド環境などに存在する脆弱性や設定不備を発見するための取り組みです。

一方、脆弱性管理は、診断などで発見された問題を自社の資産と紐付け、優先順位を決め、修正・緩和・再確認まで継続して追跡します。

つまり、脆弱性診断は「弱点を見つける」役割、脆弱性管理は「見つけた弱点を対応完了まで管理する」役割として整理できます。

脆弱性診断の種類や実施頻度については、脆弱性診断とは?目的や種類、実施頻度をUS・UK公的機関の推奨から解説で詳しく解説しています。

自動診断ツールの種類や製品選定については、脆弱性診断ツールとは?種類・自動診断と手動診断の違い・企業での選び方もあわせてご覧ください。

ASMと脆弱性管理

ASM(Attack Surface Management)は、主にインターネットから確認できる自社のIT資産を継続的に発見し、攻撃者から見える攻撃面を把握するための取り組みです。

脆弱性管理では、ASMで発見した外部公開資産だけでなく、社内サーバー、PC、ネットワーク機器、クラウド、アプリケーション、OSSなども管理対象になります。

例えば、

ASMで未把握の公開サーバーを発見 → 脆弱性や設定不備を確認 → 脆弱性管理プロセスへ登録 → 担当者・期限を決定 → 修正後に再確認

という形で連携できます。

ASMの仕組みや脆弱性診断との違いについては、ASM(アタックサーフェスマネジメント)とは 専門家が解説で紹介しています。

SBOM・SCAと脆弱性管理

自社で開発・提供するソフトウェアでは、OSやサーバーだけではなく、OSS・ライブラリ・依存関係に含まれる脆弱性も把握する必要があります。

SBOM(Software Bill of Materials)は、ソフトウェアを構成するコンポーネントや依存関係を一覧化するための情報です。

SBOMを作成するだけで脆弱性対応が完了するわけではありません。新たなCVEが公表された際にSBOMと照合し、自社製品への影響を判断し、修正や更新まで追跡することで脆弱性管理につながります。

SBOMの基本については、SBOMとは?必要性・記載項目を解説をご覧ください。

関連製品については、SBOM ツール 比較6選|CISA・NIST・NCSCの公的要件から機能・選び方を解説で比較しています。

ペネトレーションテストと脆弱性管理

脆弱性管理では、多数の資産や脆弱性を継続的に把握して対応します。

一方、脆弱性が実際に悪用された場合にどこまで侵入できるか、どのような攻撃経路で重要資産へ到達できるかを確認したい場合は、ペネトレーションテストが選択肢になります。

脆弱性診断が「どこに弱点があるか」を広く確認するのに対し、ペネトレーションテストでは攻撃者の視点から侵入、権限拡大、横展開、重要資産への到達などを検証します。

両者は代替関係ではなく、継続的な脆弱性管理を行ったうえで、重要システムや特定の攻撃経路について防御の有効性を確認するためにペネトレーションテストを利用できます。

詳しくは、ペネトレーションテストと脆弱性診断の違い|目的・手法・頻度・使い分けを比較で整理しています。

パッチをすぐに適用できない脆弱性への対応

脆弱性が見つかっても、すべてのシステムへ即座にパッチを適用できるとは限りません。

業務システムでは、修正版による影響確認や動作検証が必要になる場合があります。また、ゼロデイ脆弱性では修正プログラム自体がまだ提供されていないこともあります。

このような場合は、パッチ提供を待つだけではなく、

  • 外部公開の停止・制限
  • 不要サービスや機能の無効化
  • アクセス制御
  • WAF・IPS等による緩和
  • EDRによる監視
  • ベンダーが示す回避策
  • 仮想パッチ・パッチレス保護

など、利用可能な暫定対策を検討します。

重要なのは、暫定対策を「対応済み」として放置せず、恒久修正へ移行する期限と担当者を管理することです。

脆弱性の優先順位付けから修復、暫定防御までの考え方は、AI時代の脆弱性管理・パッチ管理 実践ガイド|優先順位付けから修復・暫定防御まででまとめています。

脆弱性管理で重要なのは「発見件数」ではなく対応完了まで管理できること

脆弱性管理ツールを導入すると、多数のCVEを可視化できます。

しかし、

20,000件検出した → Criticalが500件ある → 担当部門へ一覧を送付

で止まってしまえば、脆弱性管理の目的は達成できません。

デジタル庁GSSの事例や、短期間で悪用されたPAN-OS・Citrixの脆弱性を見ると、企業が必要としているのは単純な「脆弱性リスト」ではありません。

必要なのは、

自社のどの資産が危険なのかを把握し、実際に悪用される前に優先して対応し、対応できない場合は緩和し、その後まで確認する仕組み

です。

特に、

  • インターネットへ公開されている
  • VPNやファイアウォールなど境界にある
  • 認証やID基盤に関係する
  • 実際の攻撃で悪用されている
  • KEVへ掲載されている
  • ランサムウェアでの悪用が確認されている
  • 侵害時の業務影響が大きい

といった脆弱性は、CVSSだけではなく組織固有のリスクを踏まえて優先順位を決める必要があります。

脆弱性管理ツールは、この一連の運用を継続的に支援するために利用します。

脆弱性管理・パッチ管理を資料で確認する

脆弱性の優先順位付けや修正プロセス、パッチをすぐに適用できない場合の対応を整理した資料も公開しています。

AI時代の脆弱性管理・パッチ管理 実践ガイド|優先順位付けから修復・暫定防御まででは、CVSSだけに依存しない優先順位付け、資産との突合、修復、暫定防御、対応後の再確認までを一連の運用として整理しています。

脆弱性管理に関する関連記事

脆弱性管理のお役立ち資料