【AI×セキュリティ】AIで脆弱性の悪用が速くなる｜「パッチは月1回まとめて」では間に合わない？を解く

【AI×セキュリティ】AIで脆弱性の悪用が速くなる｜「パッチは月1回まとめて」では間に合わない？を解く AIセキュリティ

「プラグインや OS の更新は、月に 1 回まとめてやっています」「脆弱性の情報が多すぎて、どれから直せばいいか分からない」——小さなチームでサイトやサーバを運営していると、こうした声をよく聞きます。

ところが、ここ数年で前提が変わりつつあります。AI によって、攻撃側が脆弱性を調べて悪用するまでの時間が短くなると、各国の公的機関が相次いで警告しているのです。「うちのような小さなサイトは狙われない」という考えも、通用しにくくなっています。

この記事では、英国 NCSC と米国 CISA の公開資料、そして攻撃の速さや優先順位付けを測った研究をもとに、「何から・どれくらいの速さで直すか」を運営者の目線で整理します！

何が速くなったのか

英国の国家サイバーセキュリティセンター（NCSC）は 2025年5月の評価で、脆弱性の公表から悪用までの時間はすでに「数日」に縮んでおり、AI がこれをさらに短くすることはほぼ確実だと見ています。これは今後の脅威についての評価（予測）で、AI による短縮を実測した結果ではありません。2027年までに AI を使ったツールが既知の脆弱性を悪用する能力を高め、セキュリティ修正を適用していないシステムへの攻撃が増えるとも見ています。さらに、AI を使った脅威に追随できるシステムと、取り残されて脆弱なままの多くのシステムとの間に「格差」が生まれることもほぼ確実だとしています（NCSC「Impact of AI on cyber threat from now to 2027」）。

米国の CISA も、2026年6月に出した連邦機関向けの拘束力のある運用指令 BOD 26-04 の背景説明で、攻撃者による AI の利用が、パッチの公開から悪用までに防御側が対応できる時間をさらに縮めうると書いています（CISA「BOD 26-04」）。

📄 論文: 「後追いの組織」が受ける影響

Uplifted Attackers, Human Defenders: The Cyber Offense-Defense Balance for Trailing-Edge Organizations（Benjamin Murphy ほか、2025年8月、arXiv:2508.15808）は、査読前の論文（プレプリント）です。独自の実験や計測ではなく、既存の調査や事例をもとに議論を組み立てて主張する論文です。

著者らは、古いソフトウェアに頼り、セキュリティの人手が足りず、パッチを素早く当てられない組織を「trailing-edge（後追いの）組織」と呼びます。こうした組織は「経済的にうまみがないから狙われないだろう」という計算で守りへの投資を抑えてきたかもしれない、と指摘します。そのうえで AI の進歩は、攻撃 1 回あたりのコストを下げて、より多くの攻撃者がより頻繁に狙ってくるようにし、さらに攻撃の準備を早めるため、今の先進的な組織に追いつくだけでは足りず、修正までの時間をもっと縮める必要がある、と論じています。

運営者にとっての意味は、「小さいから狙われない」は AI の時代には当てにできず、修正の速さそのものを上げる必要があるということです。

📄 論文: 重大な脆弱性への悪用の試みは、公開から数日で始まった

Internet-Scale Measurement of React2Shell Exploitation Using an Active Network Telescope（Aakash Singh ほか、2026年3月、arXiv:2603.12300）は、査読前の論文（プレプリント）です。2025年12月3日に公開された、Web 開発で広く使われる React の Server Components の重大な脆弱性（CVSS 基本値 10.0）について、インターネット上の観測点に届いた悪用の試みを計測しました。

悪用の試みは公開直後から急速に増え、自動化されたスキャンの特徴を示していました。本文によると、観測点に悪用の試みが最初に届いたのは公開から 2 日後の 2025年12月5日で、観測期間中に 735 の異なる送信元 IP アドレスが確認されました（本文 IV 章）。CISA の KEV カタログにも、同じ 12月5日に登録されています（CISA「Known Exploited Vulnerabilities Catalog」）。

これは研究用の観測点に届いた通信を測ったもので、すべての実サイトが同じように狙われたとまでは言えません。それでも運営者にとっての意味は、広く使われる部品の重大な脆弱性には、公開から数日で自動化された試みが始まりうるということです。月 1 回の更新だけでは、その間が無防備になりかねません。

📄 論文: AI エージェントは Web の脆弱性をどこまで悪用できるか

CVE-Bench: A Benchmark for AI Agents’ Ability to Exploit Real-World Web Application Vulnerabilities（Yuxuan Zhu ほか、2025年3月、arXiv:2503.17332）は、査読前の論文（プレプリント）で、2025年6月に第 4 版へ改訂されています。深刻度が「緊急（Critical）」の実在する脆弱性をもとに、現実に近い Web アプリの検証環境を作り、AI エージェントがどこまで悪用できるかを評価しました。

最新版の抄録によると、最先端のエージェントの仕組みでも、ベンチマーク上の脆弱性のうち悪用に成功したのは最大 13% でした。

運営者にとっての意味は、今すぐ「AI が何でも自動で攻撃する」わけではないものの、能力を測る物差しができ、伸びを追える状態になったということです。

📄 論文: 自律的な侵入の能力は、モデルの進歩とともに伸びている

The Emergence of Autonomous Penetration Capabilities in Large Language Model-Powered AI Systems（Jiaqi Luo ほか、2026年6月、arXiv:2606.13079）は、査読前の論文（プレプリント）です。脆弱なサービスを含む標的サーバ 300 台を用意し、事前知識を与えない汎用のエージェントの仕組みで、19 種の LLM が人の介入なしに侵入できるかを評価しました。

侵入の成功率はモデルによって 10.7% から 69.3% まで幅があり、モデル全体の能力が上がるにつれて侵入の能力も上がっていく傾向が見られました。前の論文とは条件が違うので、数字をそのまま比べることはできません。

これは評価環境での傾向で、実環境での攻撃の増加を測ったものではありません。運営者にとっての意味は、モデルの能力が上がれば攻撃の自動化も進みうる、と見込んで備えておくべきだということです。

📄 論文: CVSS の高い順より「悪用が確認されたか」を先に

KEVGraph: Exploitation-Aware Dependency Vulnerability Remediation（Daniel Okumu Omondi、2026年9月、arXiv:2609.24164）は、著者 1 人による査読前の論文（プレプリント）です。npm（JavaScript のパッケージ管理）を使う実在の 924 リポジトリで、依存パッケージの更新をどの順番で行うかを比べました。

この標本では、著者らが比較用に組んだ「CVSS の高い順」の計画だと、CISA の KEV カタログに載っている（悪用が確認された）脆弱性の最初の修正が 18 手目まで後回しになりました。KEV を考慮した計画では 1 手目で解消でき、更新の総数もわずかに少なくて済みました。特定の標本と計画方式での結果である点には注意が必要です。なお、論文は背景として以前の指令 BOD 22-01 を参照していますが、BOD 22-01 は 2026年6月に後述の BOD 26-04 に置き換えられています。

運営者にとっての意味は、深刻度の数字だけで並べると、本当に急ぐべきものが埋もれてしまうということです。

優先順位の考え方：CISA BOD 26-04 の段階制

CISA の KEV カタログは、CISA が実環境での悪用を確認した脆弱性の一覧です。登録は「悪用が確認された」ことを示すもので、すべてが今も攻撃され続けているという意味ではありません。2026年9月30日公開の版で 1,730 件が登録されています（2026年10月1日に確認）。CISA は、あらゆる組織が脆弱性管理の優先順位付けの入力として KEV を使うよう呼びかけています（CISA「Known Exploited Vulnerabilities Catalog」）。

2026年6月10日に出た BOD 26-04 は、KEV への対応を定めた BOD 22-01 と、インターネットに面したシステムの修正期限を定めた BOD 19-02 を廃止して、一本化しました。実施は段階制で、方針の見直しなどは即時、手順の更新は 60 日以内、下の表の期限に沿った修正は 180 日以内に始まる段階に置かれています。修正期限は、次の 4 つの判定項目の組み合わせで決まります（CISA「BOD 26-04」）。

  • Publicly Exposed（公開されているか）: インターネットなどの公的なネットワークを通じて、認証されていない、または信頼されていない相手からアクセスできるか
  • In the KEV（KEV に載っているか）
  • Automatable（悪用を自動化できるか）: 攻撃者が悪用の全手順を自動化できるか
  • Technical Impact（技術的な影響）: 悪用後に得られるのが Partial control（部分的な制御）か Total control（完全な制御）か

指令の表 1 は、この 16 通りの組み合わせすべてに期限を割り当てています。並べ直すと次のとおりです（日数は暦日。「＋調査」は侵害の有無を調べるフォレンジック調査も求めるもの）。

