脆弱性管理とは？脆弱性診断・パッチ管理との違い、優先順位付けと運用プロセスを解説

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

脆弱性診断を一度実施したり、公開されたパッチを適用したりするだけでは脆弱性管理にはなりません。どの資産を保有しているか、どの脆弱性が存在するか、実際に悪用されているか、対象システムが外部公開されているか、業務への影響はどの程度かを継続して確認します。

英国National Cyber Security Centre（NCSC）は、脆弱性管理によって、自組織の技術環境にどの脆弱性が存在するか、更新が失敗している場所はどこかを定期的に把握し、重大な脆弱性が公表された際に自社の影響を迅速に確認できるようになると説明しています。

脆弱性管理とは

脆弱性管理は、システムやソフトウェアの弱点を「見つける」だけでなく、「対応が完了するまで管理する」取り組みです。

対象には次のようなものがあります。

• OS
• サーバー
• PC・モバイル端末
• ネットワーク機器
• Webアプリケーション
• クラウド環境
• SaaS
• ミドルウェア
• OSS・ライブラリ
• コンテナ
• ファームウェア
• 外部公開資産

脆弱性には、ソフトウェアの欠陥だけでなく、設定不備、更新漏れ、不要な外部公開なども含まれます。

脆弱性管理では、資産を把握し、脆弱性情報を収集し、自社への影響を評価し、修正または緩和し、対応結果を確認するサイクルを継続します。

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

企業が対応しなければならない脆弱性は、年間数件という規模ではありません。

OS、クラウド、ネットワーク機器、業務アプリケーション、OSSなど複数の技術を利用する企業では、新しい脆弱性が継続的に追加されます。

Microsoftは2026年7月だけで569件を修正

Microsoftは2026年7月の月例セキュリティ更新で569件の脆弱性を修正しました。

セキュリティ対策Labの調査では、このうち56件がCriticalで、Active Directory Federation ServicesとSharePoint Serverの2件はパッチ公開前から実際の攻撃で悪用されていたゼロデイでした。

関連記事：Microsoft、2026年7月定例パッチで569件の脆弱性を修正―2件はゼロデイ攻撃で悪用済み

企業が利用する製品すべてについて公開された脆弱性を同じ優先順位で対応することは現実的ではありません。対象資産の有無、外部公開状況、悪用状況、業務上の重要度を組み合わせて判断する必要があります。

Oracleでは一度に673件、247件が認証不要でリモート悪用可能

Oracleは2026年9月のCritical Security Patch Updateで673件の新規セキュリティパッチを公開しました。

このうち247件は認証なしでリモートから悪用可能とされ、CVSS 10.0の脆弱性も複数含まれていました。

関連記事：Oracle、9月CSPUで673件の新規セキュリティパッチを公開

件数が多い場合、CVSSの高い順に対応するだけでは、業務上の優先順位と一致しないことがあります。自社で利用している製品か、インターネットから到達できるか、実際の攻撃で悪用されているかなどの情報を加える必要があります。

ゼロデイでは「次回の定例対応」を待てない

Cisco Catalyst SD-WANのCVE-2026-20127では、Cisco Talosが実際の悪用を確認し、その活動が少なくとも2023年まで遡る証拠を公表しました。CiscoはCVSS 10.0と評価しています。

関連記事：Cisco SD-WANゼロデイが新局面―CVE-2026-20127の長期悪用とPoC公開

このような脆弱性では、月次や四半期単位の定例パッチ運用だけでは対応が遅れる可能性があります。

脆弱性管理では、通常の更新サイクルとは別に、実悪用されている重大脆弱性へ緊急対応する経路を用意します。

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

脆弱性診断は、システムやアプリケーションに存在する脆弱性・設定不備などを発見する取り組みです。

脆弱性管理は、診断結果を含む複数の情報を使い、発見後の対応まで継続的に管理します。

脆弱性診断については、以下の記事で種類や実施頻度を整理しています。

脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説

脆弱性管理とパッチ管理の違い

パッチ管理は、ソフトウェアやファームウェアの更新プログラムを特定し、優先順位を付け、取得・適用し、正しく適用されたことを確認するプロセスです。

NIST SP 800-40 Rev.4では、エンタープライズパッチ管理を、組織全体でパッチ、アップデート、アップグレードを特定・優先順位付け・取得・インストール・検証するプロセスと定義しています。

脆弱性管理の方が範囲は広く、パッチが存在しないゼロデイや、設定変更、アクセス制限、サービス停止などで対応する脆弱性も扱います。

脆弱性管理とASMの違い

ASM（Attack Surface Management）は、主にインターネットから見える自社のIT資産を継続的に発見し、攻撃面を把握・評価する取り組みです。

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

ASMは「何が外部から見えているか」を見つける役割、脆弱性管理は「見つかった資産に存在するリスクをどう修正するか」まで扱う役割として整理できます。

ASM（アタックサーフェスマネジメント）とは

脆弱性管理の基本プロセス

脆弱性管理は、次の流れで設計すると整理しやすくなります。

1. IT資産を把握する

最初に、何を管理するのかを把握します。

例えば次の情報です。

• 資産名
• IPアドレス・FQDN
• OS
• ソフトウェア
• バージョン
• 管理部門
• システムオーナー
• 外部公開の有無
• 業務上の重要度
• 個人情報・機密情報の有無
• サポート期限

英国NCSCも脆弱性管理の原則として資産把握を挙げています。

自社が所有していると認識していないサーバーや、担当者不明のシステムでは、脆弱性が公表されても対応判断ができません。

2. 脆弱性情報を収集する

次に、自社資産へ影響する脆弱性情報を収集します。

主な情報源には次があります。

• ベンダーのセキュリティアドバイザリ
• CVE
• NVD
• CISA Known Exploited Vulnerabilities（KEV）
• JVN・JPCERT/CC
• 脆弱性診断ツール
• SCA
• ASM
• EDR・クラウドセキュリティ製品

すべてのCVEを人手で確認するのではなく、自社の資産情報と脆弱性情報を照合できる仕組みが必要です。

3. 脆弱性を検出する

保有資産に対象の脆弱性が存在するかを確認します。

方法は対象によって異なります。

• 認証付き脆弱性スキャン
• ネットワークスキャン
• Webアプリケーション診断
• エージェントによる端末情報収集
• クラウドAPI連携
• SCA
• SBOM
• ベンダー提供ツール
• バージョン確認

一つの診断方法だけで全資産をカバーするのは難しいため、資産種別ごとに確認方法を決めます。

4. リスクを評価し、優先順位を付ける

検出された脆弱性をすべて同じ順番で修正するのではなく、リスクに応じて優先順位を付けます。

主な判断材料は次の通りです。

• 実際の攻撃で悪用されているか
• インターネットから到達可能か
• 認証なしで悪用できるか
• 攻撃にユーザー操作が必要か
• 対象資産の業務上の重要度
• 機密情報を扱っているか
• 権限昇格やRCEにつながるか
• ランサムウェアなどで利用されているか
• 修正版・緩和策が存在するか
• CVSS

CISAはKEV Catalogを、実際の攻撃で悪用された脆弱性の権威ある情報源として提供し、組織が脆弱性管理の優先順位付けへ利用するよう推奨しています。

CVSSが高いかどうかだけではなく、実悪用と自社環境の条件を組み合わせて判断します。

5. 修正または緩和する

対応方法はパッチだけではありません。

• パッチ適用
• バージョンアップ
• 設定変更
• 外部公開停止
• アクセス元制限
• WAF・IPSなどの緩和策
• 機能停止
• 対象機器の隔離
• 製品利用停止・廃止

ゼロデイのようにパッチが提供されていない場合は、一時的な緩和策を実施し、修正版公開後に正式対応へ切り替えます。

6. 修正結果を確認する

「担当者が更新したと報告した」だけでクローズせず、脆弱性が解消されたことを確認します。

• 再スキャン
• バージョン確認
• 設定確認
• パッチ適用状況確認
• 外部公開状況確認
• ベンダーの確認コマンド・ツール

イスラエル国家サイバー総局（INCD）のCyber Defense Methodologyでも、継続的な脆弱性評価、過去と現在のスキャン結果比較、脆弱性修正プロセスの追跡などを示しています。

CVSSだけで対応順を決めない

CVSSは脆弱性そのものの技術的な深刻度を比較するために利用できますが、企業ごとのリスクをそのまま示す数値ではありません。

例えばCVSS 9.8でも、自社では対象製品を利用していないのであれば対応対象ではありません。

一方、CVSSがそれより低くても、インターネット公開された重要システムで実際に悪用されている脆弱性であれば、優先度を上げる必要があります。

CISAはKnown Exploited Vulnerabilities Catalogについて、実際の攻撃で悪用された証拠がある脆弱性を掲載し、脆弱性管理の優先順位付けに使用するよう案内しています。

企業内では少なくとも、

「技術的な深刻度 × 実悪用状況 × 外部公開状況 × 資産の重要度」

を組み合わせて判断できるようにします。

ゼロデイ脆弱性への対応を別ルートで用意する

通常の脆弱性対応を月次で行っていても、実際に悪用されているゼロデイでは数週間待てない場合があります。

緊急対応対象となる条件を事前に決めておくと、公開後の判断を短縮できます。

例えば、

• ベンダーが実悪用を確認
• CISA KEVへ追加
• インターネット公開された製品
• 認証不要のRCE
• 重要システムで利用
• PoC公開後にスキャン・悪用が増加

などです。

通常の変更管理を完全に無視するのではなく、緊急変更手順として誰が判断し、誰が停止・更新を承認できるかを定めます。

脆弱性対応の期限はどう決めるか

すべての脆弱性へ同じ期限を設定する方法では、リスクの高い脆弱性へ人員を集中できません。

英国NCSCは、更新を原則として速やかに適用する方針、実悪用への対応、資産把握、トリアージ・優先順位付け、更新しない場合のリスク受容、プロセスの継続的な検証を脆弱性管理の原則として示しています。

イスラエルINCDのCyber Defense Methodologyでは、組織が脆弱性の重大度に応じた修正SLAを定義し、期限超過を監視する考え方を示しています。資料中の例では、Criticalを直ちに、高を1か月以内、中を3か月以内としています。

これはすべての組織へ一律に適用する期限ではありません。自社の資産重要度、変更可能時間、外部公開状況、実悪用状況などを踏まえてSLAを定めます。

実際に悪用されている脆弱性については、通常SLAより短い緊急期限を設定する設計が必要です。

脆弱性管理ツールでできること

管理対象が増えると、Excelやチケットだけでは脆弱性と資産の対応関係を維持しにくくなります。

脆弱性管理ツールでは、製品によって次の機能を提供します。

• 資産情報の収集
• 脆弱性スキャン
• CVEとの照合
• CVSSの表示
• CISA KEVとの照合
• 外部公開状況の管理
• リスクスコアリング
• 修正担当者の割り当て
• チケット管理
• SLA・期限管理
• 対応状況のダッシュボード
• 再スキャン
• API連携
• SCA・SBOM連携
• クラウド資産連携

脆弱性管理ツールを選ぶ際は、検出件数の多さだけではなく、「誰が、いつまでに、何を修正するか」を運用へ載せられるかを確認します。

脆弱性を見つける機能が中心の製品については、以下の記事で整理しています。

脆弱性診断ツールとは？種類・自動診断と手動診断の違い・企業での選び方

米国・英国・イスラエルの公的機関が示す脆弱性管理

米国：CISAは実悪用を優先

CISAはKnown Exploited Vulnerabilities Catalogを公開し、実際の攻撃で悪用された脆弱性を脆弱性管理の優先順位付けへ利用するよう案内しています。

米連邦政府機関にはBOD 22-01に基づく是正期限がありますが、CISAは民間組織に対してもKEV掲載脆弱性の優先的な修正を推奨しています。

NISTはSP 800-40 Rev.4で、パッチ管理を単発の作業ではなく、組織全体の予防保守として扱っています。

英国：更新・実悪用・資産・優先順位・リスク受容を一つのプロセスにする

英国NCSCは脆弱性管理について、次の原則を示しています。

• 原則として更新する方針を持つ
• 実際に悪用されている脆弱性へ対応する
• 資産を把握する
• 評価・トリアージ・優先順位付けを行う
• 更新しないリスクを組織として所有する
• 脆弱性管理プロセスを検証・定期的に見直す

技術部門だけで閉じず、IT運用、セキュリティ、リスク管理、経営層を含む横断的なプロセスとして扱うことも示しています。

イスラエル：継続スキャンと修正管理を連携する

イスラエルINCDのCyber Defense Methodologyでは、組織の脆弱性管理プロセスに従って内部・外部の情報システムへ継続的な脆弱性評価を行うことを示しています。

さらに、

• スキャンツールを最新状態に保つ
• 過去と現在のスキャン結果を比較する
• 複数の評価ツールの結果を統合する
• 脆弱性管理と修正プロセスを連携する
• 重大度に応じた修正SLAを設定する
• SLA超過を監視する

といった運用を挙げています。

情報システム・セキュリティ部門が確認したいポイント

脆弱性管理を始める場合、最初からすべての資産と脆弱性を完全に管理しようとすると運用負荷が大きくなります。

英国NCSCも、最初は重要システムなど対象を絞って開始し、徐々に拡大する方法を示しています。

まずは次を確認します。

• 管理対象となるIT資産の一覧があるか
• 各資産に責任者が設定されているか
• 外部公開資産を把握できているか
• 脆弱性情報をどこから取得するか
• 脆弱性診断・スキャンの対象と頻度が決まっているか
• CISA KEVなど実悪用情報を確認しているか
• CVSS以外の優先順位付け基準があるか
• Critical・Highなど重大度別のSLAがあるか
• ゼロデイ・実悪用時の緊急対応手順があるか
• パッチがない場合の緩和策を管理できるか
• 対応後の再確認を実施しているか
• 対応を見送る場合のリスク承認者が決まっているか
• グループ会社や委託先をどこまで含めるか

脆弱性管理の目的は、発見された脆弱性をゼロにすることではありません。

限られた人員と変更可能時間の中で、自社にとって攻撃リスクの高い脆弱性を特定し、対応状況を追跡し、残存リスクを把握できる状態にすることが実務上の中心になります。

出典

• Known Exploited Vulnerabilities Catalog – CISA
• Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, NIST SP 800-40 Rev. 4 – NIST
• Vulnerability management – UK National Cyber Security Centre
• Vulnerability management guidance – UK National Cyber Security Centre
• Cyber Defense Methodology for an Organization – Israel National Cyber Directorate