脆弱性対応
脆弱性対応の優先順位を、深刻度と自社への影響で決める
脆弱性情報を受け取った後、対象資産、悪用状況、外部公開、業務影響を確認し、修正・暫定対策・再確認まで進める実務手順を解説します。
cotomu セキュリティ編集部 / 公開・資料確認： / 読了目安 6分
この記事で整理すること
自社に該当するかを確かめ、担当者と期限を決める。
脆弱性の通知を受け取っても、対象のシステムと担当者が分からなければ対応は止まります。最初に確かめたいのは、自社でその製品を使い、影響する条件を満たしているかです。そのうえで悪用状況、外部からの到達性、業務への影響を重ねて、対応順を決めます。
深刻度の点数だけで順番を決めると、外部公開された機器と、到達できる範囲が限られた検証環境を同じ扱いにしてしまいます。以下は社内運用を組み立てるための実務例です。
製品名より先に、対象資産を確かめる
通知の製品名を、社内の台帳と照合します。製品名、バージョン、導入先、外部公開の有無、担当者を確認し、ベンダーが示す影響条件と修正版を読みます。クラウドやSaaSでは、利用者が更新する範囲と、提供者が対応する範囲も確認してください。
国内の注意喚起はJPCERT/CCの注意喚起ページやJVNで確認できます。製品固有の条件や回避策は、そこからリンクされるベンダーの最新情報までたどります。対象か判断できない場合は「該当なし」とせず、未確認の理由を残します。
深刻度に、悪用と露出を重ねる
共通の深刻度指標であるCVSSは、技術的な深刻度を把握する材料です。自社の対応順には、それに加えて次の情報を使います。
| 確認 | 判断材料の例 |
|---|---|
| 自社に該当するか | 製品、バージョン、有効な機能・設定 |
| 悪用されているか | ベンダーの説明、公式の注意喚起、KEVへの掲載 |
| 外部から届くか | インターネット公開、接続元の制限、認証の条件 |
| 被害はどこまで及ぶか | 管理権限、重要情報、他システムへの接続 |
| 変更の影響は何か | 停止時間、互換性、代替手段、検証環境 |
CISAのKnown Exploited Vulnerabilities（KEV）カタログは、悪用が確認された脆弱性の情報をまとめたものです。CISAは優先順位付けの材料として利用するよう案内しています。KEVに載っていないことは、安全の証明にはなりません。 掲載期限をそのまま自社の義務とせず、自社のリスクと適用される要件から期限を決めます。
たとえば、悪用が確認された脆弱性が外部公開の認証基盤に該当するなら、業務影響を踏まえて早急な対応を検討します。これは判断例であり、すべての環境に共通する期限ではありません。
修正できない間の対策にも期限を付ける
業務上すぐに更新できないときは、ベンダーが示す回避策やアクセス制限等を検討します。どの攻撃経路を減らすか、残るリスクは何か、いつ恒久対応に戻すかを記録してください。回避策の有効性は製品や構成によって異なります。
実務では「更新担当」「実施期限」「業務側の承認者」「暫定対策」「再確認日」を一つの管理表に残すと、対応待ちを追いやすくなります。担当者が不在の場合の代理も決めます。対象の確認が未完了なら、その調査自体に担当と期限を付けてください。
侵害が疑われる状況では、更新だけで対応を終えず、ログの保全や影響調査も必要になることがあります。調査の範囲と進め方は既存の保守・専門窓口と確認します。
適用と再確認までを一つの対応にする
NIST SP 800-40 Rev.4（2022年）は、パッチ管理を予防保全として位置付け、適用後の検証も扱っています。管理表を「作業した」で閉じず、修正後のバージョンと対象台数、主要業務の動作、暫定対策を戻す条件を確かめます。
再スキャンや構成確認の結果、確認者、実施日を残し、漏れがあれば再対応に戻します。社内で期限の判断ができない場合や、通知と資産の照合が担当任せになっている場合は、現在の管理方法から相談できます。脅威情報を判断に変える流れは脅威インテリジェンスの実務ガイドもご参照ください。
参照資料と確認日
資料確認：2026年10月9日。KEVと製品の注意喚起は随時更新されます。最新の件数、特定の製品・CVEの期限を本記事では固定しません。
本文中の実務例は編集部の提案です。公式資料の要件や、安全性の保証を示すものではありません。製品の影響範囲と対策は、対応時点のベンダー情報で確認してください。記事の編集方針