Anthropic「Project Glasswing」── Claude Mythosが40社限定公開で発見した数千件のゼロデイ脆弱性

Posted at 2026-04-13

はじめに

2026年4月7日、Anthropicが「Project Glasswing」を発表しました。同社の未公開フロンティアモデル「Claude Mythos Preview」を用いて、主要OSや主要Webブラウザから数千件のゼロデイ脆弱性を発見したという内容です。しかもこのモデルは一般公開されず、約40社の限定パートナーにのみ提供されます。Anthropicが自ら「危険すぎる」と判断したモデルを、どうしてこのタイミングで、このかたちで世に出したのか。発表文を一度読むだけでは腑に落ちない論点がいくつも残ります。

本記事では、発表の背景にある政治的・技術的な文脈、LLMが従来手法では見つけられなかった脆弱性を発見する具体的なメカニズム、Anthropicにとっての経済合理性、そして一般の開発者が今日から備えるべきことを、公開情報をもとに掘り下げていきます。記事の前半は事実関係の整理、後半は仕組みと含意の解説という構成です。

なぜ今、このタイミングで発表されたのか

2025年から2026年のAIセキュリティ業界の空気

Project Glasswingを理解するうえで外せないのが、2025年に一気に可視化された「AIによる脆弱性発見」の潮流です。

まず2024年10月、Google Project ZeroとGoogle DeepMindの共同研究「Big Sleep」（前身は Project Naptime）が、SQLiteに存在する既知ではない脆弱性を発見しました。これはGoogle自身が「広く使われている実世界のソフトウェアで、AIエージェントが過去に見つかっていないメモリ安全性の問題を特定した最初の公的な事例」と位置付けたもので、LLMをセキュリティ研究に使う流れの事実上の号砲になりました（Project Zero - From Naptime to Big Sleep）。

続いて2025年、自律型ペンテストツール「XBOW」が HackerOne の米国リーダーボードで1位を獲得します。XBOWは90日で約1,060件の脆弱性を報告し、そのうち54件が Critical、242件が High、524件が Medium でした。人間のペネトレーションテスターが40時間かかる104件のシナリオを、XBOWは28分で完遂したと報告されています（XBOW公式ブログ、CyberScoop）。パロアルトの GlobalProtect VPN に影響する未知の脆弱性の発見も含まれており、「バウンティハンターの世界では既にAIが人間を越えた」という事実が可視化されました。

一方で、XBOWの成功は副作用も生みました。オープンソースプロジェクトのメンテナーたちのもとに「AI生成の低品質な脆弱性レポート」が殺到する事態が起きたのです。curlの作者 Daniel Stenberg 氏は自身のブログで「AIの吐き出したノイズの対応に毎日何時間も奪われている」と公然と苛立ちを表明し、Linuxカーネルのメンテナー Greg Kroah-Hartman 氏も「1カ月前に何かが変わった。今は本物のレポートが来ている」と発言しています。両者の発言は Glasswing 発表前のものであり、業界には「AIが脆弱性を見つける力は急激に質的に変わりつつある」という体感が既に広がっていました。

つまり Glasswing は、無風の空から突然落ちてきた発表ではありません。Big Sleep → XBOW → 各所の体感変化、という助走を踏まえたうえで「ついに自律的エクスプロイト構築まで踏み込んだモデルが出てきた」という位置付けになります。

Anthropicのこれまでのセキュリティ研究との連続性

Anthropicがセキュリティ関連の研究をしていたのも今回が初めてではありません。2022年末の Constitutional AI（CAI）論文で「モデルが自己批評を繰り返すことで有害応答を抑制する」枠組みを提示して以降、同社は一貫して「モデル自身の内部状態を観測し、介入する」アプローチを続けてきました（Constitutional AI - Anthropic）。

その延長線上に、2025年の Constitutional Classifiers（普遍的ジェイルブレイクに対する防御器）、2026年2月発効の Responsible Scaling Policy v3.0、そしてAlignment Science Blogでの「活性化プローブ」研究があります。Glasswing で「モデル内部のアクティベーションを監視する専用プローブで悪用を検出する」という記述が出てきたとき、これらの研究が伏線として機能していたことに気づきます。Glasswing は単発のプレスリリースではなく、Anthropicが数年単位で積み上げてきた「能力 × 介入 × 公開制御」の系譜の最新章だと捉えるのが妥当です。

政治的タイミング

もう一つ見逃せないのが、米国政府との距離です。Fortuneによると、Anthropicは「Mythosクラスの能力が年内に大規模なサイバー攻撃の発生確率を大きく押し上げる」と政府関係者に非公式に警告したと報じられています（Fortune）。2026年2月に改定された RSP v3.0 は、サイバー能力に関する閾値を具体化しつつあり、ASL-4相当のセキュリティ基準に踏み込むための実務的な布石を敷いた形です（Responsible Scaling Policy v3.0）。Glasswingは「RSPに沿って自主規制しました」と社外に示すことのできる最初の大型事例でもあり、政策当局との信頼関係構築にも寄与する構造になっています。

Project Glasswingの発表概要

何が発表されたのか

Project Glasswing は、Anthropic の未公開フロンティアモデル「Claude Mythos Preview」を防御的サイバーセキュリティに活用するイニシアチブです。発表の骨子は次の通りです。

Claude Mythos Preview を、Anthropic自身を含む12社のローンチパートナーと約40社の追加パートナーに限定提供
最大1億ドル（約150億円）のAPIクレジットをパートナーに提供
オープンソースセキュリティ団体（Alpha-Omega、OpenSSF、Apache Software Foundation）へ400万ドルを直接寄付
一般公開は見送り。新たなセーフガードが整備されるまで広く出さない方針

ローンチパートナーには、Anthropic 本体に加えて AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorgan Chase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networks が名を連ねます（合計12社）。いずれもOS、ブラウザ、ネットワーク機器、クラウド基盤、金融インフラなど、世界のソフトウェアスタックの下層を担う企業です。ここに入った時点で、実質的に「世界のソフトウェアインフラの大半」がカバーされる構図になっています。

「数千件のゼロデイ」という結果

Anthropicによれば、Mythos Preview を数週間運用しただけで次の結果が得られました。

主要OS（Windows、macOS、Linux、FreeBSD、OpenBSD）のすべてで未知の脆弱性を発見
主要Webブラウザ（Chrome、Firefox、Safari）のすべてで未知の脆弱性を発見
500件以上の高深刻度脆弱性をオープンソースソフトウェアから特定・検証
深刻度評価はプロのセキュリティコントラクターと89%一致

具体例として公開された3件は次の通りです。いずれも10年以上潜伏していた「深海の脆弱性」です。

対象	内容	潜伏期間
OpenBSD TCP/SACK処理	符号付き整数の二重オーバーフローによるNULLポインタ参照。リモートからシステムクラッシュが可能	27年
FFmpeg H.264デコーダ	スライス番号の衝突によるヒープ境界外書き込み。ファザーが500万回実行しても発見できず	16年
FreeBSD NFS（CVE-2026-4747）	リモートコード実行。6パケットに分割された20ガジェットのROPチェーンで、APIコスト50ドル未満で完全な攻撃を自律構築	17年

OpenBSD は「世界で最もセキュリティが堅牢なOS」として知られ、FFmpeg は動画処理のデファクトスタンダードです。いずれも長年にわたり専門家が目を通してきたコードベースであり、そこから十数年以上沈んでいた脆弱性が掘り出されたという事実が、従来手法の限界をもっとも雄弁に示しています。

「数千件」の内訳について

