月次のパッチ適用が通らなくなった — 保守契約の書き直し4点

保守契約書に「セキュリティパッチは月次のメンテナンス枠で適用します」と書いてある。3年前に締結したときは、それで十分に見えました。当時は、脆弱性が公表されてから実際に攻撃が始まるまで数週間の猶予があったからです。

その前提が変わりつつあります。複数の調査が、公表から攻撃コードが成立するまでの時間を「日」ではなく「時間」の単位で報告するようになりました。月次の適用枠は、最悪の場合29日間の無防備な期間を意味します。

契約書の文言を変えないまま運用だけ頑張る、という対応をしている会社が多いのですが、これは事故が起きたときに責任範囲が曖昧になります。

猶予が縮んでいる、という報告の中身

数字はいくつかの調査から出ています。いずれも観測範囲と定義が異なるため、絶対値ではなく変化の方向として読むのが妥当です。

• 攻撃までの平均時間について、2024年に約53日だったものが2026年には24時間未満とする集計がある
• 既知の脆弱性のうち、約4割で公表から数時間〜数日のうちに悪用が確認されている
• ある重大な脆弱性では、公表から9時間で動作する攻撃コードが作られた事例が報告されている

一方で、守る側の数字は逆方向に動いています。悪用が確認されている脆弱性の修正までの期間の中央値は43日で、前年の32日から延びたとする調査があります。攻撃側が速くなり、防御側が遅くなっている。 この差が広がっているというのが、いま起きていることです。

背景として指摘されているのは、AI による差分解析の自動化です。修正パッチが公開されると、そのパッチが「どこを直したか」から「何が壊れていたか」を逆算できます。この作業に人手と時間がかかっていたものが、短縮されています。修正の公開そのものが、攻撃のヒントになるという構造は以前からありましたが、そこにかかる時間が変わりました。

「全部を24時間で」は現実的ではない

だからといって、すべてのパッチを24時間以内に当てる契約に切り替えるのは、多くの中小企業にとって無理があります。検証環境での動作確認、業務時間を避けた適用、切り戻し手順の準備。速度を上げるには、その分の体制が要ります。

現実的なのは、対象を分けることです。分け方は次の3つで足ります。

重要なのは「緊急」の定義を、深刻度スコアではなく「外部から届くか」と「実際に悪用されているか」の2軸で決めることです。スコアが高くても、社内からしか到達できない管理画面の脆弱性は緊急ではありません。逆にスコアが中程度でも、公開サーバーで悪用が始まっているものは緊急です。

この2軸なら、専門知識がなくても判断できます。中小企業の脆弱性診断を検討する段階の会社でも、この区分だけは自社で決めておくべきです。

契約書で決めておく4点

保守を外部に委託している場合、揉めるのはたいてい事故のあとです。先に決めておく項目は次の4つです。

1. 緊急パッチの定義。 上記の2軸で、誰がどう判断するか。委託先が判断するのか、報告を受けて発注側が決めるのか
2. 連絡から適用開始までの時間。 「速やかに」ではなく時間数で書きます。営業時間内か、24時間365日かで費用が変わるため、ここが見積もりの分岐点になります
3. 業務停止を伴う場合の扱い。 緊急適用で業務が止まる可能性があるとき、承認を待つのか、先に適用して事後報告にするのか。待つ設計にするなら、待っている間の責任がどちらにあるかを書く必要があります
4. 対象範囲。 OS、ミドルウェア、アプリケーションのライブラリ、どこまでが保守範囲か。ライブラリの更新が範囲外になっている契約は多く、そこが実際の穴になります

4つ目は特に確認してください。更新が止まったまま運用されているサイトの多くは、保守契約自体はあるのに、契約範囲がサーバー側だけでアプリケーションの依存関係が入っていない、という状態です。

速く当てるより、まず「知る」を早くする

適用速度を上げる前に、多くの会社で効くのは検知の側です。そもそも自社が使っている製品の脆弱性が公表されたことを、当日中に知る仕組みがあるか。

ここが週次のメール確認になっていると、適用を24時間以内にすると契約で決めても、起点が3日後になります。速度を議論する前に、次の2つを確認してください。

1つは、使用している製品の一覧があるか。 サーバー、ミドルウェア、フレームワーク、主要ライブラリ。この一覧がないと、公表された脆弱性が自社に関係あるかを判断できません。

もう1つは、通知の受け口が個人のメールアドレスになっていないか。 担当者が休みの日に届いた通知が、月曜まで誰にも見られていない、というのはよくあります。共有のアドレスかチャットのチャンネルに集約します。

この2つは費用がほとんどかかりません。契約の見直しより先にやる価値があります。

頻度を上げると、別の問題が出る

適用頻度を上げると、今度は「当てたことで壊れる」事故の確率が上がります。ここを想定しないまま速度だけ上げると、可用性の側で損をします。

対策は、切り戻せる状態を先に作ることです。適用前のスナップショット、設定ファイルのバックアップ、切り戻し手順書。この3つがあれば、緊急適用の判断は速くなります。 逆に、戻せない構成では「当てて壊れたらどうする」の議論が毎回発生し、結局遅くなります。

保守契約の SLA をどう決めるかを検討する際は、適用時間の数字と同じ重さで、切り戻し手順の有無を項目に入れてください。速度を約束できるかどうかは、実際にはここで決まります。

次にやること

まず、自社の保守契約書で「セキュリティパッチ」がどう書かれているかを確認してください。 「月次」「速やかに」といった文言なら、見直しの候補です。時間数で書かれているなら、その時間で足りるかを上記の区分で検討します。

そのうえで、脆弱性情報の通知が誰に届いているかを確認してください。 個人アドレス宛なら、共有の受け口に変えるだけで実効的な対応時間が縮みます。

保守体制の設計、脆弱性対応フローの整備、既存システムの構成把握については、グリームハブの開発・AI・自動化のご相談で承っています。システム構成と現在の保守体制によって取れる手が変わるため、個別にご相談ください。お問い合わせからどうぞ。

Sources

• N-day is Becoming N-Hour. Patching Faster Won’t Save You. — The Hacker News
• AI-Driven Vulnerability Surge Breaks the Traditional Patching Model — SecurityWeek
• The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization — Cloud Security Alliance
• When exploits move in hours, patching must move faster — N-able
• AI is shrinking the time to patch software vulnerabilities — Axios