プロジェクト・グラスウィング：ミトスが示したもの

過去数ヶ月にわたり、私たちは自社のインフラ上でセキュリティ指向のLLM（大規模言語モデル）をいくつかテストしてきました。これらのLLMは、自社システムの潜在的な脆弱性を特定し、修正するための支援を行うだけでなく、最新のモデルを用いた攻撃者が何ができるかを示すものでもあります。 これらの中で最も注目を集めているのは、Anthropic社のMythos Previewです。数週間前、私たちはProject Glasswingの一環としてMythos Previewの使用を招待されました。すぐに、五十以上の自社リポジトリに対してこのツールを適用し、何が検出されるか、またどのように動作するかを確認しました。 本稿では、私たちが観察した結果、モデルが得意とした点と不得意な点、そして大規模運用に際してアーキテクチャやプロセスにおいて何を変更する必要があるかを共有します。 Mythos Previewにおける変化 Mythos Previewは明確な前進であり、これ以上の詳細に入る前にその点を率直に述べる価値があります。私たちはこれまで数ヶ月にわたり自社のコードに対してモデルを走らせてきましたが、以前の汎用型フロンティアモデルで可能だったことと、今日Mythos Previewが実現していることの間の飛躍は、単なる前世代の改良ではなく、全く新しい段階です。 これは異なる種類のツールであり、異なる種類の作業を行うものであるため、以前のモデルとの明確な対比比較は困難です。したがって、Mythos Preview を汎用最先端モデルに対してベンチマークしようとするよりも、実際に何ができるのかを記述する方が有用です。私たちが Mythos Preview と行った作業全体で際立った 2 つの特徴があります。 エクスプロイトチェーンの構築 - 実際の攻撃は単一のバグを使用することはめったにありません。いくつかの小さな攻撃プリミティブを結合して、動作するエクスプロイトを作成します。例えば、use-after-free バグを任意の読み書きプリミティブに変換し、制御フローを乗っ取り、return-oriented programming (ROP) チェーンを使用してシステム全体を完全に支配するようなケースです。Mythos Preview はこれらのいくつかのプリミティブを取得し、それらを動作する証明にどのように組み合わせるかを推論します。その過程で示される推論は、自動化されたスキャナからの出力というよりも、シニア研究者の作業のように見えます。 証明の生成 - バグを見つけることと、それがエクスプロイト可能であることを証明することは別々のことです。Mythos Preview はこの両方を実行できます。モデルは疑わしいバグをトリガーするコードを書き、そのコードをスクラッチ環境でコンパイルして実行します。プログラムがモデルの予想通りに動作すれば、それが証明となります。もしそうでなければ、モデルは失敗を読み取り、仮説を調整して再試行します。このループは発見されたバグ自体と同様に重要です。なぜなら、動作する証明のない疑わしい欠陥は単なる推測に過ぎず、Mythos Preview はそれを独自に埋めるからです。 上記で記述した内容の一部は、Mythos Preview に固有のものではありません。他の最先端モデルを同じハーンネス（評価枠組み）で実行した際にも、同様の根本的なバグが多数発見され、場合によっては推論面でも予想以上に進展が見られました。しかし、それらが不足していたのは、それらの断片をつなぎ合わせる点でした。あるモデルは興味深いバグを特定し、なぜそれが重要なのかについて思慮深い説明を書き上げますが、その後で停止してしまい、実際のチェーンが未完成のままになり、悪用の可能性に関する問いに答えないという状態でした。Mythos Preview で変わったのは、従来のバックログの中で目立たずに放置されていた低深刻度のバグを、モデルが単一のより深刻なエクスプロイトへと連鎖させられるようになった点です。 正当な脆弱性研究におけるモデルの拒否反応 Project Glasswing の一部として Anthropic が提供する Mythos Preview モデルには、一般利用可能なモデル（Opus 4.7 や GPT-5.5 など）に含まれている追加的なセーフガードは備わっていませんでした。 それでもなお、このモデルは特定の要求に対して有機的に拒否反応を示します。脆弱性ハンティングに有用だったサイバー能力と同様に、このモデルにも独自の創発的ガードレール（安全装置）があり、それが正当なセキュリティ研究の要求に対してさえ時に反発を引き起こすことがあります。しかし私たちが発見した通り、これらの有機的な拒否は一貫していません。同じタスクでも、枠組みを少し変えたり異なる文脈で提示したりするだけで、以下に示す例のように全く異なる結果を生み出す可能性があります。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5St6rLRq9wkuxwmLHZ88CV/b4eb948c917ef7f7b0028ccc8ec0aefe/image2.png) 動作する概念実証（Proof of Concept）の構築に対して Mythos Preview が拒否を示す例 例えば、モデルは当初あるプロジェクトに対する脆弱性調査の実施を拒否しましたが、その後、プロジェクトの環境に関する無関係な変更が行われたことで、同じコードに対する同一の調査の実施に同意しました。分析対象となったコード自体には何の変化もありませんでした。 別のケースでは、モデルがコードベース内で複数の深刻なメモリバグを発見して確認したものの、デモンストレーション用のエクスプロイト（攻撃コード）の作成を拒否しました。同じ要求でも表現方法を変えれば異なる回答が得られ、さらにモデルの確率的性質により、同一の要求であっても実行ごとに結果が異なることがあります。意味的に同等なタスクであっても、モデルに提示する方法やタイミングによって正反対の結果を生じることがあります。 これは重要です。なぜなら、モデルの自発的な拒否やガードレールは確かに存在するものの、それら単独では完全な安全境界として機能するには一貫性が不足しているからです。まさにその理由から、将来一般に利用可能となるような能力の高いサイバーフロンティアモデルには、このベースライン行動の上に追加的な safeguards（安全対策）を含めることが必須となります。これにより、Project Glasswing のような制御された研究文脈の外で広く使用しても適切になるようにします。 シグナル対ノイズの問題 セキュリティ脆弱性のトリアージにおいて最も困難な部分の一つは、どのバグが実際に存在し、どのバグが悪用可能であり、どのバグを今すぐ修正する必要があるかを判断することです。これは AI が登場する前の世界でも難しい問題でした。AI による脆弱性スキャナや AI 生成コードの登場により状況はさらに悪化しており、Cloudflare ではこれに対処するために複数の事後検証ステージを構築しました。 ノイズ率を支配する2つの要因があります: プログラミング言語 - C や C++ は直接メモリ制御を提供し、それによってバッファオーバーフローや境界外読み書き・書き込みといったバグクラスをもたらします。一方、Rust などのメモリスafeな言語ではこれらの問題はコンパイル時に排除されます。私たちは、メモリー不安全な言語で書かれたプロジェクトから一貫して偽陽性が多発することを確認しました。 モデルバイアス - 優れた人間のリサーチャーは発見した内容と自身の自信度を伝えますが、AI モデルはそうではありません。バグの探索をモデルに依頼すると、コードに実際にバグがあるかどうかに関わらず、必ず見つけ出します。その結果として返される所見には「おそらく」「潜在的に」「理論上は可能」といった留保表現が付帯し、こうした留保付きの所見が確実な所見を圧倒的に上回ります。これは探索ツールのための合理的なバイアスですが、トリアージキューにおいては破滅的なものです。なぜなら、すべての推測性所見に対して人間の注意とトークンが費やされ、そのコストは数千件の所見にわたって複利のように積み重かるからです。 Mythos Preview は、特にプリミティブを連鎖させる能力において明確な改善を示しています。これは、複数の脆弱性を個別に報告するのではなく、複数の脆弱性を組み合わせて動作する概念実証（PoC）を作成できる点です。PoC を伴う発見は、即座に対応可能な発見であり、「これが実際に存在するのか？」と尋ねる時間を大幅に短縮します。 私たちのハーンズは意図的に過剰報告するように調整されており、より多くの脆弱性を検出し（見落としを減らす）一方で、ノイズも増えます。しかし、トリアージの段階では、Mythos Preview の出力は明らかに品質が高く、曖昧な発見が少なく、再現手順が明確で、修正または却下という判断に至るまでの作業量が削減されています。 汎用的なコーディングエージェントをリポジトリに指向させるのが機能しない理由 私たちが昨年 AI を支援した脆弱性調査を開始した際、私たちの直感は明白でした：汎用的なコーディングエージェントを任意のリポジトリに向け、脆弱性の発見を依頼することです。このアプローチは、モデルが発見結果を生成するという意味では機能しますが、実際のコードベースに対する有意義なカバレッジを生み出し、価値ある発見を特定する点では機能しません。これには主に 2 つの理由があります： コンテキスト - コーディングエージェントは、機能の構築、バグの修正、リファクタリングの実行など、一つの集中した作業ストリームに最適化されています。彼らは大量のソースコードを取り込み、一度に一つの仮説のみを保持し、それに対して反復処理を行います。これは脆弱性調査には全く不適切な形状です。なぜなら脆弱性調査は本質的に狭く並列的な性質を持つからです。人間の研究者は特定の一点を選び、それを徹底的に調査します。その一点は、単一の複雑な機能であったり、セキュリティ境界を横断するものであったり、攻撃者の入力がシェルコマンドとして実行されるような特定の脆弱性クラス（例えばコマンドインジェクション）であったりする可能性があります。その後、彼らはコードベース全体で数千回にわたって、異なる機能やセキュリティ境界、あるいは別の脆弱性クラスに対して同じ調査を繰り返します。10 万行規模のリポジトリに対して単一のエージェントセッション（サブエージェントを含む場合でも）を実行しても、モデルのコンテキストウィンドウが一杯になり、圧縮処理が開始される前に、有用な形でカバーできるのは表面積の約 0.1% に過ぎません。その過程で、後に重要となる可能性のある初期の発見が失われるリスクさえあります。 スループット - シングルストリームエージェントは一度に一つの作業しか行えませんが、実際のコードベースでは多くのコンポーネントに対して同時に多数の仮説を検証する必要があり、興味深い発見があった際にはさらに範囲を広げる能力も求められます。エージェントをより強く駆動させることは可能ですが、ある時点でモデル自体がボトルネックになるのではなく、相互作用そのものの形状が制限要因となります。研究者がすでに手がかりを持っており、第二の視点を得たいという手動調査においては、モデルを直接コーディングエージェントとして使用することは問題ありません。しかし、高いカバレッジを実現するためのツールとしては不適切です。この事実を受け入れた後、私たちは Mythos Preview に不適切な役割を担わせようとするのをやめ、その周囲にハネス（枠組み）を構築し始めました。 ハネスが実際に解決する課題 スケールして作業を実行した結果、4 つの教訓が得られ、それぞれが全体の実行を管理するハネスの必要性を示していました: 狭いスコープの方がより良い発見につながる - モデルに「このリポジトリ内の脆弱性を見つけよ」と指示すると、探索範囲が広がりすぎてしまいます。一方、「この特定の関数内でコマンドインジェクションを検索せよ。その上部にはこの信頼境界があり、ここにアーキテクチャドキュメントを提示し、この領域の過去の調査結果も参照せよ」と指示すれば、研究者が実際に実行するような作業に非常に近い成果を得ることができます。 敵対的レビューはノイズを低減する - 初期発見とキューの間に、異なるプロンプトとモデルを持ち、独自の発見を生成できない第 2 のエージェントを追加することで、最初のエージェントが自身の作業をチェックしただけでは見逃す可能性のあるノイズの多くを検出できることが判明した。単に一つのエージェントに注意深くさせるよりも、意図的に二つのエージェントを対立させる方がはるかに効果的である。 チェーンを複数のエージェント間で分割することで推論が向上する - 「このコードにはバグがあるか？」と「攻撃者がシステム外部から実際にこのバグに到達できるか？」という二つの質問は別物であり、それぞれを個別に問うことでモデルは各質問に対してより優れた回答を示す。なぜなら、それぞれの質問は統合されたバージョンよりも範囲が狭いためである。 並列化された狭義のタスクは、一つの包括的なエージェントを上回る - 多くのエージェントが限定的な質問に取り組む結果を後で重複排除する方が、単一のエージェントに包括的になるよう求める場合よりもカバレッジが向上する。 これらの観察はすべてモデルの振る舞いに関するものであり、これらを組み合わせると、もはやチャットインターフェースではない何かが浮かび上がる。それは最終的な成果を達成するための支援ツール（ハネス）である。このハネスを構築するための最初のステップは単純で、モデルに協力を求めるだけでよい。これが私たちが行ったことだ。私たちは Mythos Preview を基盤として、その強みに合わせてオリジナルのハネスを構築し、調整・改善した。 実践におけるハネスの例を以下に示す。 私たちの脆弱性発見用ハネス ここから、脆弱性発見ハーンネスの各段階の様子をご紹介します。これは、ランタイム全体、エッジデータパス、プロトコルスタック、コントロールプレーン、そして私たちが依存するオープンソースプロジェクトにまたがるライブコードのスキャンに使用されました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1OhgJDEeyc5aq8EoF4yFJE/917c9a9d8a92d0920acb96f7d5cb66f6/image6.png) | 段階 | 機能 | 重要性 | |---|---|---| ![image](https://images.ctfassets.net/zkvhlag99gkb/5736CBrNDFnYglaRFUtGp0/2bccdc1e5b5f1b21416c6439cdb63967/BLOG-3301_image7.png) リコン（Recon） エージェントがレポジトリをトップダウンで読み込み、各サブシステムを担当するサブエージェントに展開し、ビルドコマンド、信頼境界、エントリポイント、および潜在的な攻撃対象領域を網羅したアーキテクチャドキュメントを作成します。また、次の段階のための初期タスクキューも生成されます。 すべての下流のエージェントに共有コンテキストを提供し、探索の無駄（wander problem）を削減します。 ![image](https://images.ctfassets.net/zkvhlag99gkb/7wGJ8jmh1gjMevxH31nSfv/b3bd6772cfa57939a1291cae8c4faab3/BLOG-3301_image8.png) Hunt 各タスクは、攻撃クラスとスコープのヒントを組み合わせたものです。ハンター（実際にバグを探すエージェント）は並行して実行され、通常は一度に約五十体が稼働し、それぞれがいくつかの探索サブエージェントへと展開します。各ハンターには、タスク固有の一時ディレクトリで概念実装コードをコンパイルおよび実行するためのツールへのアクセス権限が付与されています。 ここが作業の大部分が行われる場所です。一つの包括的なエージェントではなく、多数の狭義なタスクが並列処理されます。 ![image](https://images.ctfassets.net/zkvhlag99gkb/7mMu2OOeot8CLuvu2PYAjx/144ecd5ef0785d8c6b0c7c3cd6feccc8/BLOG-3301_image5.png) Validate 独立したエージェントがコードを再読し、元の発見を反証しようと試みます。異なるプロンプトを使用し、独自の新たな発見を生成する能力は持ちません。 ハンター自身が自分の作業を検証する際に見過ごすノイズの有意な割合を検出します。 ![image](https://images.ctfassets.net/zkvhlag99gkb/7f8SJhTAja5bLPvydZkrv4/11a9cf6b0cee030db5f56d0dd46e0b45/BLOG-3301_image11.png) Gapfill（ギャップフィル） ハンターが接触したが十分にカバーしなかった領域にフラグを立てます。これらの領域は、再度別のパスで処理されるようキューに戻されます。 これは、モデルがすでに成功した攻撃クラスへと drifting（ドリフト：ずれること）する傾向に対抗するものです。 ![image](https://images.ctfassets.net/zkvhlag99gkb/5tbCM9SUgCZlYF0m9e8CY0/c48b7f90e39ddc5bd6060d5067bae0ea/BLOG-3301_image4.png) Dedupe（重複排除） 同じ根本原因を共有する発見事項は、単一のレコードに統合されます。 バリアント分析（variant analysis：変異解析）は機能であり、重複でキューを膨らませるための手段ではありません。 ![image](https://images.ctfassets.net/zkvhlag99gkb/51VLQM1a40KKRdvq2HidRj/c9ad0209a54544fe783d9eb019a6f02b/BLOG-3301_image3.png) Trace 共有ライブラリ内の各確認済み発見事項について、トレーサーエージェントがファンアウト（各コンシューマーリポジトリごとに 1 インスタンス）し、クロスリポジトリシンボルインデックスを使用して、攻撃者が制御する入力システム外部から実際にバグに到達するかどうかを判断します。 「欠陥がある」という状態を、「到達可能な脆弱性がある」に変換します。これが最も重要な段階です。 ![image](https://images.ctfassets.net/zkvhlag99gkb/4UhAgIcdpKcWxNG2kO5fIN/6f883a0f993604339b5381b14f63f40d/BLOG-3301_image1.png) Feedback 到達可能なトレースは、バグが実際に露出しているコンシューマーリポジトリにおける新たな調査タスクとなります。 ループを閉じます。パイプラインは実行されるにつれて改善されていきます。 レポート エージェントは、事前に定義されたスキーマに対して構造化されたレポートを作成し、そのスキーマに対する検証エラーを自ら修正して、取り込み API にレポートを送信します。 出力されるのは自由形式の文章ではなく、照会可能なデータです。 これがセキュリティチームにとって何を意味するか 他のセキュリティリーダーから Mythos プレビューに対する最も大きな反応は、スピードに関するものでした。より速くスキャンし、より速くパッチを適用し、対応サイクルを圧縮することです。私たちが話した複数のチームがすでに、CVE 公開から本番環境へのパッチ適用までの SLA を 2 時間以内に設定して運用しています。その直感は理解できます。攻撃者のタイムラインが短縮されるなら、防御側のタイムラインもそれに合わせて短縮されなければなりません。しかし、スピードを上げるだけでは不十分であり、多くのチームがこれから、このことを痛い思いをして学び、多大な時間、労力、資金を費やすことになるだろうと考えています。 パッチ適用を速くしても、パッチを生み出すパイプラインの形状は変わりません。回帰テストに 1 日かかる場合、それを省略せずに 2 時間の SLA を達成することはできず、回帰テストを省略して出荷されたバグは、修正しようとしていたバグよりも深刻なものである傾向があります。モデル自身にパッチを書かせて数個が公開される様子を見守った際にも、この問題の一種を経験しました。それらは元のバグは修正したものの、コードが依存していた別の機能を静かに壊してしまっていたのです。 より難しい問いは、脆弱性を取り巻くアーキテクチャがどのようなものであるべきかという点です。原則として、バグが存在する状況でも攻撃者にとって悪用を困難にし、脆弱性が公開された時点とパッチ適用までの間の時間差の重要性を低下させることです。つまり、アプリケーションの手前に配置されてバグに到達するのをブロックする防御手段が必要です。また、コードの一部にある欠陥が攻撃者に他の部分へのアクセス権を与えないようにアプリケーションを設計することも含まれます。さらに、個々のチームがデプロイするのを待つのではなく、コードが稼働しているすべての場所に同時に修正をロールアウトできる能力も必要です。 私たちはこのトピックには両刃の剣である側面があることも認識しています。自社のコード内でバグを見つけるのに役立った同じ機能が、間違った手に渡れば、インターネット上のあらゆるアプリケーションに対する攻撃側を加速させることになります。Cloudflare は数百万ものアプリケーションの手前に位置しており、上記で説明したアーキテクチャ原則こそが、顧客に代わって適用するために当社の製品が構築されている基盤です。これが顧客にとって何を意味するかについては、今後数週間でさらに詳しく共有していきます。 ご自身のチームでも同様の取り組みを行っており、情報を交換したい場合は、security-ai-research@cloudflare.com までご連絡ください。 Mythos Preview を用いた当社の研究は、制御された環境において自社のコードに対して実施されました。この研究を通じて表面化したすべての脆弱性は、Cloudflare の公式な脆弱性管理プロセスに基づき、必要な対応が行われるようトリアージされ、検証され、修正されました。 この作業はチームによる共同成果です。Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl、Rohit Chenna Reddy 各位に、その貢献に対し感謝申し上げます。

プロジェクト・グラスウィング：ミトスが示したもの

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト