重大な脆弱性の注意喚起が届くたびに、対象製品を探し、担当者へ連絡し、 業務停止の影響を確認してパッチを適用する。この対応だけでも相応の負荷がかかります。 しかし、本当に難しいのはパッチ作業そのものより、「どこで使っているか」「誰が判断するか」 「適用できない場合に何をするか」が平時からつながっていないことです。

IPAは2026年3月に「製品利用者向けガイド」を公開し、同年6月に第1版第2刷を公表しました。 ガイドは脆弱性対処を運用開始後だけの作業と捉えず、計画・要件定義、調達、導入、運用、廃棄という システム・サービスのライフサイクル全体へ組み込む考え方を示しています。

本記事では、この考え方を経営者、IT責任者、実務担当者が共通の運用に落とし込むための5つの手順に整理します。 特定の製品やツールを前提にせず、重要なサービスから小さく始める進め方です。

課題は情報不足ではなく、判断の流れが分断していること

脆弱性情報は、製品ベンダー、IPAのJVN・JVN iPedia、セキュリティ機関、監視サービスなどから届きます。 一方で、資産台帳にバージョンや利用部門がない、SaaSや組み込み機器が台帳から漏れる、 保守契約やサポート終了日が別管理になっている、といった分断があると、 情報を受け取っても自社への影響を速やかに判断できません。

また、CVSSのような共通指標は脆弱性の技術的な深刻度を比べる有用な材料ですが、 それだけで自社の対応順序は決まりません。実際に悪用されているか、外部公開されているか、 重要データや高い権限へ到達できるか、停止時にどの業務へ影響するかを組み合わせる必要があります。 CISAもKnown Exploited Vulnerabilities（KEV）カタログを、脆弱性管理の優先順位付けへの入力として使うよう案内しています。

脆弱性管理の目的は、すべての更新を最速で適用することではありません。 事業にとって許容できないリスクを見極め、対処、確認、例外管理、更新終了までを継続できる状態にすることです。

実践手順1：重要サービスから「対象・責任・期限」をそろえる

最初から全社のソフトウェアを完全に把握しようとせず、停止や情報漏えいの影響が大きいサービスを一つ選びます。 そのサービスについて、業務オーナー、システム責任者、運用担当、セキュリティ担当、 ベンダー・保守委託先の役割を整理します。担当者名ではなく、異動後も残る役割として定義します。

資産台帳には、少なくとも次の情報を結び付けます。

  • 対象：製品名、バージョン、主要な構成要素、設置場所、外部公開の有無
  • 事業影響：支える業務、扱うデータ、停止時の影響、代替手段
  • 責任：判断者、作業者、承認者、連絡先、委託先との責任分界
  • 期限：保守期限、サポート終了日、契約更新日、次回棚卸し日

クラウドサービスでは自社が製品バージョンを管理しない場合もあります。 その場合は、設定、利用アカウント、データ、連携先、障害・脆弱性通知の受信先を管理対象にします。 「所有しているもの」ではなく「事業が依存しているもの」を起点にすることが重要です。

実践手順2：調達時に、将来の脆弱性対応まで決める

導入後に初めて脆弱性対応の条件を確認すると、通知が届かない、修正プログラムの提供時期が分からない、 検証環境がない、サポート終了までに移行できないといった問題が起きます。 調達・設計の段階で、将来の運用と廃棄を含む要件を確認します。

  • 脆弱性とセキュリティ更新の通知方法、窓口、提供言語
  • 修正プログラム、回避策、影響確認情報が提供される条件
  • 検証、展開、ロールバックに必要な機能と支援範囲
  • 重大な事象が起きた際の連絡、役割、目標時間
  • サポート終了の事前通知期間、移行支援、データ返却・消去

IPAのガイドは、契約上の責任範囲や役割分担を一律に定義するものではないと明記しています。 実際の条件は製品、サービス、契約、業務の重要性によって異なります。 セキュリティ部門だけで決めず、調達、法務、事業部門、IT運用が実行可能性を確認してください。

実践手順3：技術的深刻度と「自社の文脈」で優先順位を決める

脆弱性情報を受け取ったら、まず台帳と構成情報を使って対象の有無を確認します。 次に、単一のスコアではなく、次の観点を組み合わせて対応順序と期限を決めます。

  1. 悪用状況：実際の悪用が確認されているか、信頼できる注意喚起があるか。
  2. 到達可能性：インターネット公開、認証の要否、ネットワーク分離、実行条件はどうか。
  3. 権限と影響：機密性、完全性、可用性、横展開、重要業務への影響はどうか。
  4. 対処可能性：正式な修正、設定変更、機能停止、アクセス制限、監視強化が選べるか。
  5. 変更リスク：適用による停止や互換性問題を、どの手順で抑えられるか。