ただし、この「数千件」という数字には慎重に読むべき留保があります。Tom's Hardware はフォローアップ記事で「Anthropic が『深刻』と表現する脆弱性のうち、人手で検証されたのは198件に過ぎない」と指摘しています（Tom's Hardware）。残りはLLMによる自動深刻度評価をそのまま数えたものです。198件という数字自体は十分驚異的ですが、数千件すべてが独立検証済みの「真のゼロデイ」ではない点は押さえておく必要があります。

発見された脆弱性の内訳を公開情報から推定すると、次のような分布が見えてきます。

メモリ安全性起因（ヒープ／スタックオーバーフロー、UAF、NULL参照、整数オーバーフロー等）が大多数。C/C++で書かれたコンポーネントに集中
入力パーサ（メディアコーデック、プロトコル解析、ファイルフォーマット処理）での発見が目立つ
カーネル内の並行処理やロック周りのレースコンディション
スマートカードやTLS実装など、暗号プロトコル実装の境界チェック漏れ

AISLEの分析記事も「Mythosが強いのはメモリ安全性バグとロジック・レース系であり、認証・認可などの上位レイヤの設計不備にはまだ弱い」という傾向を報告しています（AISLE - AI Cybersecurity After Mythos）。ここから「Claude Mythos の強みは、ファザー／静的解析が長年取り組んできたメモリ安全性領域に、意味理解を注入して到達範囲を広げた点にある」という読み方ができます。

Claude Mythos のスペックと既存モデルとの違い

ベンチマーク比較

Mythos Preview と Claude Opus 4.6 のベンチマーク比較が公開されています。

ベンチマーク	Mythos Preview	Claude Opus 4.6
CyberGym（脆弱性再現）	83.1%	66.6%
SWE-bench Pro	77.8%	53.4%
Terminal-Bench 2.0	82.0%	65.4%

注目すべきは CyberGym だけでなく、汎用コーディングベンチマークの SWE-bench Pro や Terminal-Bench でも大きく上回っている点です。Mythos はセキュリティ特化で微調整されたモデルではなく、汎用的なコード理解・推論能力の向上がそのままセキュリティ能力に直結している構造だと読めます。Anthropicの技術レポートにも「コード、推論、自律性の全般的な改善から自然に出現した能力であり、サイバーセキュリティタスクのための明示的な訓練は行っていない」と記されています（Claude Mythos Preview - red.anthropic.com）。

この「自然発生」という言い回しは慎重に捉える必要があります。完全な偶然というよりは、訓練データ・スキャフォールド・RLHF段階で「コードを読んで仮説を立て、実行して検証する」という推論ループを強く学習させた結果として、セキュリティ能力が副産物的に伸びたと解釈するのが妥当でしょう。SWE-bench Pro の大幅な上昇は、Mythos がコードベース全体を対象に複数ステップの変更を計画できるエージェント能力を獲得したことを示唆しており、それがそのまま「コードを読み、仮説を立て、PoC を書いて検証する」というゼロデイ探索のループとほぼ同型になっていることに気づきます。

エクスプロイト開発能力の質的な差

数値以上に衝撃的なのが、エクスプロイト開発における質的な飛躍です。

Firefox JavaScriptエンジンのエクスプロイト: Mythos は181件の動作するエクスプロイトを生成。Opus 4.6 は同じ試行で2件のみ
OSS-Fuzz（1000リポジトリ対象）: Mythos は595件の Tier 1-2 クラッシュと10件の完全な制御フロー乗っ取りを達成。Opus は単発の Tier 3 クラッシュにとどまった
Linuxカーネル権限昇格: Mythos は2〜4件の脆弱性を自律的にチェーンして KASLR バイパスを含む特権昇格を達成。Opus は脆弱性を発見しても攻撃への連鎖ができなかった

