2026年6月12日

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

目次

近年の脆弱性の特徴

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

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

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

表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つに分けて整理します。

運用視点での整理

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

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

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

SIer視点での整理

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

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

ユーザ企業視点での整理

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

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

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

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

まとめ

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

参考

執筆者の他の記事を読む