30日周期でパッチを当てるやり方は、すでに成り立たなくなっています。ほとんどのセキュリティチームは、そのこと自体はもう分かっています。なぜ成り立たなくなったのか、そして何に置き換える必要があるのか、という点までは理解が及んでいません。SC Mediaは先ごろ、まさにこの転換をめぐって、さまざまな立場のセキュリティ責任者を集めました。そこで語られた状況は、厳しいものでした。

AIは、もともと膨大な数にのぼる脆弱性を、さらに増やしただけではありません。開示から悪用までの時間を、数週間から数時間へと縮めました。Microsoftが7月に公開した修正プログラムは、1回のPatch Tuesdayで600件を超える不具合を修正しました。その前月にも、過去最多となる206件の欠陥を修正したばかりでした。同じ週、CISAはOracle E-BusinessとMicrosoft SharePointに対して緊急のパッチ適用を命じ、調査員は、着手から完了まで24時間足らずで実行された一連のランサムウェア攻撃を記録しています。
　Cloud Security Allianceの最近の調査は、この危うさを数字で示しています。重大な脆弱性を24時間以内に修復している組織は、わずか9%です。修復に4日から7日を要するチームのうち97%は、その期間中に既知の脆弱性に結び付いたインシデントを報告しています。脆弱性が公表されてから悪用されるまでの時間は、短くなりつつあるのではありません。すでに無くなっているのです。
　この数字を前にすれば、アナリストを増やすことも、労働時間を延ばすことも、はじめから解決策になりえなかったと分かります。答えは、何かにパッチを当てる前に、本当に重要なものはどれかを決めておくことです。

パッチを当てているものの大半は、はじめから脅威ではなかった

　どのスキャナーでも、「重大」と判定される検出結果が大量に並びます。しかし、そのうち自社の環境で到達可能なものは、ごくわずかです。実際のネットワークトポロジーとコードの経路まで踏まえると、本当に悪用できる検出結果は1%程度だと、セキュリティ研究者は見ています。
　Mend Reachability Analysisは、この見立てに基づいて作られています。問うのは、脆弱性が深刻かどうかではありません。リスクを実際に決めるのは、攻撃者の経路が実行時にこのコードへ到達できるかどうかです。一度も呼び出されない関数のなかにある重大なCVEは、深刻な問題ではありません。逆に、インターネットに公開された入口にある中程度のCVEの方が、深刻な問題です。
　CVSSだけに頼ったトリアージが破綻するのは、この点です。National Vulnerability Databaseは、ほとんどのCVEについて、詳細情報の付与をやめました。そのため深刻度スコアだけでは、実際に悪用されているもののおよそ3分の1を、いまでは見落とすことになります。一方、到達可能性を、CISAのKnown Exploited Vulnerabilities（KEV）カタログやEPSSスコアリングといったエクスプロイトインテリジェンスと組み合わせれば、長いリスクの一覧ではなく、短くまとめられたリスクの一覧を渡すことができる。攻撃者が触れられないコードに急いでパッチを当てるのは、最も足りていない人手と時間を、誤った対象に費やすことにほかなりません。

対策は、社内のチケット処理のペースではなく、脆弱性が公開されるスピードに合わせなければならない

　脆弱性対応のワークフローに関する最近の調査では、74%の組織が依然として対策の半分以上を手作業で行っていました。完全に自動化できていると答えたのは、わずか7%です。チームが自動化したのは警報であって、対応ではありません。ここが本当のボトルネックです。対策の進め方も変えなければ、AIが生み出す検出は、積み残しを減らすどころか増やすことになります。
　解決策は、より短いカレンダーによるカレンダー基準のパッチ適用ではありません。必要なのは、検知し、優先順位を付け、対処し、検証するという流れを絶えず繰り返す、閉じたループです。このループを回すために作られているのが、Mend Remediateです。
　優先順位付けでは、エクスプロイト、攻撃にさらされている状態、そして事業の状況を組み合わせる必要があります。CVSSの数値を単独で用いるのではありません。リスクが低く、繰り返し行える修正は、一件ごとに人がクリックして承認しなくても進むよう、あらかじめ許可しておく必要があります。利用できるパッチがない場合、チームには直ちに使える代替手段―仮想パッチ適用、設定の変更、あるいはベンダーを待たずに攻撃経路を閉じるセグメンテーションの規則―が必要です。そして、チケットを処理することと、攻撃にさらされている状態を解消することは、同じではありません。どの修正についても、環境内のリスクが実際に解消されたことを、自動の再スキャンで確かめる必要があります。
　こうした仕組みは人の判断を支援するものであって、人に取って代わるものではありません。ポリシーの策定やリスク許容度の判断、例外対応は引き続き人が担う必要があります。AIは、自ら検証できる定型的な作業を担うことで、人が本来注力すべき意思決定に集中できるようにします。

依存関係の更新を、四半期に一度のプロジェクトにしてはいけない

セキュリティチームがパッチを当てている対象のかなりの部分は、そもそもアプリケーションのコードではありません。アプリケーションの裏に隠されたOSSの依存関係です。これらは、チームが注目しているかどうかにかかわらず、それぞれのペースで絶えず更新されていきます。
　Mend Renovateは、この更新のパイプラインを、断続的なものではなく継続的なものに保ちます。四半期ごとに依存関係をまとめてアップグレードするプロジェクトでは、出荷の時点で更新がすでに古くなっています。そうではなく、更新が絶えず提案され、テストされ、マージされていきます。その範囲は、実際に変更しても安全なものに絞られます。到達可能性のデータと組み合わせれば、Renovateは依存関係ツリーをアルファベット順に処理するのではなく、悪用可能な経路を閉じる更新から先に手を付けられます。
　これによってパッチ管理は、定期的に慌ただしく対応する作業から、常に動き続ける仕組みへと変わります。更新のパイプラインは、今週のCVE件数が記録を更新するかどうかにかかわらず動き続けます。

判断を伴わずにスピードを上げても、リスクを別の場所へ移すだけである

この転換に最もうまく対応できているのは、最も速くパッチを当てているチームではありません。2つの問いに、数日ではなく数分で答えられるチームです。これは到達可能なのか。そして、いまそれは重要なのか。実際の修正を含めた残りのすべては、この2つの問いに正しく答えることから決まります。
　だからこそ、到達可能性、自動化された依存関係の管理、そして継続的な修復は、後からつなぎ合わせた3つの別々のツールではなく、ひとつのつながったシステムとして扱う必要があります。AIによって、推測に頼ることの代償は大きくなりました。しかし、判断の必要性をなくしたわけではありません。AIは、判断のタイミングを早めただけです。担当者がようやく対応に取りかかる段階ではなく、検出結果が出た時点で判断するようになったのです。
　パッチを当てるまでに与えられていた猶予は、もう戻ってきません。うまく適応しているチームは、猶予がないことを前提に、仕組みを作り上げています。