対応しない、または延期する判断も記録します。理由、残存リスク、暫定対策、承認者、見直し日が残っていれば、 状況の変化に応じて再判断できます。KEVへの追加、攻撃コードの公開、外部公開設定の変更などは、 優先順位を見直すきっかけになります。

実践手順4：適用を「取得・検証・展開・確認」の標準作業にする

緊急対応ほど、担当者の経験だけに頼らない標準手順が必要です。 NIST SP 800-40 Rev. 4は、パッチ管理を技術の予防保守として捉え、 識別、優先順位付け、取得、インストール、適用確認を組織的に運営する考え方を示しています。

実務では、通常変更と緊急変更の経路を分けつつ、最低限の安全確認は共通化します。

  • 正規の配布元と署名・ハッシュなどを確認し、修正プログラムを取得する
  • 検証環境または限定された対象で、機能、性能、連携、監視への影響を確認する
  • バックアップとロールバック条件を準備し、業務部門と停止・周知を調整する
  • 段階的に展開し、失敗率や異常を監視して、必要なら展開を止める
  • 適用後のバージョン、設定、再スキャン結果を確認し、完了の証跡を残す

すぐに適用できない場合は、通信経路の制限、不要機能の停止、権限縮小、監視ルールの追加など、 製品ベンダーの情報を踏まえた暫定対策を検討します。暫定対策は恒久対応ではないため、 終了条件と再確認日を必ず設定します。

実践手順5：適用後の確認とサポート終了を同じ台帳で追う

配布ツールが「成功」と表示しても、再起動待ち、対象漏れ、構成差異、更新後の設定戻りなどが残ることがあります。 適用率だけでなく、期限超過、例外の滞留、対象不明の資産、サポート終了が近い製品、 適用後の検証完了までを追います。

サポート終了が決まった製品は、最終更新を当てて使い続けるだけではリスクを管理できません。 移行先、予算、データ移行、連携変更、利用者周知、旧環境の停止を計画し、 廃棄時にはアカウント、認証情報、APIキー、保存データ、バックアップ、監視設定まで確認します。 物理機器やクラウドに残るデータの消去方法は、情報の機密性、契約、利用環境に応じて決めます。

最初の90日で一つのサービスを一周させる

  1. 1〜30日：重要サービスを一つ選び、資産、責任者、通知先、保守・終了期限を整理する。
  2. 31〜60日：過去の脆弱性を一件使い、影響確認、優先順位、承認、適用、確認の流れを試す。
  3. 61〜90日：不足した情報と手順を改善し、例外管理とサポート終了計画を台帳へ加える。

対象数や期間は一例です。重要なのは、棚卸しだけ、手順作成だけで止めず、 一つのサービスで検知から完了確認までを実際に一周させることです。 そこで得た所要時間、判断の詰まり、対象漏れをもとに、次のサービスへ展開します。

注意点：完全な台帳や単一スコアを前提にしない

  • CVSS、KEV、ベンダー評価のいずれか一つだけで、自社の優先順位を自動決定しない。
  • クラウドや委託先に運用を任せても、自社の設定、アカウント、データ、連絡判断まで移転したと考えない。
  • パッチ適用が難しい事情を恒久的な例外にせず、暫定対策、承認、見直し日を記録する。
  • 資産台帳の完成を待たず、重要サービスから管理範囲を広げ、未知の資産を減らす。
  • 脆弱性が存在しないことや、対策後に事故が起きないことを、診断やチェックリストだけで保証しない。

本記事は公的資料をもとに一般的な実務の進め方を整理したものであり、 個別の法令適合性、契約条件、製品安全性を判断する法律・監査・認証上の助言ではありません。 実際の対応では、製品ベンダーの最新情報、契約、業務影響、専門家の評価を確認してください。

まとめ

脆弱性管理を安定させる鍵は、注意喚起のたびに緊急パッチを回すことだけではありません。 重要サービスを起点に対象と責任をそろえ、調達時に将来の対応条件を決め、 自社の文脈で優先順位を付け、安全に適用し、確認とサポート終了まで追うことです。

この流れが日常のIT運用と経営判断につながれば、情報量が増えても、限られた人員を重要なリスクへ配分しやすくなります。 まずは一つの重要サービスでライフサイクルを一周させ、判断と証跡を残せる運用へ育ててください。

参考にした公式資料

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る