Publicly Exposed／In the KEVAutomatable はい・Totalはい・Partialいいえ・Totalいいえ・Partial
はい／はい3 日＋調査3 日3 日＋調査14 日
はい／いいえ3 日14 日14 日60 日
いいえ／はい3 日＋調査14 日14 日14 日
いいえ／いいえ60 日60 日次のシステム更新時次のシステム更新時

期限は、CISA が KEV に登録した時点か、機関が自分の資産で脆弱性を見つけた時点の早いほうから数えます。新たに KEV に載れば期限は短くなります。

この指令は米国の連邦文民行政機関のシステムが対象で、国家安全保障システムなどは除かれ、請負業者も契約で定めない限り対象外です。日本の企業に義務を課すものではなく、この表も個々の会社の修正期限を定めるものではありません。それでも「外から届き、悪用が確認され、自動化できて影響の大きいものは日単位で」というメリハリは参考になります。自社では、この考え方を借りて、リスクに応じた目標時間を自分で決めましょう！

運営者のやること

1. 自分が何を使っているか一覧にする

CMS 本体・プラグイン・テーマ、サーバの OS やミドルウェア、ルーターや VPN 機器など、インターネットに面しているものを書き出します。BOD 26-04 も、外から届く資産を見つけて印を付けることを求めています。一覧がないと、脆弱性の情報が出ても「うちに関係あるか」をすぐに判断できません。

2. 自動更新を味方にする

WordPress の場合、5.6 以降の新規インストールでは本体のメジャー・マイナー両方の更新が既定で自動になりますが、それ以前からのサイトはマイナー更新だけが既定です（WordPress Developer Resources「Upgrading WordPress」）。プラグインとテーマは 5.5 以降、管理者が一つずつ自動更新をオンにする方式です（WordPress.org「Plugins and themes auto-updates」）。使っていないプラグインは停止でなく削除し、守る対象そのものを減らしましょう（Hardening WordPress）。戻せるバックアップも忘れずに。

3. 「悪用が確認されたか」を毎日の確認に入れる

月 1 回の定期更新は続けつつ、「悪用が確認された脆弱性」だけは別枠ですぐ当てる二段構えにします。KEV の更新通知に加え、日本語なら IPA の「重要なセキュリティ情報」が使えます。IPA は、影響が大きく実際に悪用された攻撃が確認されているものに「緊急」の区分を付けています（IPA「重要なセキュリティ情報」）。自分の一覧にある製品に「緊急」や KEV 登録が出たら、その日のうちに対応を始めるくらいの感覚が目安です。

4. すぐ直せないときは時間を稼ぐ

検証に時間がかかる、制作会社の対応を待つ、といった場合は、WAF で既知の攻撃を止める「仮想パッチ」で時間を稼ぎます。OWASP は、仮想パッチの目的を修正までの時間の短縮と攻撃面の縮小とし、コードの修正と対立するものではなく並行して進めるものだと説明しています（OWASP「Virtual Patching Cheat Sheet」）。AI を守る側で使い、脆弱性を自分で見つける取り組みについては、LLM の企業活用事例の記事も参考にしてください。

パッチ運用の鍵は次の3点です

  1. 「月 1 回まとめて」に、悪用が確認されたものの別枠を足す
    公開から数日で自動化された悪用の試みが始まった例が出ています。定期更新とは別に、悪用が確認されたものはすぐ当てる経路を作りましょう。
  2. CVSS より先に「悪用が確認されたか」「外から届くか」を見る
    KEV や IPA の「緊急」に載ったもの、インターネットに面したものから直します。深刻度の数字だけで並べると、急ぐべきものが埋もれます。
  3. 一覧・自動更新・時間稼ぎで速さを底上げする
    何を使っているかを把握し、自動更新できるものは任せ、すぐ直せないものは仮想パッチでつなぎます。

まとめ：AIの時代のパッチ運用は「全部を速く」ではなく「急ぐものを見分けて速く」！

AI によって、脆弱性の公表から悪用までの時間はさらに縮むとみられています。研究でも、重大な脆弱性への悪用の試みが公開から数日で観測され、評価環境では AI の攻撃能力がモデルの能力とともに伸びる傾向が報告されています。とはいえ、すべてを 3 日で直す必要はありません。BOD 26-04 のように「外から届くか」「悪用が確認されたか」で優先順位を付ければ、限られた人手でも急ぐべきものに集中できます。まずは使っているものの一覧づくりから始めてみましょう！

参考文献

タイトルとURLをコピーしました