Agentic Exploitationの台頭：なぜ噂がゼロデイを引き起こすようになったのか

従来のセキュリティの秘密保持（バグを非公開で修正し、公開発表前にユーザーに通知する慣行）は、もはや役に立たなくなっている。現代の脅威環境では、脆弱性に関する噂や、公開されたプルリクエスト（PR）の開設というわずかな兆候さえも、AIエージェントが数分以内に自律的に脆弱性を発見し、攻撃を実行するための十分なシグナルとなる。

セキュリティの秘密保持の崩壊

AIエージェントは、脆弱性の発見から攻撃までのタイムラインを劇的に短縮した。最近の事例では、OCamlの cohttp 6.3.0 におけるパストラバーサル問題について、修正用の公開PRを開いた直後（10分以内）に、メンテナーサーバー上で実際に攻撃の探査が観測された。

このスピードは、最先端のLLMが自律的な調査を可能にしていることに起因する。たとえば、パス正規化に関するヒントといった広範な方向性が与えられれば、エージェントは自ら脆弱性の正確な位置を特定し、動作する攻撃コードを生成できる。この変化は、いくつかの重要なトレンドによって裏付けられている：

攻撃までの平均時間（MTTE）が負値に： 2026年のデータによると、攻撃までの平均時間はゼロを下回り、攻撃が公式パッチの公開よりも先に発生することが頻繁になっている。2018–19年にはこの指標は約63日だった。
アドバイザリから攻撃への急速な変換： 最近のCVE（例：marimoの CVE-2026-39987、Langflowの CVE-2026-33017）では、公開されたPoC（概念実証）がなくても、攻撃試行が9～20時間以内に観測された。
最小限のデータからの高い成功率： Fangらの研究によると、GPT-4エージェントはCVEの説明が与えられれば15件の脆弱性ベンチマークのうち87%を攻撃可能だが、説明がなければわずか7%にとどまる。これは、高レベルの説明さえも、自動攻撃を促進する強力な触媒であることを示している。

「バグノミクス」という概念

LLMが脆弱性の検出と攻撃コードの生成を自動化する中で、ソフトウェアセキュリティのボトルネックは「バグの発見」から「防御側の修正処理のスループット」へと移行した。この現象を「バグノミクス」と呼ぶ。これは、攻撃者が機械的なスピードで攻撃コードを生成できる一方で、人間主導の検証・優先順位付け・持続可能な修正のリリースプロセスは一向に進んでいないという、深刻な不均衡を浮き彫りにする。

OSSメンテナーや独立開発者は特に脆弱である。彼らは攻撃者と同じ最先端エージェントにアクセスできないことが多く、商業モデルのセキュリティガードレールによってAIの利用が制限されている。一方で、Project Glasswingのような取り組みは一部の組織に高レベルなAIアクセスを提供しているが、多くの独立メンテナーは、自らの防御的パッチ作成をAIで加速する手段を失っている。

現代の防御のための提案戦略

Agenticな攻撃に対抗するためには、手動の優先順位付けや秘密保持にとどまらず、より動的な防御メカニズムへと移行する必要がある。

1. プライベートなパッチ開発と信頼ネットワーク

AI監視ツールから完全に隔離された環境で修正を開発することは不可欠である。しかし、現在のツール（例：GitHubの一時的なプライベートフォーク）は、メンテナーがCI/CDパイプラインから切り離されてしまうため、しばしば不十分である。より堅牢な解決策として、「信頼ネットワーク（web-of-trust）」インフラを構築し、一般公開せずに信頼できる貢献者間で脆弱性情報を安全に共有する仕組みが考えられる。

2. コンティニュアス・シッピングと自動トリアージ

露出期間を短縮するには、継続的リリースモデルへの移行が必要である。これには以下が含まれる：

動的パッチ適用： 再起動なしで実行時中にバイナリを交換できる仕組み（Chromeの週次更新と同様）を実装する。
エコシステム横断のパッケージ管理： ライブラリが下流製品に埋め込まれている場所を追跡する能力を向上させ、更新がより迅速に伝播するようにする。
自動トリアージツール： Scrutineerのようなツールを活用し、機械生成のバグ報告の増加に対応する。

3. プロトコル層での予防的保護

完全なパッチをパッケージ化・配布するのを待つのではなく、防御側はプロトコル層で「仮想パッチ（virtual patching）」を実装できる。たとえば、パストラバーサルの脆弱性は、下位ライブラリが更新される前に、エッジ（CDNやゲートウェイ）でパーセントエンコードされたパス区切り文字を正規化するルールを即座にデプロイすることで、即座に緩和できる。

コミュニティの見解と反論

メンテナー間の技術的議論から、問題は技術的側面だけでなく、システム全体の構造的課題にあることが明らかになっている。一部の意見では、攻撃コードの開発が民主化されたことで、低スキルの攻撃者が同時にインターネット全体を標的にできるようになったと指摘している。

"パッチやコミットメッセージ、あるいは偶然聞こえた言葉から攻撃PoCを逆算することは、脆弱性研究の歴史と同様に古くから存在する。LLMの登場による違いは、『十分なスキルを持つ』（人間でも非人間でも）攻撃者が爆発的に増加したことで、これまで不可能だった『インターネット全体を攻撃する』ような粗雑な／低スキルな攻撃者が可能になった点にある。"

他のメンテナーは、報告件数の著しい増加を報告しており、rcloneのメンテナーの一人は、10年間で20件のセキュリティ報告があったのに対し、1か月で40件以上に急増したと述べている。また、「マイクロアップデート」の推進が新たなリスクを生む可能性にも懸念が示されている。たとえば、更新メカニズム自体がリモートコード実行の攻撃ベクトルになる可能性があり、極めて注意深く設計されない限り、逆効果になる恐れがある。

今後の研究課題

これらの課題に対処するには、ソフトウェアの強制実行に関する新しいアーキテクチャ的アプローチが必要となる。提案される研究方向には以下がある：

防御用テストベッド： MirageOSなどを用いて、脆弱性に関する噂に基づいて自動的に緩和ルールをデプロイできるゲートウェイを構築する。
強制自動機： Leanなどの形式仕様をコンパイルし、実行時自動機として、ファイルシステムおよびネットワーク層でライブラリが実行できる範囲を厳密に制限する仕組みを構築する。これにより、特定の攻撃が知られていない場合でも、全体的な脆弱性クラスを無効化できる。