Opus 4.6 の時点で「自律的なエクスプロイト開発の成功率はほぼ0%」だったのが、Mythos では実用レベルに達しています。この能力の非連続なジャンプが、Anthropicが公開を見送った最大の理由です。ここで重要なのは「脆弱性を見つける」と「見つけた脆弱性を攻撃につなぐ」の間には大きな段差があるという認識です。攻撃チェーンの構築には、メモリレイアウトの推測、ガジェット探索、制約付きの入力生成、保護機構（ASLR、KASLR、CFI）の回避など、複数の異なるサブタスクを破綻なく連結する必要があります。Mythos はこのオーケストレーションを自律的に行えるところまで来た、というのが要点です。

LLMはどうやって脆弱性を発見するのか

従来手法との根本的な違い

脆弱性の発見には大きく3つの従来手法があります。

ファジング: ランダムまたは半ランダムな入力を大量に投入し、クラッシュを誘発する
静的解析: コードを実行せず、パターンマッチや型情報でバグの可能性がある箇所を検出する
人手によるコードレビュー: セキュリティ研究者がコードを読み、論理的にバグを推測する

Mythos のアプローチは3番目、つまり「人間のセキュリティ研究者がコードを読んで推論する」行為のスケーラブルな自動化です。ただし単純な模倣ではなく、以下の点で従来手法それぞれと差別化されています。

ファジングとの違いは「意味の理解」です。ファジングは入力空間を確率的に探索するため、複合条件がそろったときだけ顕在化するバグにはほぼ到達できません。後述するFFmpegのスライス番号衝突は典型例で、ファザーは500万回実行してもヒットできませんでした。Mythos は H.264 の仕様を理解したうえで「この条件が重なるとヒープ境界外書き込みが起きる」と推論し、そこから逆方向に入力を構築しています。

静的解析との違いは「文脈と実行の両面から検証できる」点です。従来の静的解析はパターンベースなのでどうしても偽陽性が多く、セキュリティ担当者が結果を取捨選択する人件費がボトルネックでした。Mythos はエージェントとして実際にプロジェクトをビルドし、仮説をコードとして書いて走らせ、クラッシュするかどうかを直接確認します。静的解析 + 動的検証 + 自然言語による仮説説明が一体化しているのが特徴です。

人手レビューとの違いは「規模」です。人間のセキュリティ研究者が1つの脆弱性を発見するには数時間から数週間かかりますが、Mythos は数分から数時間で同等の深さの調査をこなせる。さらに1000リポジトリを並列で回すという横展開にも耐えられる。このスケーラビリティこそが、数千件という数字の背景にあります。

スキャフォールドは意外なほどシンプル

技術レポートで公開されているエージェント構成は、思っていたよりずっとシンプルです。次の手順で構成されています。

テスト対象のプロジェクトとソースコードを含むコンテナを起動（インターネット遮断）
Claude Code に Mythos Preview を指定して「脆弱性を探せ」と指示
Mythos がコードを読み、仮説を立て、プロジェクトを実行して検証する
ファイルを脆弱性の可能性スコア（1〜5）でランク付けし、高スコアから優先走査
二次エージェントが発見結果を検証し、PoC と再現手順を含むレポートを出力

大事なのは「エージェントの構成が特別複雑ではない」という事実です。Mythos の強みは、スキャフォールドの工夫よりも、モデル自身のコード理解力と長期推論能力にあります。逆に言えば、同等の能力を持つモデルさえ手に入れば、今日の Claude Code や類似のエージェント枠組みでも同じスキャフォールドを組めてしまうということです。これが後述する「業界全体への拡散」の議論につながります。

Gitコミット履歴からのパターン学習

もう一つの発見経路として、Mythos は過去の Git コミット履歴を分析し、過去に修正された脆弱性と類似の未修正パターンを探索します。これは Big Sleep が SQLite の脆弱性を発見したときの手法とほぼ同じ系譜です。

GhostScript の事例では、スタック境界チェックに関する過去のコミットを調べ、同じ保護が欠落している別のコードパスを特定しました。OpenSC の事例では、strcat の連鎖呼び出しによるバッファオーバーフローを検出しています。これらは「ファザーがほとんど到達しない前提条件の多いコードパス」にある脆弱性でした。

この手法の本質は「過去の修正 = 人間が正解ラベルを付けてくれた教師データ」と見なすことです。LLM は大量の CVE、コミットログ、パッチ、リグレッションテストを学習データとして持っており、そこから「どんなコード断片が過去に脆弱性として修正されたか」という分布を内面化しています。そのうえで、目の前のコードベースで類似パターンが未修正のまま残っていないかを推論する。ここには「量で攻める」でも「パターンで引っかける」でもない、第4の方法論が立ち上がりつつあります。

Mythos は他のモデルより何が優れているか（仮説）

ここから先は公開情報から読み取れる仮説ですが、Mythos の優位性はおそらく次の要素の合成です。

長いトークン列にわたる因果関係追跡能力。関数間、ファイル間、モジュール間の呼び出しグラフを頭の中に保持し続けられる
仮説 → 実行 → 観測 → 仮説修正のループを破綻なく数十ターン回せる安定したエージェント性
デバッガやプロセス監視ツールを道具として使いこなす能力（Claude Code のツール使用スキル経由で強化されたと考えられる）
セキュリティ関連のコーパス（CVE、exploit-db、学術論文、過去のバグレポート）を豊富に含む訓練データ

これらはどれも「セキュリティ専用チューニング」ではなく、汎用コード能力を底上げする方向の改善です。だからこそ Anthropic は「意図せずに強くなった」と表現しているわけで、そこに逆説的な怖さがあります。次世代の汎用モデルを出すたびに、意図せずセキュリティ能力が非連続にジャンプする可能性が常につきまとうことになります。

なぜ一般公開しないのか: Dual-use問題

攻守非対称性という構造的問題

Anthropicは公式ページで次のように述べています。

フロンティアAIの能力は、世界で最も重要なソフトウェアに存在する多数の欠陥を悪用するために使われうる

問題の本質は「攻撃と防御の速度差」です。Picus Security の分析では、LLM を活用した攻撃者が 106カ国・2,500組織を1時間以内に侵害した事例が報告されています。攻撃側は「マシン速度」で動けるのに対し、防御側はパッチの開発・テスト・デプロイという「カレンダー速度」でしか対応できません（Picus Security - The Glasswing Paradox）。

Mythos が見つけた脆弱性のうち、発表時点でパッチが適用されたものは1%未満です。仮に Mythos を一般公開すれば、攻撃者が防御側のパッチ適用より先に脆弱性を発見・悪用するリスクが極めて高くなります。Dual-use 問題とは、本来「抽象的な安全保障の話」として語られがちですが、Glasswing ではこの非対称性が定量的な形で目の前にあることが決定的でした。

なぜ40社という数字なのか

40社という数字は一見中途半端に見えますが、「世界のソフトウェアインフラの上層をほぼ網羅できる最小の集合」として選ばれた可能性が高いです。OS（Microsoft、Apple、Google、Linux Foundation）、ブラウザ（Google、Mozilla周辺、Apple）、クラウド基盤（AWS、Google、Microsoft、Broadcom、Cisco、NVIDIA）、金融（JPMorgan Chase）、セキュリティベンダー（CrowdStrike、Palo Alto Networks）── この12社のローンチパートナーが押さえている領域を足し合わせると、世界のソフトウェアの攻撃対象面の大部分が入ります。

さらに追加の30社弱にはオープンソース団体や特定領域のインフラ企業が含まれていると見られ、「40社以上に広げると情報漏洩リスクが一気に上がるが、これ未満だと重要インフラを守り切れない」というトレードオフの解として選ばれた数字だと解釈できます。契約条件としては、Anthropic は利用目的を「自社ソフトウェアまたは自社が保守する OSS の脆弱性発見・修正」に限定し、発見された脆弱性はすべて協調開示プロセス（90日 + 45日の猶予期間）を経由するよう義務付けています。

Anthropic の多層セーフガード

Anthropic は以下の多層的な安全策を講じています。

利用目的の契約的限定（自社または自社保守 OSS のみ）
協調開示プロセス経由の必須化と、未パッチ脆弱性の SHA-3 ハッシュ公開
モデル内部のアクティベーションを監視する「プローブ」による悪用検出
悪意のあるトラフィックをリアルタイムで遮断する介入機構
将来の Claude Opus モデルに新しいセーフガードを実装したうえで、正当なセキュリティ専門家向けの「Cyber Verification Program」を立ち上げる計画

SHA-3 コミットメントハッシュは特に興味深い手法です。発見された脆弱性の詳細を暗号的にコミットしつつも、実際の内容はパッチ公開後まで伏せる。これにより「発見の事実」と「発見の中身」を時間軸で分離できる。今後業界標準になっていく可能性があります。

100M ドル拠出の経済合理性

1億ドルの API クレジット拠出は、一見「気前の良い寄付」に見えますが、Anthropic にとっての経済合理性を細かく見ると納得感のある構造です。

第一に、40社の大企業を Mythos の実運用に巻き込むことで、Anthropic は「最も価値の高いドッグフーディング環境」を手に入れます。自社の一般公開モデルでは得られない、本気のセキュリティワークロードのフィードバックが集まるわけです。1億ドルのクレジットは、同等のフィードバックを外部調達するよりはるかに安い投資です。

第二に、Glasswing は Anthropic を「責任あるフロンティアラボ」というポジションに強烈に紐付けます。競合が似たような能力を持つモデルを先に一般公開したとき、規制当局とエンタープライズ市場は「AnthropicはRSPに沿って自主規制した」という事実を記憶しています。これはエンタープライズ契約とホワイトハウス・議会とのパイプラインの両方で長期的に効いてきます。

第三に、40社のパートナー企業のうち少なからぬ数が、Mythos の限定アクセス経験を経て Anthropic とより大きな年間契約に流れる可能性があります。API クレジットは実質的に「戦略顧客向けの販売促進費」としても機能します。

つまり100Mドルは、セキュリティ研究支援、ポジショニング投資、エンタープライズ販促、この3つを同時に達成するレバレッジの高い資金投下だと見ることができます。

過去のAIによる脆弱性発見事例との比較

ここで過去の事例を並べておくと、Mythos がどれだけ踏み込んだかが見えやすくなります。

事例	発見対象	規模	自律性
Google Big Sleep（2024）	SQLiteのスタックバッファアンダーフロー	単一の脆弱性	エージェントによる発見、PoC生成まで
XBOW（2025）	HackerOneで1,060件	数千件レベルで大企業の外部攻撃面	自律ペンテスト、ただし人手で事前レビュー
Anthropic Opus 4.6（2025）	500件超の OSS 高深刻度脆弱性	中規模	発見までは自律、エクスプロイト構築はほぼ不可
Anthropic Mythos（2026）	OS・ブラウザを含む数千件	大規模	発見から攻撃チェーン構築まで自律

Big Sleep が「LLMで脆弱性を見つけられる」ことを示し、XBOWが「外部からの自律ペンテストで人間を超えられる」ことを示し、Opus 4.6 が「コードベース内部からのゼロデイ発見も自律化できる」ことを示した。そして Mythos は「見つけた脆弱性を実攻撃に変える」一線を越えた初の事例、という系譜になります。

コミュニティの反応

Hacker Newsでの議論

Hacker News のスレッドでは、賛否が分かれました。懐疑派は「毎回のモデルリリースで『パラダイムシフト』と言われるのにうんざりしている」「独立検証のない派手なプレスリリースだ」と批判しました。セキュリティ専門家からは「85%の成功率」のような数値は「深刻度、実際の攻撃可能性、影響範囲のコンテキストがなければ意味がない」という指摘もありました。

