改めて考える脆弱性対応の期限と優先度~主要文書と3つの視点で整理する~

Compact

true

担当領域：脆弱性管理／専門分野：脆弱性管理、アジャイル/スクラム、セキュリティアーキテクト

お客様に提供するシステムの脆弱性管理を行うための基盤づくりや推進業務に従事。 CISSP、情報処理安全確保支援士（RISS）を保持。

columns

span-col-12

tablet-columns

tablet-span-col-8

bottomMargin

Spacing07

脆弱性対応では、「パッチは何日以内に適用すべきか」という期限の議論がたびたびおこります。
近年は、個別のパッチだけでなく、累積パッチ、リビジョンアップ、バージョンアップといった形で定期的に適用することが一般的になっています。
一方で、ゼロデイ攻撃など緊急性が求められる場合、脆弱性の内容や悪用状況、システム特性を踏まえて判断することも重要です。
本ブログでは、まず主要な公開文書をもとに、脆弱性対応の期限と優先度についてどのように考えられているかを整理し、複数の視点から考察します。

近年の脆弱性の特徴

主要な公開文書における脆弱性対応の期限

3つの視点から考える脆弱性対応

AI時代の脆弱性対応について考える

まとめ

近年の脆弱性の特徴

脆弱性対応の期限が議論される背景の一つとして、脆弱性の報告件数が年々増加していることがあります。NVD[1]への脆弱性の登録件数は、2023年は約3万件、2024年は約4万件、2025年は約5万件と増加しており、組織が把握し、対応を検討すべき対象は増え続けています。
また、問題は件数の多さだけではありません。公表された脆弱性が実際の攻撃に使われる事例も継続的に報告されています。例えば、CISAが公開しているKEV Catalog[2]には、実際に悪用が確認された脆弱性が継続的に追加されています。このことから、脆弱性対応では、深刻度だけでなく、実際に悪用されているかどうかも踏まえて優先順位を考える必要があります。
さらに近年は、AIの活用によって、公開情報の整理、影響調査、コード理解、PoC分析などが効率化されつつあります。攻撃側・防御側の双方で、既知脆弱性への対応スピードは今後さらに速くなる可能性があります。
このように、対応すべき脆弱性が増え、実際に悪用されるものもある中では、脆弱性対応の期限を一律の日数だけで決めるのが難しい場面が増えています。

主要な公開文書における脆弱性対応の期限

ここでは、主要な公開文書では脆弱性対応の期限をどのように捉えているのかを表1に整理します。

表1　主要な公開文書における脆弱性対応の期限

出典

位置づけ・主な内容

Column3

Column4

期限に関する記述

Column6

IPA/JVN[3][4]

国内で脆弱性情報を確認する際の基本的な参照先。脆弱性の概要、影響を受ける製品、対策、ベンダ情報などの確認先

Column3

Column4

一律の適用期限の提示なし。脆弱性情報や対策情報の提供が中心

Column6

JPCERT/CC[5]

インシデント対応支援を行う機関。緊急性の高い脆弱性に関する注意喚起、対策、回避策の提示

Column3

Column4

一律の適用期限の提示なし。個別事案ごとの早急な対応や回避策の実施を求める形式

Column6

NIST SP 800-40 Rev.4[6]

パッチ管理計画・運用ガイド。資産把握、優先順位付け、テスト、展開、例外管理、メトリクスなどの整理

Column3

Column4

一律の適用期限の提示なし。リスク評価と優先順位付けに基づく運用の重視

Column6

ISO/IEC 27001/27002[7][8]

情報セキュリティ管理の国際規格。ISO/IEC 27001:2022の附属書AおよびISO/IEC 27002:2022では、技術的脆弱性に関する情報の入手、評価、適時対応が求められる

Column3

Column4

一律の適用期限の提示なし。技術的脆弱性への適時対応の要求

Column6

CISA KEV Catalog/BOD 22-01[9]

KEV Catalogは、実際に悪用が確認された脆弱性の一覧。BOD 22-01は、米国連邦民間機関に対し、KEV Catalog掲載脆弱性の是正を求める指令

Column3

Column4

KEV Catalog自体は一覧情報であり、BOD 22-01でKEV Catalog掲載脆弱性ごとの是正期限の設定

Column6

PCI DSS v4.0.1[10]

クレジットカード情報を扱う環境向けの業界標準。セキュリティパッチの適用についての比較的具体的な要件

Column3

Column4

重大なセキュリティパッチはリリース後1か月以内の適用

Column6

表1を見ると分かるように、脆弱性対応の期限について一律の日数を明確に示している文書はそれほど多くありません。NIST SP 800-40やISO/IEC 27001 / 27002は、固定的な期限を示すというよりも、脆弱性情報の収集、評価、優先順位付け、テスト、展開、例外管理といった一連の運用プロセスを整備することを重視しています。
国内のJVNやJPCERT/CCも同様に、脆弱性情報や注意喚起、対策情報を提供する重要な情報源ではありますが、すべての脆弱性に一律の適用期限を求める形にはなっていません。
一方で、CISAのKEV CatalogとBOD 22-01は、実際に悪用が確認された脆弱性を特に重視している点が特徴です。BOD 22-01は米国連邦政府機関向けの指令ですが、KEV Catalogに掲載された脆弱性に是正期限を設定しており、実際に悪用されている脆弱性は通常より優先して対応すべきという考え方を明確に示しています。
また、PCI DSS v4.0.1は、比較的具体的な期限を示している例です。対象はカード会員データを扱う環境に限られますが、リスクの高い脆弱性に対して一定の期限を設けて管理する考え方の参考になります。
表1全体を俯瞰すると、「全ての脆弱性に共通する一律の期限」を示すというより、リスクに応じて優先順位を付けて対応する考え方が中心だと分かります。
そして、重要な点ですが、一律の外部基準が少ないからこそ、各組織は自分たちの運用に合わせて脆弱性対応の期限を設計する必要があります。
次の章では3つの視点で脆弱性対応の期限を設計する際の要点を整理します。

3つの視点から考える脆弱性対応

ここでは、脆弱性対応の期限を設計する際の要点を運用視点、SIer視点、ユーザ企業視点の3つに分けて整理します。

運用視点での整理

運用で重要なのは、一律の日数を先に決めることではなく、まず通常時の運用サイクルを立て付けたうえで、緊急時対応と例外管理を組み合わせることです。
まずは、通常時に回す定期的な運用と、緊急時の運用を分けて考えることが重要です。

通常時の運用サイクル
例えば月次や四半期ごとに、脆弱性情報の収集、影響評価、検証、適用、結果確認を回すサイクルをあらかじめ定めておくことが基本になります。近年は、個別パッチではなく、累積更新やリビジョンアップ、バージョンアップとして提供されることも多いため、「いつ、どの単位で更新を取り込むか」という定期運用の設計が以前より重要になっています。
緊急時の運用サイクル
通常時の運用サイクルとは別に、短い期限で対応する仕組みを用意しておく必要があります。例えば、実際に悪用が確認されている脆弱性や、外部公開資産に存在する重大な脆弱性などについては、通常の月次対応を待たず、数日から1週間程度で対処する、といった整理が考えられます。緊急時には、必要に応じてサービス停止を伴うメンテナンスを実施するかどうかを判断できるよう、あらかじめそのプロセスを設計しておくことも重要です。

このように、通常時と緊急時の運用を分けたうえで、次に重要になるのが優先順位の判断基準です。優先順位を決める際には、例えば次のような観点を組み合わせて判断します。

CVSSなどの深刻度
KEV Catalog掲載の有無など、実際の悪用状況
PoC公開状況や、必要に応じてEPSSなど悪用可能性指標
外部公開資産かどうか
対象資産の業務重要度、機密性、完全性、可用性への影響
回避策や補完策の有無

さらに、実際の運用では、優先度が高くても期限内に適用できない場合があります。
そのため、例外管理の仕組みもあらかじめ定めておく必要があります。
例外承認の条件、暫定対策の実施、再評価期限、恒久対策への移行計画を明確にしておくことで、「未対応の脆弱性」を放置するのではなく、「管理された例外」として扱うことができます。

SIer視点での整理

SIerの立場では、パッチが公開されたからといって、すぐに本番環境へ適用できるとは限りません。顧客システムは、OSやミドルウェアだけでなく、業務アプリケーション、個別カスタマイズ、他システムとの連携などを含んでいるため、適用前に影響確認や検証が必要になることが多いためです。
主に、次のような点が重要になります。

適用前の影響確認や検証
パッチ適用によって、業務アプリケーションや連携機能に想定外の影響が出る可能性があるため、事前の確認や検証が重要です。
システムを止めずに適用する設計
24時間稼働のシステムや停止影響が大きいシステムでは、パッチ適用作業そのものが大きなリスクになることがあります。そのため、停止せずに適用する、または停止時間を最小化できる構成や手順を考えておくこと重要です。
回避策を検討
影響確認や業務都合により、すぐにパッチ適用ができない場合もあります。そのため、回避策として、設定変更やWAF等を用いた回避策も含めて、適用までのリスクをどう管理するかをあらかじめ整理しておくことが重要です。

このように、SIerにとって重要なのは、影響確認や検証、停止を抑えた適用方法、回避策の検討を運用の段階ではなく設計の段階から考慮しておくことです。

ユーザ企業視点での整理

ユーザ企業の立場でも、脆弱性が公表されてから個別に調整するのではなく、平時のうちから必要なことを整理しておくことが重要です。
主に、次のような点が重要になります。

SIerとあらかじめ調整
どのような場合に緊急対応を行うのか、どのように連絡し判断するのかといった点を、事前に合意しておくことが重要です。
業務影響を考慮
パッチ適用に伴う停止や再起動が、どの業務にどの程度影響するのかを整理しておくことが重要です。これが曖昧だと、対応の判断が遅れやすくなります。
責任範囲の明確化
誰が影響を判断し、誰が適用を承認し、誰が実際に対応するのかを明確にしておくことが重要です。特に、複数ベンダや複数部門が関わる場合には、この整理が欠かせません。

このように、ユーザ企業にとって重要なのは、SIerとの事前調整、業務影響の整理、責任範囲の明確化を、脆弱性が公表されてからではなく平時のうちから整理しておくことです。

AI時代の脆弱性対応について考える

今後は、脆弱性情報の収集、影響確認、優先順位付け、適用判断といった一連のプロセスで、AIの活用がさらに進むと考えられます。これにより、脆弱性の公表から対応判断までの時間は短くなり、これまで人間が行っていた情報整理や判断の一部も、AIによって支援・代替されていく可能性があります。
ただし、こうした業務がすぐにすべてAIに置き換わるわけではありません。個別のシステム特性や業務影響、例外の扱いなどは、引き続き人間による判断が重要になると考えられます。
このため、AIの活用が進んでも、脆弱性対応の基本的な考え方そのものは変わりません。脆弱性情報を把握し、影響を評価し、優先順位を付けて対応すること、そして例外や回避策も含めて管理することが今後も重要です。

まとめ

今回は、脆弱性対応の期限と優先度について、主要な公開文書を整理したうえで、運用視点、SIer視点、ユーザ企業視点から考え方を整理しました。脆弱性対応の期限は一律の日数だけで決められるものではなく、脆弱性の内容や悪用状況、システム特性、業務影響を踏まえて判断することの重要性を説明しました。
また、3つの視点からそれぞれ平時から検討すべき内容について説明しました。
AIの活用が進む可能性がありますが、脆弱性対応の基本となる考え方は変わりません。
今後のAIの活用に着目し、運用に生かせるものを見極め、脆弱性対応に取り組んでいきたいと思います。