Project Glasswing：Mythosが示したもの
(blog.cloudflare.com)- Mythos Preview は、Cloudflare の50以上のリポジトリで個別のバグ検出を超え、複数のプリミティブをつなぎ合わせてエクスプロイトチェーンを構成した
- 疑わしいバグの検出にとどまらず、トリガーコードの作成、一時的なコンパイル・実行、失敗後の仮説修正まで繰り返して 動作証明 を作り上げた
- 正当な脆弱性研究でも自発的な拒否が見られたが、文脈や表現によって変わるため、安全境界 として使うには一貫性が不足していた
- 汎用コーディングエージェントには大規模リポジトリのカバレッジと並列探索に限界があり、Cloudflare は狭いタスクを並列実行する ハーネス を構築した
- セキュリティチームにとっては、より高速なスキャンやパッチだけでは不十分で、バグがあっても悪用や到達が困難になる アーキテクチャ が重要になっている
Mythos Previewが変えた脆弱性研究の進め方
- Cloudflare はここ数か月、自社インフラ上でセキュリティ重視の LLM をテストしており、Anthropic の Mythos Preview を Project Glasswing の一部として受け取り、50以上の自社リポジトリに適用した
- Mythos Preview は、既存の汎用フロンティアモデルを単純に改良したものというより、脆弱性研究の異なる段階を担う 新しいツール に近かった
- 中核となる変化は、個別のバグを列挙するだけで終わらず、複数の攻撃プリミティブを組み合わせて エクスプロイトチェーン を構成する点にある
- 実際の攻撃は単一のバグだけを使うのではなく、use-after-free を任意読み取り・書き込みプリミティブに変え、制御フローを乗っ取り、ROP チェーンでシステム制御を得る、といった形で連なっていく
- Mythos Preview はこうしたプリミティブを組み合わせて動作する証明へとつなげ、自動スキャナよりも熟練研究者の作業に近い推論を行った
- もう1つの変化は、疑わしいバグを見つけた後に 動作証明 まで自ら作成する能力だった
- トリガーコードを書き、一時環境でコンパイルしてから実行する
- 予想どおり動作すれば証明になり、失敗すれば失敗内容を読んで仮説を調整し、再試行する
- 動作する証明のない欠陥は推測の域を出ないが、Mythos Preview はこのギャップを自力で縮めた
- 同じハーネス上で他のフロンティアモデルも一部の基礎的なバグを見つけ、予想以上に先まで推論したケースはあったが、複数の断片を実際のチェーンとして完成させる段階で差が出た
- Mythos Preview は、従来ならバックログに低深刻度で残っていたバグ群を、より深刻な1つのエクスプロイトへと結び付けられた
正当な脆弱性研究でも発生したモデルの拒否
- Project Glasswing に提供された Mythos Preview には、Opus 4.7 や GPT-5.5 のような一般提供モデル向けの追加安全装置は含まれていなかった
- それにもかかわらず、モデルは特定のリクエストに自発的に反発し、脆弱性検出に有用だったサイバー能力とともに 創発的ガードレール も示した
- 自発的な拒否は一貫していなかった
- 同じ作業でも、表現や文脈が変わると結果がまったく異なることがあった
- あるプロジェクトの脆弱性研究を最初は拒否したのに、プロジェクト環境への無関係な変更後、同じコードに対する同じ研究を受け入れた
- コードベースで重大なメモリバグを複数見つけて確認した後に、デモ用エクスプロイトの作成を拒否したケースもあった
- 同じリクエストでも、モデルの確率的性質により実行ごとに異なる結果を返すことがあった
- 自発的拒否とガードレールは実際に存在するが、それだけで完全な 安全境界 になるほど一貫してはいなかった
- 高能力なサイバー系フロンティアモデルを一般提供するには、Project Glasswing のような制御された研究環境の外でも適切に使えるよう、追加の安全装置が必要になる
シグナルとノイズの問題
- セキュリティ脆弱性のトリアージで最も難しいのは、どのバグが実在し、悪用可能で、今すぐ修正すべきかを判断することだ
- この問題は AI 以前から難しかったが、AI 脆弱性スキャナと AI 生成コードによってさらに悪化し、Cloudflare は複数の 事後検証段階 を構築した
-
プログラミング言語
- C と C++ は直接的なメモリ制御を提供し、バッファオーバーフローや範囲外読み取り・書き込みのようなバグ種別を生み出す
- Rust のような メモリ安全言語 は、こうした種別をコンパイル時点で排除する
- メモリ安全でない言語で書かれたプロジェクトでは、一貫してより多くの誤検知が見られた
-
モデルのバイアス
- 優れた人間の研究者は何を見つけ、どれほど確信しているかを伝えるが、モデルはコードにバグがあってもなくても結果を生成する傾向がある
- 結果は
possibly、potentially、could in theoryのような表現で弱められて返ってきて、こうした 推測的な結果 は確実な結果よりはるかに多かった - 探索ツールとしては合理的なバイアスだが、トリアージキューではすべての推測的結果が人の注意とトークンを消費し、数千件規模に積み上がるとコストが大きくなる
- Mythos Preview は、複数の脆弱性を別々に報告するのではなく、動作する PoC に結び付ける プリミティブチェーン の能力で明確な改善を示した
- PoC を含む結果は、そのまま対処可能な結果に近く、「これは本物か」を確認する時間を大幅に減らした
- Cloudflare のハーネスは、見落としを減らすため意図的に多めに報告するよう調整されておりノイズも多いが、Mythos Preview の出力は曖昧表現が少なく、再現手順も明確で、修正または棄却の判断に必要な作業を減らした
汎用コーディングエージェントをリポジトリにそのまま適用する方式の限界
- AI 支援の脆弱性研究の初期には、汎用コーディングエージェントに任意のリポジトリを渡して脆弱性を探させる方法が自然な出発点だった
- この方法でも結果は出るが、実際のコードベースを意味のある形でカバーし、価値ある結果を見つけるには適していなかった
-
コンテキスト
- コーディングエージェントは、機能実装、バグ修正、リファクタリングのような1つの集中した作業フローに合わせて設計されている
- 脆弱性研究は、単一の複雑な機能、セキュリティ境界の切り替え、コマンドインジェクションのような狭い対象を深く調べ、それをコードベース全体で何千回も繰り返す 狭く並列的な作業 に近い
- サブエージェントを使ったとしても、10万行規模のリポジトリに対する単一エージェントセッションでは、モデルのコンテキストウィンドウが埋まり圧縮が始まる前に、有用な形で表面の 0.1% 程度しかカバーできない
- 圧縮過程で重要だった可能性のある以前の結果が捨てられることもある
-
スループット
- 単一ストリームのエージェントは、一度に1つの作業しか行えない
- 実際のコードベースでは、複数コンポーネントに対する多くの仮説を同時に適用し、興味深い点が見つかればさらに広く分岐する能力が必要になる
- 研究者がすでに手がかりを持っていて、2人目のレビュー担当が必要な場合には、コーディングエージェントは手動調査に適している
- しかし高いカバレッジを達成するツールとしては不向きであり、Cloudflare は Mythos Preview の周辺に ハーネス を構築する方向へ切り替えた
ハーネスが解決した問題
- 大規模運用の経験から、全体の実行を管理するハーネスが必要だという結論に至った
-
狭い範囲のほうが良い結果を生む
- 「このリポジトリで脆弱性を探せ」という依頼は、モデルをさまよわせる
- 「この特定の関数でコマンドインジェクションを見ろ。上位にはこの信頼境界があり、ここにアーキテクチャ文書とこの領域の既存カバレッジがある」といった依頼のほうが、実際の研究者の仕事の進め方に近い結果を生む
-
敵対的レビューがノイズを減らす
- 初期結果とキューの間に第2のエージェントを置くと、第1エージェントが自己レビューで見落とすノイズを多く取り除ける
- 第2エージェントは異なるプロンプトと異なるモデルを使い、自分で結果を生成する権限は持たない
- 1つのエージェントに慎重になるよう言うより、2つのエージェントを意図的に 不一致状態 に置くほうがはるかに効果的だった
-
チェーンをエージェントごとに分けると推論が良くなる
- 「このコードにバグがあるか」と「攻撃者がシステム外部から実際にこのバグへ到達できるか」は別の問いだ
- 2つの問いを分離すると、それぞれがより狭くなり、モデルは各問いでより高い性能を出した
-
並列の狭い作業は1つの包括的エージェントに勝る
- 多数のエージェントが狭く定義された問いを処理し、その後で結果を重複排除するほうがカバレッジは良くなる
- 1つのエージェントに包括性を求める方法より効果的だった
- Cloudflare は Mythos Preview を使い、既存のハーネスをその強みに合わせて拡張・調整・改善した
Cloudflare の脆弱性発見ハーネス
- このハーネスは、Cloudflare のランタイム、エッジデータパス、プロトコルスタック、コントロールプレーン、および依存するオープンソースプロジェクトの実コードをスキャンするために使われている
-
Recon
- エージェントがリポジトリを上から読み、各サブシステムを担当するサブエージェントへ分岐する
- ビルドコマンド、信頼境界、エントリポイント、想定攻撃面を含む アーキテクチャ文書 を生成する
- 次段階へ渡す初期作業キューも作成し、すべての後続エージェントに共有コンテキストを提供して、モデルがさまよう問題を減らす
-
Hunt
- 各タスクは1つの攻撃クラスと範囲ヒントで構成される
- 実際のバグを探すハンターエージェントは通常およそ50個同時に動作し、各ハンターはさらに数個の探索サブエージェントへ分岐する
- 各ハンターは、タスクごとの一時ディレクトリで PoC コードをコンパイル・実行するツールにアクセスできる
- ほとんどの作業は、1つの包括的エージェントではなく、多数の狭いタスクを並列実行する形で進む
-
Validate
- 独立したエージェントがコードを読み直し、元の結果を反証しようと試みる
- 異なるプロンプトを使い、自律的に新しい結果を出すことはできない
- ハンターが自分の作業をレビューしたときには見落とす、意味のある割合のノイズを取り除く
-
Gapfill
- ハンターが触れたが十分にカバーできなかった領域をマークする
- その領域は別パス向けに再びキューへ入る
- モデルがすでに成功した攻撃クラスへ偏る傾向を相殺する
-
Dedupe
- 同じ根本原因を共有する結果を1つのレコードにまとめる
- 変種分析は機能であり、重複でキューを膨らませる手段ではない
-
Trace
- 共通ライブラリで確認された各結果について、トレーサーエージェントが利用側リポジトリごとに1つずつ分岐する
- クロスリポジトリのシンボルインデックスを使い、攻撃者制御入力がシステム外部から実際にバグへ到達するかを判断する
- これは「欠陥がある」を「到達可能な脆弱性がある」へ変える、最も重要な段階だった
-
Feedback
- 到達可能な追跡結果は、そのバグが実際に露出している利用側リポジトリ向けの新たな Hunt タスクになる
- 実行を重ねるほどパイプラインが改善されるループを閉じる
-
Report
- エージェントは事前定義されたスキーマに従って構造化レポートを作成する
- スキーマ検証エラーを自ら修正し、ingest API に送信する
- 出力は自由形式の散文ではなく、問い合わせ可能なデータ になる
セキュリティチームにとっての意味
- Mythos Preview を見た他のセキュリティリーダーたちは、より速くスキャンし、より速くパッチを当てることで対応サイクルを短縮しようとしていた
- Cloudflare が話をしたチームのうち少なくとも1つは、CVE 公開から本番パッチまで 2時間 SLA で運用していた
- 攻撃者のタイムラインが短くなるなら、防御側のタイムラインも短くしなければならないが、速度だけでは十分ではない
- パッチをより速く適用しても、パッチを生み出すパイプラインの形そのものは変わらない
- リグレッションテストに1日かかるなら、リグレッションテストを飛ばさずに 2時間 SLA へ到達することはできない
- リグレッションテストを飛ばしてデプロイしたバグは、もともと直そうとしていたバグより悪い可能性がある
- モデルに直接パッチを書かせた際、元のバグは修正したものの、そのコードが依存していた別の部分を静かに壊すパッチが一部デプロイされたこともあった
- より難しい問いは、脆弱性の周辺アーキテクチャをどう設計するかだ
- バグが存在しても、攻撃者が悪用しにくいようにしなければならない
- 脆弱性公開からパッチまでの間隔の重要性を下げられるようにしなければならない
- アプリケーション前段でバグへの到達を遮断する防御が必要だ
- コードの一部の欠陥が、攻撃者に他の部分へのアクセス権を与えないようアプリケーションを設計する必要がある
- 個別チームのデプロイを待たず、コードが実行されるすべての場所へ同時に修正を展開できる必要がある
- 同じ能力には両面性がある
- 自社コードのバグを見つける能力は、悪意ある手に渡ればインターネット上のあらゆるアプリケーションへの攻撃を加速しかねない
- Cloudflare は何百万ものアプリケーションの前段に位置しており、上記のアーキテクチャ原則は、顧客に代わって適用するよう製品が作られている原則だと述べている
- Mythos Preview の研究は制御された環境で Cloudflare 自社コードを対象に実施され、発見されたすべての脆弱性は Cloudflare の正式な脆弱性管理プロセスに従ってトリアージ・検証され、必要に応じて修正された
2件のコメント
curlのように、どんなエラーを修正したのかを分析したレポートかと思ったら、ただの露骨な宣伝記事なんですね？
クラウドフレアもAIエージェント専用のpaywallや要約エンドポイントなんかを作って盛り上がっていたと思ったら、おかしくなってきましたね
Hacker Newsのコメント
「別種の仕事をする別種のツールなので、以前のモデルときれいな apples-to-apples 比較をするのは難しい」とはどういう意味なのか分からない
別種のツールだと言いながら、実際の使い方の説明は他のモデルとまったく同じだ。平均的な Cloudflare ブログよりずっと出来が悪く、チェイニングと例示の重要性を指摘していた Mythos の発表を繰り返しただけという印象が強い
みんながやっているようにハーネスを付けて使うのはその通りで、モデルにハーネスを与える一般的な方法は今後も大きくは変わらないだろう。人間でも、何かの仕事をするのにハーネスが必要なことはある
好意的に見るなら、まだ NDA があるので、何が違うのかを正確に言えず、あえてぼかしているのかもしれない
最近の Cloudflare の成果物は、ほとんど全部 AI臭 が強い
セキュリティ研究向けに設計され、専門家にだけ開放されるモデルが、合法的な依頼を拒否するというのは意外だ
もっと具体的な数字や驚くような結果を期待していたが、ただのバランスの取れた宣伝文に見えるし、おそらく LLM で書かれたのだろう
[1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...
本当の問いは、この文章を書いたのが Mythos なのか Opus なのかということだ
「なぜ重要なのか」のような文句は、実際には重要ではない。企業ブログがもともと一人の筆者の声で書かれることは稀だったが、大組織までもがブログを LLM に外注するようになっているのを見るのは興味深い
「なぜ重要なのか」は、今や「AI出力が学習データの一部になる」へと格上げしたい。いずれ、磨かれたAI風の冗長な文体が標準になり、前の世代でなければ見分けにくくなるのだろう。Usenet のある側面を懐かしむのと少し似ている
銃口をのぞき込みながら、銃の広告チラシがどんな紙に印刷されているかで冗談を言っているようなものだ
だから Claude Code には妙なバグが多く、サポートが返金処理したと言っても実際にはされていない、ということも起きるのだろう
これを大規模に回して得たという「4つの教訓」は笑ってしまった。4つのうち3つは実質的に同じで、あまりにも当たり前だった
要するに「脆弱性を見つけろ」よりも 具体的で狭い依頼 のほうがうまくいく、という話で、当たり前だ。それでも敵対的レビューはまったく新しいものではなく HN でも何度も扱われてきたが、少なくとも興味深く、差別化できる部分ではあると思う。自分のワークフローにももっと取り入れてみたいし、コーディング以外の作業にも役立つかもしれない
https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...
「Mythos Preview に対するセキュリティリーダーたちの最大の反応は速度だった。より速くスキャンし、より速くパッチを当て、対応サイクルを圧縮すること。我々が話をしたチームのうち少なくとも2つは、CVE 公開から本番パッチまで 2時間SLA で運用している [...] 回帰テストに1日かかるなら、それを飛ばさずに2時間SLAに到達することはできず、回帰テストを飛ばせば、本来修正しようとしていたバグより悪いバグをデプロイしやすくなる」という部分は印象的だった
時間がたてば、こうしたモデルがコードをマージする前に 悪用可能性テスト を実行して、結果としてより安全なコードを生成できるようになるのだろうかと思う
*ここでの彼らとは、OpenAI も同じ方向に進んでいるようなので、あらゆる基盤モデル提供者を指す
良いのは分かるが、見つかった脆弱性のうち 最も深刻なもの がどの程度だったのか知りたい
おそらく公表したくないのだろうが、そこが本当に最も興味深く重要な部分だ
多くの人は Mythos を心理戦キャンペーンのように見ているが、そうした懐疑にはあまり納得できない。たいていは公に使えないもの一般への不信から来ているように思える。何人かの Anthropic 社員は Mythos を汎用モデル改善だと説明していたが、まだ広く裏付けられていないので、その点だけは引き続き懐疑的に見ている。セキュリティ研究という領域に限れば、この物語は受け入れられる
そう考えると、脆弱性を塞ぐことはエクスプロイトを見つけることと同じではない。むしろ小さな隙を減らし、動作するエクスプロイトを組み立てるのをますます難しくすることに近い
だから「ハードスキル」が圧倒的に良くなっていなくても、それらをより効果的に組み合わせられる。今でもこうした脆弱性のかなりの部分は Opus で特定できるが、複雑なエクスプロイトにつなげるには、依然として人間、それも熟練者が途中で必要だ。人が介在しなくてよくなるなら、平均的な人でもエクスプロイトを見つけて利用するのがずっと容易になる
https://security.paloaltonetworks.com
良さそうではあるが、実際に セキュリティ脆弱性 をいくつ見つけたのか、そのうち本物はいくつで誤検知はいくつだったのか、なぜデータを共有しないのか分からない
公開前に処理したいというのは理解できるが、データがほとんどない主張ばかり見せられて、人々がどうして懐疑的にならないはずだと思うのか分からない。セキュリティ専門家とは、文字どおり 懐疑的であることに報酬が支払われる 人たちだ
他モデルと比較したのか気になる。この文章の多くは、セキュリティに AI を初めて適用して、パターンマッチング機械 のとんでもない性能に驚いているように聞こえる
結局はパターンを合わせる機械なのだから、当然だ
反発する部分がかなり面白い。実際に使ってみると、先へ進む前に、そのコードベースへ 合法的にアクセスする権利 がある証拠を出すよう求められた
「Mythos Preview で変わったのは、従来バックログの中で見えないまま残っていた低深刻度のバグを、モデルがひとつのより深刻なエクスプロイトへとチェイニングできるようになったことだ」という話は、Mythos に関する他の独立テストともある程度一致しているように見える
長いエージェント作業 で非常に優れていて、おそらくそれを狙って訓練されたのだろう。そうであれば、コンテキストウィンドウ内でゆるく関連する話題どうしの周辺的なつながりを見つけ出せなければならない
[1] 主に https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos... のことを指している