一方、実態を裏付ける証言もあります。先述の Greg Kroah-Hartman 氏と Daniel Stenberg 氏の発言は Glasswing 発表前のものであり、Mythos 級のモデルが既にテストされていたことを示唆します。また「既に Opus 4.6 で脆弱性を発見して報奨金をもらった」と報告するユーザーもいました。

Simon Willison 氏は自身のブログで「一般公開しないという判断は、この能力水準では必要な選択に見える」と率直に評価しています（Simon Willison）。過度な興奮でもなく過度な懐疑でもなく、ここで公開を止めたことをポジティブに捉える立場です。

オープンソースモデルの追随可能性

r/LocalLLAMA コミュニティ（会員26万人超）では、オープンソースモデルでのセキュリティ研究も進んでいます。2026年時点で DeepSeek-R1、Qwen3-235B-A22B、GLM-4.5 がサイバーセキュリティ用途で推奨されるオープンソースモデルとして挙げられています。

ただし現時点で、オープンソースモデルが Mythos と同等の「自律的エクスプロイトチェーン構築」を達成したという検証可能な報告はありません。Opus 4.6 相当の「脆弱性の発見」と、Mythos 相当の「発見した脆弱性の自律的な攻撃への連鎖」には質的な隔たりがあります。

とはいえ、Anthropic 自身が「同様の能力は今後1年以内に業界全体で利用可能になる」と認めている点は重要です。Mythos の限定公開は防御側の「先行期間」を確保する措置であり、永続的な独占ではありません。この先行期間をどう使うかが、Glasswing 全体の成否を決めます。

開発者・セキュリティ担当者にとって何を意味するか

シナリオを想像する: Apple／Google の活用

発表時点で公開されている情報からは、各社がどう Mythos を使っているかは明かされていません。ただしローンチパートナー各社の事業特性から、実務的な活用シナリオは想像できます。

Apple は macOS / iOS のカーネルとコアフレームワーク、WebKit、Safari の JavaScriptCore に対して Mythos を回すと考えるのが自然です。特に WebKit は過去10年にわたって状態遷移起因の UAF が繰り返し発見されてきた領域であり、Mythos が得意とする「複合条件のロジックバグ」と相性が良い。Google の場合は Chromium、V8、Android のメディアコーデック、そして gVisor や Fuchsia などサンドボックス実装が対象になりうるでしょう。Linux Foundation は当然カーネルそのものと主要 OSS ディストリ、Microsoft は Windows カーネルと Edge、Microsoft 365 周辺、CrowdStrike や Palo Alto Networks は自社製品とお客様環境のテレメトリを組み合わせた防御知見の生成、といった具合です。

各社に共通する構図は「自社の製品を、自社のセキュリティチームが通常より1〜2桁多い探索予算で Mythos に監査させる」ことです。結果のうち真のゼロデイは協調開示プロセスに入り、ノイズは社内で吸収されます。

パッチ適用速度が生存戦略になる

Mythos が突きつけた現実は「発見速度が人間のパッチ適用速度を圧倒的に上回った」ことです。発見のボトルネックが解消された今、次のボトルネックは修正と展開です。開発者として意識すべきことは次の通りです。

パッチ適用のリードタイムを短縮する CI/CD パイプラインの整備
依存ライブラリの脆弱性情報を自動監視する仕組み（Dependabot、Renovate、Snyk、Socket等）の導入
SBOM の作成と管理。自分のソフトウェアが何に依存しているかを即座に把握できる状態の維持
セキュリティパッチの「デプロイ猶予期間」を従来の週単位から日単位に短縮する体制

「うちはオープンソースだから関係ない」という態度は最も危ういポジションです。Mythos の初期ターゲットにはオープンソースが多く含まれており、攻撃者の側が将来 Mythos 級モデルを手に入れた瞬間、OSS のメンテナは「1週間で百件の真贋混じった脆弱性レポート」に対応する立場に立たされます。

メモリ安全性の再評価

Mythos が発見した脆弱性の多くは C/C++ のメモリ安全性に起因するものです。Rust、Go、Zig などメモリ安全な言語への移行は以前から推奨されてきましたが、LLM による脆弱性発見の高速化により緊急度が一段上がりました。新規プロジェクトで C/C++ を選択する場合は、メモリ安全性に対する追加の正当化（パフォーマンス要件、エコシステム依存、既存資産との互換性など）が求められる空気になってきています。

Linux カーネルの Rust 受け入れや、Android / Windows のユーザー空間コンポーネントの Rust 移行はここ数年のトレンドでしたが、Mythos 以降は「マネジメントが Rust 移行を承認する際の根拠の一つ」として Glasswing の数字が引用されるケースが増えていくでしょう。

自社セキュリティで LLM をどう使うか

Mythos を待つ必要はありません。Opus 4.6 の時点で OSS から500件以上のゼロデイを発見できている事実は、現行の API アクセス可能なモデルでも有意なセキュリティ監査が行えることを意味します。実践レベルで考えられるアプローチは次の通りです。

自社コードベースに対して LLM ベースの脆弱性スキャンをパイプラインの一段として試行する。既存の SAST ツールの後段に LLM による二次レビューを挟むのが導入しやすい
過去の Git コミット履歴を LLM に読ませ、「同じパターンの未修正箇所がないか」を定期的に検査する（Big Sleep 型アプローチ）
社内 CVE 対応のトリアージに LLM を組み込む。影響度判定と修正コード片の候補生成は、LLM が得意な領域
PR レビューの段階で、セキュリティ観点のチェックプロンプトを組み込む。Claude Code などのエージェント型ツールと相性が良い

いずれも完全自動化する必要はなく、「人間のトップレビュアーの負担を減らす」補助輪として導入するだけでも効果があります。

協調開示の重要性の高まり

LLM が大量の脆弱性を発見する時代では、協調開示（Coordinated Disclosure）のプロセスがこれまで以上に重要になります。Anthropic が採用した SHA-3 コミットメントハッシュ方式は、発見の事実と内容を時間軸で分離する手法として、今後の業界標準になる可能性があります。自社が未対応の脆弱性を抱えている段階で攻撃者が先に同じ脆弱性に到達するリスクを下げるために、このような仕組みは防御側にとって有用です。

まとめ

Project Glasswing は、LLM の能力が「脆弱性の発見」から「自律的なエクスプロイト開発」へと非連続的に進化したことへの、Anthropic なりの回答です。核心は次の3点に集約できます。

Mythos は汎用的なコード理解能力の向上から副産物的に強化されたセキュリティ能力を持つ。専用チューニングの産物ではないため、次世代モデルでも同様の非連続ジャンプが起こりうる
ファジングや静的解析では見つからない複合条件の脆弱性を、コードの意味理解と仮説検証のループで発見できる。エージェントのスキャフォールドは意外なほどシンプルで、能力の大半はモデル本体に宿っている
同等の能力は1年以内に業界全体へ広がる見込みであり、Glasswing の限定公開は「独占」ではなく「防御側の先行期間の確保」として設計されている

セキュリティの世界では昔から「攻撃者は1つの穴を見つければよいが、防御者はすべての穴を塞がなければならない」と言われてきました。LLM が攻撃側・防御側双方の能力を底上げする時代に、この非対称性がどう変化するかは予断を許しません。ただし確実に言えるのは、発見のコストが劇的に下がった以上、次のボトルネックは「どれだけ速く直し、どれだけ速く配れるか」に移ったということです。

開発者としてできることは、パッチ適用の高速化、メモリ安全な言語の採用、LLM を活用したセキュリティ監査の導入を、今日から小さくでも始めることです。Glasswing の限定公開はあくまで猶予期間であり、その猶予が終わったとき、備えていたチームと備えていなかったチームの差は想像以上に大きくなるはずです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up