Project Glasswing: Mythos PreviewによるAI駆動型脆弱性調査のスケールアップ
サイバーセキュリティ向けに特別にチューニングされたフロンティアモデルの登場は、汎用AIアシスタントから、複雑な推論が可能な専門ツールへの転換を意味しています。Cloudflareは最近、Project Glasswingに参加し、AnthropicのMythos Previewを活用して自社の50以上のリポジトリを分析しました。その目的は、単にバグを見つけることだけでなく、これらのモデルがいかに脆弱性の悪用可能性（exploitability）について推論するか、そしてそれらを大規模に効果的に展開するために必要なインフラをどのように構築するかを理解することにありました。
能力の飛躍：単純なバグハンティングを超えて
Cloudflareの調査結果によると、Mythos Previewは単なる以前のモデルの改良ではなく、能力における根本的な転換を表しています。汎用モデルは孤立したバグを特定できることが多いものの、疑わしい欠陥と動作するエクスプロイトの間のギャップを埋めることに苦労するのが一般的です。Mythos Previewは、以下の2つの重要な領域で優れています：
- エクスプロイトチェーンの構築: 実世界の攻撃は、単一の脆弱性に依存することは稀です。Mythos Previewは、複数の低深刻度のプリミティブ（例えば、use-after-freeバグを任意の読み取り/書き込みプリミティブに変換するなど）をどのように連鎖させて制御フローを乗っ取り、システム全体の制御権を取得するかについて推論できます。この推論プロセスは、シニアセキュリティリサーチャーのプロセスを模倣しています。
- PoC（概念実証）の生成: モデルは推測で止まりません。バグをトリガーするコードを書き、スクラッチ環境でコンパイルし、実行することができます。実行に失敗した場合、モデルはエラーを分析し、仮説を調整して、PoCが確立されるまで反復を行います。
「有機的な拒絶」とノイズの課題
標準的な商用セーフガードのない制御された研究環境においてさえ、Mythos Previewは「有機的な拒絶（organic refusals）」を示しました。モデルは、正当なセキュリティ研究の要求に対して時折拒絶反応を示しましたが、これらの拒絶は一貫していませんでした。ある文脈で拒絶された要求が、言い換えられたり環境がわずかに変化したりすると受け入れられることもありました。
さらに、Cloudflareは持続的な「信号対ノイズ（signal-to-noise）」の問題を特定しました。AIモデルは、バグが存在しない場所でもバグを見つけようとするバイアス（傾向）を持つことが多く、「潜在的に」や「理論上は可能」といった曖昧な言葉を頻繁に使用します。このノイズはプログラミング言語によって悪化します。CやC++のようなメモリ非安全な言語は、Rustのようなメモリ安全な言語よりも大幅に多くの偽陽性（false positives）を生成します。
なぜ汎用コーディングエージェントは大規模展開に失敗するのか
Cloudflareは、単に汎用コーディングエージェントをリポジトリに向けるだけでは、包括的な脆弱性調査には不十分であることを発見しました。主に2つのボトルネックが存在します：
- コンテキストの制限: コーディングエージェントは線形的なタスク（機能構築やバグ修正）向けに設計されています。脆弱性調査は並列的かつ局所的です。単一のエージェントセッションは、攻撃対象領域（attack surface）のほんの一部をカバーする前に、コンテキストウィンドウを使い果たしてしまうことがよくあります。
- スループットの制約: 単一ストリームのエージェントでは、大規模なコードベースに対して必要な仮説の量を処理できません。モデルの生の知能に関わらず、インタラクションモデル自体がボトルネックとなります。
解決策：多段階のディスカバリー・ハーネス
これらの制限を克服するために、Cloudflareは、複数の専門化されたエージェントの実行を管理する構造化されたハーネスを開発しました。このアーキテクチャは、チャットインターフェースから、狭く並列的なタスクのパイプラインへと移行します：
| Stage | Action | Purpose |
|---|---|---|
| Recon | Top-down repository analysis | アーキテクチャドキュメントとタスクキューを作成し、「迷走」を防ぎます。 |
| Hunt | Parallel attack-class searches | 50以上の同時実行エージェントがスクラッチディレクトリを使用してバグを特定し、PoCを生成します。 |
| Validate | Adversarial review | 独立したエージェントが、ノイズを減らすために発見事項の妥当性を否定しようと試みます。 |
| Gapfill | Coverage analysis | 接触はしたが、徹底的に調査されていない領域を再キューに入れます。 |
| Dedupe | Root cause collapse | キューの膨張を防ぐため、同じ原因を共有する発見事項を統合します。 |
| Trace | Reachability analysis | 攻撃者が制御する入力が、システムの外部から実際にバグに到達できるかを確認します。 |
| Feedback | Loop closure | 到達可能なトレースは、コンシューマーリポジトリにおける新しいHuntタスクになります。 |
| Report | Structured output | 定義済みのスキーマに従って、発見事項をデータをクエリ可能にします。 |
セキュリティチームへの戦略的示唆
脆弱性をより速く見つける能力は、セキュリティチームにとって、SLA（サービスレベル合意）を短縮するという危険な誘惑を生み出します。一部の報告では、CVEリリースからパッチ適用までの時間を2時間以内とするものもあります。しかし、Cloudflareは、速度だけでは不十分であると警告しています。回帰テスト（regression testing）が1日かかる場合、2時間のSLAは重要なチェックをスキップすることになり、結果としてより悪質なバグをグローバルに展開することにつながります。
代わりに、パッチ適用の速度だけに焦点を当てるのではなく、**建築的レジリエンス（architectural resilience）**に重点を置くべきです。これは、バグが存在してもエクスプロイトを困難にすることです。これには、バグへの到達をブロックする防御策の実装、システムコンポーネント間の厳格な分離、およびグローバルな修正を即座に展開できる能力を確保することが含まれます。
コミュニティの視点
技術的なフレームワークは堅牢ですが、コミュニティの観察者からは、結果の透明性に関する疑問が提起されています。Hacker Newsのユーザーは、一部の投稿では、発見された脆弱性の総数やその深刻度レベルに関する生データが不足していると指摘しています。また、他のユーザーは、長期的な解決策は、モデルのガードレール（ガードレール）ではなく、モデルがエクスプロイトを検索するためにフロンティアLLMによって解析されることを前提とした、ソフトウェアの書き方の根本的な転換であると主張しています。