Project Glasswing と Mythos — 脆弱性を狩る LLM の時代が開くとき
Project Glasswing と Mythos — 脆弱性を狩る LLM の時代が開くとき
Anthropic が制御下のパートナーのみへ公開した Mythos Preview は何ができ、その能力が一般に開かれたときセキュリティ産業はどう変わるのか。そしてその変化の重心はモデルにあるのか、それともモデルを取り囲む 7 段階ハーネスにあるのか。
導入 — 「脆弱性ハンティング用 LLM」という新カテゴリ
5月第 2 週、Cloudflare のセキュリティブログが「Project Glasswing: what Mythos showed us」という記事を上げた。HN スコア 266、コメント 100。記事自体は回顧録の体裁だが、行間に潜むニュースの重さは小さくない。Anthropic が Project Glasswing という制御下のアクセスプログラムで一部パートナーのみに Mythos Preview というモデルを公開し、Cloudflare がそのパートナーのひとつとして自社インフラへ試験適用した結果を整理した記事である。
Mythos Preview は「脆弱性発見に特化した LLM」である。この表現は新カテゴリを指す。これまで LLM はコードを書く・レビューする・要約する道具として定着していた。セキュリティ領域でもコードレビュー補助や静的解析結果の自然言語解釈までは慣れた風景だった。Mythos はその場所から一歩深く入る。メモリ安全性の弱い C/C++ コードベースを受け取り、脆弱性候補を見つけ、その候補を連鎖させて実際に動作する exploit に組み立て、sandbox 環境で PoC コードを自らコンパイル・実行して検証する。Cloudflare のレポートはこれを「推論自体がシニアセキュリティ研究者の作業のように見える(reasoning that looks like senior researcher work)」と書く。
ここに分析素材は二筋ある。ひとつはモデル自体が持つ能力の正体だ。Mythos が本当にシニア研究者級の作業を行えるなら、セキュリティ産業の非対称 — 攻撃者は 1 か所だけ破ればよく、防御者はすべてを守らねばならない — はさらに極端に傾く。もうひとつは Cloudflare が同じ記事で書いた一文、「モデルの自発的な拒否行動だけでは一貫した安全境界にならない(the model’s organic refusals aren’t consistent enough to serve as a complete safety boundary)」が指すガバナンス問題である。誰がこのモデルにアクセスできるのか。どんな条件で接近するのか。そしてその制御が破れたとき何が起きるのか。
本稿はその二筋を辿る。まず Mythos が実際に何をして何ができなかったか。次に Cloudflare の 7 段階ハーネスがなぜ「一般的なコーディングエージェントでは意味ある脆弱性発見はできない」という結論を作ったか。最後にこのカテゴリが一般に開かれたとき、セキュリティ産業の非対称はどう変わるか。
本文 1 — Mythos が実際にしたことと、しなかったこと
Cloudflare の記事が最も長く扱っているのは、モデルが何をうまくやれたかではなく、何がうまく行き何が行かなかったかのバランスだ。両方を書き留めておく。
うまく行った部分。 Mythos は前世代モデルより推測性(hedged)発見をはるかに少なく出した。セキュリティ研究者にとって最大のコストは未検証の候補を一つ一つ手で確かめる時間だ。前モデルは「この関数に buffer overflow があるかも」程度の推測候補を山と吐き、その中で実際に exploit 可能なのは 5% 以下だった。Mythos は本当の候補の比率を引き上げただけでなく、候補を見つけたときその候補を PoC まで持っていく能力を備えていた。Cloudflare の表現で「speculation を validated finding に変える(converting speculation into validated findings)」だ。この差はセキュリティ運用の単位時間を決める。シニア研究者 1 人が 1 週間で検討できる候補数が二桁から三桁へ増えるという意味である。
もうひとつうまく行った部分は exploit chain の構成だ。単一の脆弱性はそれ単体では大きな被害を生まないことが多い。セキュリティ研究者が本当に危険な脆弱性を報告するときには、いくつかの小さな欠陥を連鎖させて権限昇格や任意コード実行のような大きな結果へ持っていく過程が要る。Mythos はこの chain を自分で組み、sandbox 環境で PoC コードをコンパイルし、実行が失敗すれば原因を診断して再試行する反復ループを内蔵している。すなわち自動 scanner の出力ではなく、シニア研究者の作業フローを模倣する。セキュリティ産業にとって最も重い信号だ。
限界の部分。 Mythos はいまだにノイズを生む。とくにメモリ安全性の弱い C/C++ 領域で、モデルは既知パターンに引きずられ、実際には exploit 不可能な箇所に偽の候補を作る。Cloudflare はこれを「モデルバイアスが trash 候補を作り、triage リソースを食う(model bias generates speculative findings that waste triage resources)」と書く。このノイズ比率がどれくらいかレポートは正確な数字を書いていないが、「依然として substantial」と表現した。
もうひとつの限界はモデル自身の拒否行動が一貫しない点だ。Anthropic は Mythos が悪用要求を自発的に拒むよう学習させたが、Cloudflare はその拒否行動が同じ要求を別のプロンプト構造で投げると往々にして崩れると報告した。だから Cloudflare は自社の評価レポートに明示する。「モデルの自発的拒否行動だけでは完全な安全境界にならない。一般公開水準の強力なサイバーモデルはこのベースラインの上に別途のセーフガードを必ず加えねばならない(any generally-available capable cyber model must include additional safeguards on top of this baseline behavior)。」この一文はガバナンス面で核心だ。モデル自体に安全を縛れないなら、安全はそのモデルを取り囲むインフラとアクセス制御に縛らねばならない。Project Glasswing という名そのものがその発想を表す。ガラスのような羽の蝶のように、中が見える制御されたアクセス構造である。
本文 2 — なぜ 7 段階ハーネスが必要だったか
Cloudflare の記事で 2 番目に重要なのはモデルをどう使ったかの構造だ。Cloudflare は自社コードベースをただモデルに投げなかった。7 段階に分けたパイプラインを作った。
Recon → Hunt → Validate → Gapfill → Dedupe → Trace → Report
各段階を簡単に。Recon はコードベース全体を眺めて候補領域の輪郭を取る。Hunt はその領域内で具体的な脆弱性候補を探す。Validate は候補が実際に exploit 可能かを PoC で検証する。Gapfill は検証過程で情報が欠ければそこへ戻って埋める。Dedupe は同じ脆弱性に対する重複候補を統合する。Trace は候補の原因経路を追跡する。Report はその結果を人が読める形式に整える。
この構造は単なるチェックの流れではない。各段階に別々のエージェントを配し、段階間に adversarial review を差し挟んでいる。すなわち、ある段階が導いた候補を次段階が素直に受け取るのではなく、懐疑的に再検討し、反例を試みる。この adversarial review は、モデル自身のバイアス — 自分の作った候補を自分で検証すると通してしまう — を、人の同僚レビューに似た形で補う。Cloudflare はこの構造を「各々狭いタスクを並列に行い、エージェント間で adversarial review が入り、ひとつのエージェントがすべてをやるのではなく問いを細かく切る方式(parallel narrow tasks, adversarial review between agents, and specialized question-splitting)」と表現する。
ここでレポートが投げかける結論は重い。「一般的なコーディングエージェントでは意味ある脆弱性カバレッジは得られない(generic coding agents cannot achieve meaningful vulnerability coverage)。」この一文の重さは大きい。5月の Anthropic-Stainless 取引で見た通り、agentic コーディングツールは今や業界標準になりつつある。だがその標準的なコーディングエージェントが単体ではセキュリティ領域で意味ある成果を生まない、ということだ。本物の成果は (1) Mythos のような特化モデルと (2) Cloudflare のような会社が作った 7 段階ハーネスが出会う地点にしか出ない。すなわち、ある会社のモデルひとつ、あるコーディングエージェントひとつでは足りない。両方の層が要る。
この結論はセキュリティ産業の非対称構造に微妙な意味を加える。大企業は自前のセキュリティチームを持ち、Mythos のような特化モデルを受け入れるインフラを敷け、7 段階ハーネスを作るエンジニアもいる。Cloudflare の評価自体がその大企業の事例だ。しかし小規模の会社、とりわけセキュリティ人員を別に置けない会社は、Mythos が一般に開かれてもそれを自衛に使うのが難しい。同じモデルが攻撃者の手にはより容易に渡る。攻撃者は 1 か所だけ破ればよいので、洗練された 7 段階ハーネスがなくてもモデル単体である程度の成果を出す。非対称がさらに極端に傾く地点に私たちは立っている。
本文 3 — ガバナンス：Project Glasswing という名が指すもの
Anthropic がこのモデルを「Project Glasswing」という制御下のアクセスプログラムでリリースした事実自体が重要な信号だ。Glasswing は羽が透明な蝶を指す。名前が暗示するものは明確である。中が見える制御。Anthropic は Mythos Preview の能力が一般公開水準にはまだ適さないと判断し、だから Cloudflare のような信頼できるパートナーにのみ制御環境でアクセスを開いた。この決定は OpenAI が GPT-4 リリース時に導入した「red team」段階に似るが、一段精緻だ。単なる出荷前評価ではなく、継続的な controlled rollout として運用される。
この構造自体が新しいガバナンスパターンだ。過去 2 年、frontier モデルの安全ガバナンスにはふたつのパターンがあった。ひとつは OpenAI の system card のようにモデル自体への評価を事前公開し、その後一般公開するパターン。もうひとつは Anthropic の RSP(Responsible Scaling Policy)のようにリスク水準に応じて段階的に制約を加えるパターン。Project Glasswing はその二つに一層を重ねる。特定能力のモデルを一般公開ではなく制御下のパートナー群のみに開き、そのグループの使用事例で安全評価データを蓄える。安全制御が十分に固まったと判断されれば、一般公開段階へ移る。
このパターンは二つの意味を持つ。良い意味は、frontier モデルの安全評価が学術ベンチマークではなく実運用環境で積まれるデータへ移ることだ。Cloudflare の評価レポートがそれ自体安全データだ。7 段階ハーネスを通じて Mythos がどの種の脆弱性でノイズが多いか、どの領域でモデルの自発的拒否行動が崩れるかが、実会社の運用環境で測られる。このデータが次段階の安全制御の出発点になる。
悪い意味は、frontier モデルの最強の能力が大企業と小規模会社の間で時間差で開かれることだ。Cloudflare は 5月時点で Mythos を使えるが、小さなセキュリティ会社はまだ使えない。その時間差の間に大企業のセキュリティ態勢は急速に強化される。小規模会社は同じモデルを得られないまま、一般公開された(より弱い)モデルで似た結果を真似ようとする。この時間差が長くなるほど、セキュリティ産業の二層 — 大企業の強いセキュリティ態勢 vs 小規模会社の弱いセキュリティ態勢 — の距離は開く。
ここにより深い問いが続く。Project Glasswing のような制御下のアクセスプログラムに参加する会社は誰が選ぶのか。Cloudflare は自らを「信頼できるインフラ会社」と自負するが、その信頼はどこで保証されるのか。Anthropic の内部決定によってだ。すなわち frontier モデルの最強の能力に誰が先にアクセスするかは、一企業の内部決定にかかっている。この構造そのものは暫定としては機能するが、業界標準として固まれば新しいゲートキーパー問題を作る。5月の Anthropic-Stainless 取引で見たゲートキーパー問題が SDK 標準についてのものだったとすれば、Project Glasswing のゲートキーパー問題はそれよりも重い。サイバーセキュリティ能力そのものに対するゲートキーパー問題である。
最後に Cloudflare の記事が提示する実務的結論も押さえておく。記事末尾で Cloudflare はシンプルな勧告を出す。セキュリティチームは「CVE 公開からパッチ適用まで 2 時間以内」のような攻撃的 timeline を追うより、defense-in-depth、compartmentalization、simultaneous global patching のようなアーキテクチャ防御のほうに重きを置けというものだ。この勧告の重さは微妙だ。Mythos のようなモデルが一般に開かれる時点で、攻撃者が新規脆弱性を発見し exploit 化する速度がパッチ cycle の速度を追い越す可能性がある。すると事後の timeline 短縮競争では足りない。最初からひとつの脆弱性が大きな被害につながらないようシステムを分割しておくアーキテクチャ判断のほうが重要になる。
結論 — モデルそのものではなく「モデル + ハーネス + ガバナンス」の束
冒頭の問いに戻ろう。Mythos は何ができ、その能力が一般に開かれたときセキュリティ産業はどう変わるか。そして変化の重心はモデルなのか、ハーネスなのか、ガバナンスなのか。
答えは三つすべてだが、重心はモデル単体ではない。Cloudflare の評価がもっともはっきり示すのは、同じ Mythos モデルでも 7 段階ハーネスなしに投げれば一般的なコーディングエージェントと大差ない、という事実だ。すなわちモデル能力の実用は、それを取り囲む運用インフラが決める。5月に見た Anthropic-Stainless 取引と Modal の cold start 短縮が指すのと同じ結論が、セキュリティ領域でも再び現れる。モデルは平坦化し、差別化は運用インフラで決まる。
もうひとつの結論はガバナンスがモデル能力と同じ重さで扱われるべきという点だ。Project Glasswing の制御下アクセス構造は暫定として機能するが、業界標準として固まればゲートキーパー問題を生む。その問題を解く方式が何になるかはまだ開いている。自律的な安全ガバナンス委員会のような多者構造ができるかもしれないし、政府規制が入るかもしれない。どちらにせよ、5月の時点で見えているのは、そのゲートキーパー問題の輪郭だ。
本稿が残すメッセージは一行だ。攻撃セキュリティに特化した frontier モデルの時代が開く事実そのものよりも、そのモデルを誰がどんな条件で受け入れ、どんなハーネスで取り囲むかこそが次の四半期の本当の変数である。 Mythos 自体よりも、Project Glasswing の制御構造と Cloudflare の 7 段階ハーネスのほうが重要な信号だ。小規模会社はこの二つ — controlled access と multi-stage harness — が自分の手にどう入り得るかを、5月から真剣に考え始めたほうがよい。平坦化したモデル市場の上で、安全と運用の二つの層が次のラウンドの本当の舞台になる。
出典: