「パッチが出てから対応していたのでは、もう間に合わない」

今回は、悪用までの時間が劇的に短くなった現実と、
「悪用前提」で脆弱性対応をどう設計し直すかを整理します。

1. 悪用までの猶予が「数週間→数日」に崩壊した

数字がすべてを物語っています。

  • 脆弱性の公開から悪用までの平均時間は、わずか2年前の 32日から、5日へ短縮
  • 悪用の約3分の1は、公開から24時間以内に発生
  • それでも多くの組織は、重大な脆弱性のパッチ適用に平均97日かかっている

「悪用まで5日、対応に97日」——この差が、そのままリスクの窓です。
さらに深刻なのは、悪用がパッチ公開より先に起きるケースすら珍しくなくなったことです。

背景にあるのがAIです。
AI支援によって、攻撃者が脆弱性を特定・武器化・悪用する時間が大幅に短縮されています。
このスピードを受け、インドのCERT-Inは、インターネット公開システムの重大脆弱性を
「実行可能な限り12時間以内」にパッチせよという新ガイドラインを出したほどです。

2. もう一つの変化：「第三者ソフト」が主な侵入口に

侵入経路の構図も変わりました。

2026年の調査では、攻撃者は第三者ソフト由来の脆弱性（44.5%）を、
弱い認証情報（27.2%）よりも頻繁に悪用しています。

自社で書いたコードよりも、組み込んだライブラリ・OSS・ベンダー製品の脆弱性が狙われる時代です。
つまり「自分たちが何を使っているか」を把握できていないと、そもそも守れません。

3. 設計を「パッチ管理」から「悪用前提の防御」へ

ここで重要なのは、努力でパッチを速くする話ではない、ということです。
人手で97日を5日に縮めるのは不可能です。設計と仕組みで対応する必要があります。

考え方を3層に分けます。

層1：何を使っているかを常に把握する（SBOM）
ソフトウェア部品表（SBOM）をイメージのバージョンごとに署名付きで発行し、全コンポーネントをインデックス化する。
上流でCVEが公開されたら、影響を受けるシステムを即座に特定できる状態を作る。
「どこに何があるか分からない」状態では、5日では動けません。

層2：パッチが間に合わない間を「仮想パッチ」で稼ぐ
WAF・IPS・ランタイム保護などで、パッチ適用前に悪用そのものをブロックする。
正式パッチを当てるまでの危険な窓を、一時的な緩和策で塞ぐ発想です。
「直す」と「防ぐ」を切り離すことで、テスト・展開の時間を安全に確保できます。

層3：迅速な対応プロセスを事前に用意する
緊急時の一時緩和・加速テスト・迅速なロールバック手順を、平時に設計しておく。
SBOM連携でビルドパイプラインを自動再構築できれば、対応時間は数週間から数時間に縮みます。
インシデント時に手順を考えているようでは間に合いません。

4. 優先順位の付け方

すべてを12時間で当てるのは非現実的です。だからこそ優先順位が要ります。

  • インターネット公開資産を最優先（攻撃者から見える＝即狙われる）
  • 悪用が既に観測されている（KEV等）脆弱性を最優先
  • 第三者コンポーネントはSBOMで影響範囲を即特定し、当たりを付ける
  • 内部限定・悪用困難なものは計画的対応に回す

「全部すぐ」ではなく「危ないものから確実に」。リスクベースで絞ることが、限られた人手で回す鍵です。

5. 目指す状態

脆弱性対応を、こう設計し直します。

  • SBOMで「何を使っているか」を常時把握し、CVE公開時に影響範囲を即特定
  • 仮想パッチでパッチ適用前の危険な窓を塞ぐ
  • 緊急対応手順を平時に用意し、対応を数時間単位に短縮
  • インターネット公開資産・既知悪用脆弱性をリスクベースで優先

「パッチを速く当てる努力」から、「悪用されても困らない仕組み」へ。
これが、悪用が数日で起きる時代の現実的な防御です。

6. Colorkrew Securityの考え方

「パッチが出たら計画的に当てる」は、もはや前提が成立しません。
悪用は数日、ときにパッチより先に来ます。

人の努力でスピードを上げるのではなく、
把握（SBOM）・遮断（仮想パッチ）・即応（事前設計）という仕組みで時間を稼ぐ。
これは権限やアカウントの記事と同じ——「人の頑張りに依存しない設計」こそが答えです。

参考にした最新記事