かつては発見した問題ごとに個別の継続的な調査が必要だったセキュリティ研究を、体系的なプロセスとして実行できるようになりつつあります。本稿では、この分野における私たちの取り組みの一つを紹介します。
脆弱性の発見は規模を拡大しやすくなっていますが、優先順位付けと検証は依然として運用上のボトルネックです。私たちは、管理された研究環境内で Linux カーネルのセキュリティ上の欠陥を探すプロトタイプを構築しました。このプロトタイプは Linux カーネルの脆弱性候補 2,308 件を特定・分析し、1,724 件の脆弱性を動的に再現しました。また、権限のないローカルユーザーが root アクセスを取得できるローカル権限昇格（LPE）エクスプロイトを 948 件生成しました。
私たちはこの証拠を使って報告する脆弱性に優先順位を付け、メンテナーのレビューに向けてパッチ候補を開発しました。Linux カーネルコミュニティの助言に従い、深刻な脆弱性から対応を始め、Patch the Planet のパートナーとともに、さらなる報告とパッチの作成を進めています。
6 月には、Patch the Planet の取り組みの一環として、GPT‑5.5 Cyber が Linux カーネルの脆弱性を特定し、その検証と報告のために 24 件のローカル権限昇格エクスプロイトを開発したことを発表しました。その取り組みを発展させ、今後提供予定のサイバーモデルを活用して、脆弱性の発見、動的検証、悪用可能性の評価、パッチ生成までを網羅するパイプラインを構築しました。実行完了後、人間の研究者が出力をレビューし、発見された脆弱性をパッチとともに報告しました。
概要
手法
パイプラインの大まかな流れは次のとおりです。まず Linux カーネルのうちセキュリティに関わる部分を特定し、監査対象を静的にスキャンして脆弱性の候補を検出します。次に、隔離環境で候補を動的に再現し、悪用可能性を実証する概念実証（PoC）エクスプロイトを作成して、パッチを生成します。最後に、人間のセキュリティ研究者が結果をレビューします。
パイプラインは、根本原因の分析、クラッシュを再現する最小限の概念実証コード、パッチ候補、完全なエクスプロイトを出力します。これらは、人間の研究者による脆弱性の深刻度評価と、修正のアップストリームへの反映を支援します。
結果
2026 年 10 月中旬、今後提供予定のサイバーモデルを使用してパイプラインを実行したところ、1,724 件の脆弱性を動的に再現し、広く使われている Linux ディストリビューション向けに、291 件の情報漏えいの脆弱性に対する PoC と、実際に動作する 948 件のローカル権限昇格（LPE）エクスプロイトを生成しました。実行全体の API クレジット費用は 1,213,430 ドルで、LPE エクスプロイト 1 件あたり 1,279 ドルでした。
対象の仮想マシンでは、意図的に保護を弱めた環境ではなく、標準構成のデスクトップ OS を使用しました。脅威モデルは、サイバーセキュリティ競技（Pwn2Own（新しいウィンドウで開く）、TyphoonPWN（新しいウィンドウで開く） など）で使われるものと同じです。過去に Pwn2Own と TyphoonPWN は、Linux カーネルの LPE エクスプロイトに対し、それぞれ 20,000 ドルと 70,000 ドルのバグ報奨金を設定していました。この過去の報奨金額を 948 件のエクスプロイトに当てはめると、仮想的な評価額は 1,890 万～6,630 万ドルとなり、パイプラインのコストの約 16～55 倍に相当します。
攻撃対象領域を縮小した Linux カーネルを用いる kernelCTF（新しいウィンドウで開く） の環境に一部調整を加えて実行したところ、パイプラインは 25 件の情報漏えい PoC と 21 件の LPE エクスプロイトを生成しました。比較として、執筆時点で kernelCTF が 2026 年に受理した、確認済みのゼロデイ LPE エクスプロイトは 26 件です。
この検証にかかった API クレジット費用は約 32,936 ドルでした。この 21 件の脆弱性がプログラムに受理された場合、報奨金は約 150 万ドルとなり、スキャン費用の約 45 倍に相当します。
私たちが把握する限り、このパイプラインのエージェントは、少なくとも 10 種類の新しい Linux エクスプロイト手法を発見し、使用しました。
考察
Linux のメンテナーとセキュリティコミュニティは、脆弱性の迅速な発見と修正に精力的に取り組んでいます。スキャンを実行していた 10 日間で、100 件を超える Linux の LPE について、他の貢献者によるパッチが適用済み、または適用準備中となり、さらに約 300 件が公開の場で議論されていることを確認しました。
フロンティアモデルによる脆弱性発見の速さを踏まえると、必要なペースでソフトウェアの安全性を確保し、悪用可能な期間を短縮するには、パッチの自動生成が不可欠だと考えています。人間の専門家の指導のもとで改善を重ねれば、AI が生成するパッチも、機能的に正しく、既存のコーディングスタイルに沿い、攻撃の亜種にも強いものにできると考えています。これは、今後さらに研究を進めるべき重要な分野です。
能力の高いモデルは、既存のコードから新たな脆弱性を発見できます。その中には、長期間潜在し、特定がより難しい脆弱性も多く含まれます。7 月の GPT‑5.6 Sol による実行から 3 か月間のセキュリティ強化が行われたにもかかわらず、10 月中旬に新しいサイバーモデルを使った分析パイプラインは、その 5 倍を超える数の新規 LPE を発見しました。
大規模で複雑なソフトウェアプロジェクトでは、潜在的なバグを「洗い出し切る」まで、スキャンと脆弱性の修正を何度も繰り返す必要があると考えられます。理想的には、フロンティアモデルの世代が進むたびに、このプロセスを繰り返します。これは、プロプライエタリソフトウェアにもオープンソースソフトウェアにも当てはまります。
短中期的には、利用可能な最新パッチが適用されていない OS の低権限アカウントへのアクセスは、十分なリソースを持つ攻撃者にとって、実質的に root アクセスと同等であると考えるべきです。脆弱性が悪用された際の影響範囲を抑えるには、サンドボックスや Firecracker、gVisor などの隔離手法を活用した多層防御が重要です。
今後数年以内に、ソフトウェアプロジェクトに脆弱性が存在すれば、フロンティアモデルがそれを発見できる可能性が高くなると考えています。また、公開後には、能力がより低いモデルでもエクスプロイトを開発できる可能性があります。未知の脆弱性がなくなる世界では、高い安全性が保証されたソフトウェアの構築と維持が極めて重要になります。特に、OS、ブラウザー、画像解析ライブラリ、TCP/IP スタックなどの中核的なソフトウェアが重要です。既存の脆弱性の発見と修正に加え、標準で安全なコードを書くようモデルを訓練することへの投資、不要な機能の削除による攻撃対象領域の最小化、形式検証は、ソフトウェアのセキュリティ対策を効果的に拡大するうえで有望な研究分野です。
Linux カーネルは、Android デバイス、クラウド基盤、スーパーコンピューターなど、数十億人が利用するシステムを支えています。4,000 万行を超えるコードを持つこのカーネルには、システムコール、ネットワーク、ファイルシステム、デバイスドライバーを通じて、広範な攻撃対象領域が存在します。私たちは、これほど大規模かつ重要なコードベースで、フロンティアモデルがどれほど効果的に脆弱性を発見し、セキュリティへの影響を実証できるかを調べるために、Linux を選びました。
最初の脆弱性発見段階では数千件の候補が検出され、セキュリティ研究者が手作業でレビューやトリアージを行うには多すぎる数でした。脆弱性発見パイプラインの運用上の課題は、発見そのものではありませんでした。どの候補が再現可能で、どのセキュリティ境界を越え、どれをメンテナーに最優先で確認してもらうべきかを判断することが課題でした。
OpenAI の Cyber チームの使命は、世界が依存するソフトウェアの安全確保を支援することです。研究者がこの取り組みを再現・発展させるために必要なリソースを見積もれるよう、各段階の API 費用を報告します。これらの費用は、今回の評価で使用したモデル、対象環境の構成、ワークフローを反映したものです。私たちのより大きな目標は、防御側による脆弱性の発見と修正を支援し、攻撃者が利用できる機会を減らすとともに、ソフトウェアの悪用にかかるコストを引き上げることです。
なお、本研究で重点を置いたのは手法とモデルの能力測定であり、コストではありません。ハーネスの設計・実装を十分に最適化すれば、各段階のコストを大幅に削減できると考えています。そのため、報告する費用は上限に近い値として捉えてください。
私たちの脆弱性研究プロトタイプは、今後提供予定のサイバーモデルを中核とする、次の 5 段階のパイプラインです。
脆弱性の発見：エージェントがコードベース内のセキュリティに関わる部分を特定し、スキャンして脆弱性の候補を検出します。
動的検証：エージェントが隔離環境で各候補の再現を試み、実行時の証拠を保存します。このステップでは、再現・検証された脆弱性が出力されます。
悪用可能性の評価：エージェントが、検証済みの脆弱性によって情報漏えいやローカル権限昇格が可能かどうかをテストします。
パッチ生成：エージェントが、特定された各脆弱性に対応するパッチを生成します。
人間によるレビュー：セキュリティ研究者がエクスプロイト、パッチ、深刻度の評価案をレビューしたうえで、メンテナーに報告します。
パイプラインの最後に、システムは根本原因の分析、クラッシュを再現する最小限の概念実証コード、パッチ候補、完全なエクスプロイトをまとめます。これらは、人間の研究者による脆弱性の深刻度評価と、修正のアップストリームへの反映を支援します。
Linux カーネルのすべてのコード行がセキュリティに関係するわけではありません。パイプラインでは、探索エージェントのチームが監査する価値の高い対象を特定し、分析エージェントに引き渡して脆弱性をスキャンしました。
探索エージェントは各フォルダーとファイルを読み、到達可能性（低権限ユーザーが到達できるか）とセキュリティとの関連性に基づいて監査対象を決定します。
この段階で 5,034 件の監査対象、約 280 万行のコードを特定しました。これは Linux カーネルのコードベース全体の約 7% に相当し、コードベース全体を分析する場合と比べて、セキュリティ監査のコストを大幅に削減できました。このステップの API クレジット費用は 3,426 ドルでした。
次に、分析エージェントが各監査対象を分析し、Codex Security プラグイン（新しいウィンドウで開く）と同様のワークフローで脆弱性の候補を検出しました。大まかに言うと、分析エージェントは割り当てられた監査対象のコードを読み、動作を理解して脅威モデルを特定し、脆弱性を探します。
分析エージェントは 12 時間以内に、重複を除いて 2,308 件の候補を検出しました。この段階の API クレジット費用は 316,549 ドルでした。
検出された候補は、検証済みの脆弱性と同じではありません。この規模になると、私たちの研究チームがすべてのレポートを手作業で調査するのは現実的ではありません。
そこで、a）低権限ユーザーが到達できる、b）特別なケーパビリティを必要としない、c）メモリ破損の測定可能な証拠が得られる、という条件を満たす候補の検証に重点を置きました。
トリアージエージェントは候補ごとに概念実証コードを生成し、Kernel Address Sanitizer（KASAN）を有効にした Linux カーネルが稼働する隔離された仮想マシン内で実行しました。エージェントはプログラムの出力とシステムコンソールの両方を観察し、報告された挙動を再現できるか、考えられる発生方法を試し尽くすまで、概念実証コードを繰り返し改良しました。
システムは 30 時間以内に、2,308 件の候補の約 74.7% にあたる 1,724 件の脆弱性を再現しました。静的なコードレビューだけでは誤検知が生じやすいため、分析エージェントの精度の高さと、候補のほぼ 4 分の 3 について動作する概念実証コードを自律的に作成したトリアージエージェントの有効性は、印象的でした。
残る候補の大半は、より高い権限が必要なものか、再現の難しい競合状態、特定の発生条件（特定の行でのメモリ割り当て失敗など）、時間のかかる検証（参照カウントのラップアラウンドなど）が原因で、制限時間内に再現できなかったものでした。モデルの分析が誤っていたのはわずか 3.1% で、これらの報告は発生し得ない条件を前提としていました。
検証段階の API クレジット費用は、合計 73,330 ドルでした。検証パイプラインでは、候補が実際の脆弱性かどうかを確認するために概念実証コードを生成する必要がありました。このプロセスは静的分析のみに基づく推奨よりも高コストで、真陽性と偽陽性の検証を試みる費用に大きな差はないことがわかりました。そのため、パイプラインの早い段階で誤検知を除外すれば、プロセスのコスト効率を大きく改善できます。
検証によって脆弱性が実在することは確認できますが、どの程度急いで対応すべきかはわかりません。たとえば、ローカル権限昇格を可能にする脆弱性は、ローカルでのサービス拒否しか引き起こさない脆弱性よりも、優先して対応する必要があります。1,724 件の脆弱性が検証された後、次の課題は、セキュリティへの潜在的な影響が最も大きいものを特定することでした。
一次スクリーニングを担うエージェントが、各レポート、クラッシュログ、関連するソースコードを静的にレビューしました。深刻な可能性のある候補を捨てないよう、意図的に選別基準を緩くする一方で、現実的な悪用経路のないケースは除外しました。これにより、情報漏えい候補 313 件とローカル権限昇格候補 1,238 件に絞り込みました。
次に、エクスプロイト開発（ExploitDev）エージェントが、標準的な Linux ディストリビューションで有効になっている保護機能を備えた隔離された仮想マシン内で、これらの候補をテストしました。保護機能には、スーパーバイザーモード実行防止（SMEP）、スーパーバイザーモードアクセス防止（SMAP）、カーネルアドレス空間配置のランダム化（KASLR）、HARDENED_USERCOPY が含まれます。これにより、保護機能の無効化を前提とする非現実的な評価を防ぐことができました。
エージェントは、情報漏えいの概念実証コード 291 件と、権限のないローカルユーザーが root アクセスを取得できる、動作確認済みのローカル権限昇格エクスプロイト 1,169 件を生成しました。
私たちは亜種分析を行い、これらのエクスプロイトが利用する脆弱性に対して、948 件の異なるパッチを開発しました。この数値を、重複を除いた LPE の総数としています。成功したエクスプロイトの開発には、平均 359 ドルのクレジット費用がかかりました。つまり、防御側は、発見した脆弱性の悪用可能性を比較的低コストでテストできます。
脆弱性の一次スクリーニングを行うエージェントの API クレジット費用は 44,194 ドルでした。エクスプロイト段階の API クレジット費用は合計 775,929 ドルで、情報漏えい候補の処理に 84,929 ドル、ローカル権限昇格候補の処理に 691,000 ドルかかりました。
平均すると、ローカル権限昇格候補の処理費用（558 ドル）は、情報漏えい候補の処理費用（271 ドル）の約 2 倍でした。これは、情報漏えいの PoC は検証段階から引き継がれており、エクスプロイトで利用できるようにするための修正が少なく済んだためです。一方、LPE 候補からエクスプロイトを開発するには、悪用戦略の立案、利用する脆弱なオブジェクトの特定、緩和策の回避など、多くの追加ステップが必要でした。また、悪用に失敗した試行（69 件、3,922 ドル）は、成功した試行（1,169 件、360 ドル）よりも大幅に高コストであることがわかりました。これは、競合状態など、悪用が難しい一部の脆弱性が原因でした。1 時間進展がなければ試行を停止するなど、合理的な打ち切り条件を設定していれば、ExploitDev のコストを大幅に削減できたと考えられます。
システムは、検証された脆弱性ごとにパッチも生成します。モデルに関連するソースコードを提供し、パッチ作成のベストプラクティスを指示します。具体的には、パッチの静的チェック、周辺のコードで用いられている開発慣行の順守、パッチの完全性を確認するための亜種分析などです。
Linux カーネルコミュニティの提案に従い、深刻な脆弱性に関する数百件のレポートとパッチをすでに送付しました。残りのパッチも段階的に送付できるよう、Patch the Planet のパートナーと協力しています。この活動は、オープンソースプロジェクトを支援する、より広範な Daybreak の取り組みの一環です。
このセクションでは、本研究で得られた知見や考察、追加の分析を紹介します。
本研究を通じて、Linux のメンテナーが脆弱性を修正し、ユーザーを保護するために迅速に対応していることを確認しました。スキャンは 2026 年 10 月中旬、最新の Linux カーネルを対象に実施しました。10 日後に自律型スキャンと手作業による分析が完了した時点で、61 件の LPE はすでにアップストリームで修正され、43 件はパッチの適用準備中で、299 件は公開の場で報告・議論されていました。
特定された問題の修正に急ぎ取り組んでいる Linux のメンテナーと、発見した問題を報告する幅広いセキュリティコミュニティに、深く感謝しています。世界のソフトウェアの安全を守るには、このような協力による対応が必要です。脆弱性の開示とパッチ適用が急速に進んでいることは、ユーザーと企業がソフトウェアを最新の状態に保つ重要性も浮き彫りにしています。
要点：自動トリアージでは、迅速なパッチ適用サイクルを考慮する必要があります。最初のスキャン後にマージされた新しいコードも含め、最新のコードに対して検出結果を再検証することで、重複した報告や、すでに対応済みの問題の報告を避けられます。これにより、未解決の脆弱性に注意を集中させ、不要なレビュー負担を増やさずに、メンテナーが対応に活用できる証拠を提供できます。
パイプラインを開発していた 2026 年 7 月下旬、GPT‑5.6 Sol は重複のない 166 件の LPE 脆弱性を発見し、悪用に成功しました。全工程の API クレジット費用は 513,690 ドルでした。
2026 年 10 月中旬の 2 回目のスキャンでは、より新しいサイバーモデルが重複のない 948 件の LPE 脆弱性を発見し、悪用に成功しました。全工程の API クレジット費用は 1,213,430 ドルでした。どちらの検証でも、実行時点で最新の Linux カーネルの master ブランチをスキャンしました。
要点：モデルの能力が向上したら、過去に監査したコードを再スキャンすることが重要です。同じ研究用ハーネスを使っていても、能力の高いモデルなら、以前のモデルが見逃した脆弱性を発見できる可能性があります。
エージェントが開発したエクスプロイトから 166 件を抽出し、使用されている手法を分析しました。私たちが把握する限り、抽出したエクスプロイトでは、エージェントが 10 種類の新しい手法を使用していました。これらの手法を外部のカーネルエクスプロイト専門家に共有したところ、専門家にとっても未知の手法でした。
10 種類のうち 2 種類は、対象のカーネルキャッシュ内にオブジェクトをスプレーするためにモデルが使った、新しい永続的な可変サイズのオブジェクトです。別の 2 種類は、エクスプロイトの信頼性を高める新しいページグルーミング手法です。5 種類は、直接または任意書き込みを介して権限昇格を実現する、データのみを操作する新しい手法で、残る 1 種類は任意の型混同を利用する手法です。安全上の理由から、本稿ではこれらの新しいエクスプロイト手法の技術的な詳細をすべて公開することは控えます。
要点：フロンティアモデルは、既知の脆弱なコードパターンとの照合や、既知のエクスプロイト手法の利用にとどまらず、創造性を発揮し、新たなアプローチを生み出しています。
脆弱性の発見と悪用にかかるコストを測定し、その証拠を防御への投資に役立てることは、私たちのチームの重要な使命の一つです。私たちの目標は、攻撃者が脆弱性を利用する前に防御側が修正できるよう支援し、攻撃者にとってソフトウェアの悪用がコストに見合わない状態にすることです。悪用にかかるコストを測定することで、モデルの能力向上に伴い、この課題がどう変化するかを評価できます。このセクションでは、パイプラインの実行コストと、特定した脆弱性に対するバグ報奨金プログラムの報奨額を比較します。
実験対象の仮想マシンでは、意図的に保護を弱めた環境ではなく、標準構成のデスクトップ OS を使用しました。脅威モデルは、サイバーセキュリティ競技（Pwn2Own（新しいウィンドウで開く）、TyphoonPWN（新しいウィンドウで開く） など）で使われるものと同じです。過去に Pwn2Own と TyphoonPWN は、Linux カーネルのローカル権限昇格エクスプロイトに対し、それぞれ 20,000 ドルと 70,000 ドルのバグ報奨金を設定していました。この過去の報奨金額を 948 件のエクスプロイトに当てはめると、仮想的な評価額は 1,890 万～6,630 万ドルとなり、パイプラインのコストの約 16～55 倍に相当します。
また、攻撃対象領域を縮小し、セキュリティを強化した Linux カーネルを対象とする Google の脆弱性報奨金プログラム、kernelCTF（新しいウィンドウで開く） の環境でもパイプラインを検証しました。 kernelCTF の環境下で最新バージョンの Linux カーネルを対象にパイプラインを実行し、25 件の情報漏えいの概念実証コードと 21 件のローカル権限昇格エクスプロイトを生成しました。なお、このカーネルは kernelCTF の緩和策 SLAB_VIRTUAL と互換性がなかったため、この設定を除外しました。比較として、執筆時点で kernelCTF が 2026 年に受理した、確認済みのゼロデイ LPE エクスプロイトは 26 件です。検証全体には計 112 時間を要し、API クレジット費用は約 32,936 ドルでした。API 費用の 83.7% は脆弱性の発見段階で発生しました。この 21 件の脆弱性がプログラムに受理された場合、報奨金は約 150 万ドルとなり、コストの約 45 倍に相当します。
要点：公表されている報奨金額に基づくと、現在のサイバー能力を備えたモデルを使う私たちの脆弱性研究パイプラインは、本研究の時点ではコストを差し引いても利益が出る計算でした。防御側は、攻撃者にとって悪用がコストに見合わなくなるよう、自らのソフトウェアを先回りして分析するべきです。
悪用可能性の評価では、ExploitDev エージェントに脆弱性レポートを渡し、完全に動作するエクスプロイトの作成を指示しました。パイプラインは、root シェルの取得に成功すると、その脆弱性の悪用に成功したと判定しました。初期の実行では、エクスプロイト段階で 200 件のローカル権限昇格エクスプロイトに成功したと報告されました。しかし、人間がレビューしたところ、そのうち 20 件は、割り当てられたものとは別のゼロデイ脆弱性を通じて root 権限を取得していたことがわかりました。このことは、エージェントによる悪用が成功した場合でも、適切な検証が必要であることを示唆しています。
その後、タスクの制約を厳格化し、最終的なエクスプロイトがそれぞれ割り当てられた脆弱性を使用していることを確認する、独立したチェックを追加しました。
要点：自律型セキュリティ研究では、結果そのものに加え、その結果に至る経路も検証する必要があります。隔離、監視、独立したチェックは、必要な管理策です。
研究の初期には、エージェントのサイバー能力を高めるために、周囲に複雑なオーケストレーションを構築するべきかを検討しました。結果は、能力の高いモデルほど、オーケストレーションや細かな支援を減らせることを示唆していました。また、追加で得られるわずかな改善は、保守コストに見合いませんでした。そのため、複雑なオーケストレーションを取り除くことにしました。
この実験では、GPT‑5.5 Cyber と GPT‑5.6 Cyber を比較しました。私たちの観察では、GPT‑5.5 Cyber は既存の Linux カーネルのエクスプロイト手法をいつ、どのように適用すべきかを、安定して判断できませんでした。そこで、103 種類の手法をモデルが扱いやすい形式にまとめ、エージェントの環境で利用できるようにして、それらを使用するよう指示しました。これにより、悪用候補 63 件に対する成功率は 76.2% から 88.9% に向上しました。
GPT‑5.6 Cyber で同じ実験を行ったところ、モデルは関連する手法の発見、選択、適用を、より自力で行うことができました。手法やスキルの利用を制御するオーケストレーションを取り除いたところ、軽量なオーケストレーションを用いた GPT‑5.6 Cyber のワークフローは、より手厚い補助の仕組みを備えた GPT‑5.5 Cyber のワークフローを上回りました。GPT‑5.6 Cyber に手法を提供する追加の仕組みを戻しても、改善はわずか 1.5 パーセントポイントにとどまりました。
要点：ベースモデルの能力の変化に応じて、オーケストレーションとハーネスを見直すことが重要です。ある世代のモデルで大きな改善をもたらす補助の仕組みも、より高性能なモデルではほとんど価値を加えない場合があるため、保守負担とのバランスを評価する必要があります。
当初、パッチ候補の生成を直接指示すると、モデルは概念実証コードによる攻撃を防ぐ、機能的に正しいパッチを作成しました。しかし、ときには別の問題を持ち込みました。必要以上のコードを追加する、性能を犠牲にする可能性が生じる、コーディング規約から逸脱する、同じ脆弱性の亜種がないか関連コードを調べず不完全なパッチになる、といった問題です。
指示の追加とパッチ生成プロセスの反復改善により、パッチの品質は向上しました。これは、適切に扱えば、AI が生成するセキュリティパッチも、正しく、必要最小限で、既存のコーディング規約に沿ったものにできることを示唆しています。これは活発に研究が進められている分野であり、将来のモデルでは、より容易かつ効果的に実現できると考えています。また、研究用プロトタイプが人間の専門家の書いたパッチの問題を特定し、マージ前に修正できたケースもいくつかありました。
要点：モデルはパッチ作成を加速できますが、パッチが機能要件と非機能要件の両方を確実に満たすには、パッチ作成スキルとハーネスの反復改善が必要になる場合があります。また、人間や AI が生成したパッチを、モデルを使って攻撃者の視点からレビューすることを推奨します。パッチの回避が可能である、他の攻撃経路や亜種を見落としている、といった問題を特定できます。
kernelCTF での実行では、研究用プロトタイプは Linux カーネルのゼロデイエクスプロイト 21 件に加えて、QEMU TCG の脆弱性も発見し、悪用に成功しました。分析エージェントは、システムコールのエントリーコードの分析を割り当てられ、権限遷移を実験するプログラムを書いている際に、予期しないカーネルクラッシュに遭遇しました。エージェントはクラッシュをトリアージし、QEMU のソースコードにアクセスせずに原因を QEMU TCG に絞り込み、その脆弱性をレポートに含めました。その後、ExploitDev エージェントは、この脆弱性に対するローカル権限昇格エクスプロイトの開発に成功しました。私たちはエクスプロイトを手作業で分析する中でこの QEMU の脆弱性を発見し、アップストリームの QEMU では修正済みであるものの、実験に使用したリリースビルドでは未修正であることを確認しました。
要点：サイバー能力を備えたフロンティアモデルは、テスト基盤の脆弱性も発見できます。攻撃者の視点に立った脆弱性研究を行う前に、基盤の各構成要素をテストすることを推奨します。私たちは自らの基盤を先回りしてテストし、Kata、Moby/Docker、gVisor などのプロジェクトで多数の脆弱性を開示・修正してきました。
私たちの目標は、モデルの能力向上を、インターネットの安全を守る人々にとっての持続的な優位性につなげることです。本研究は、フロンティアモデルの向上するサイバー能力を活用すれば、Linux カーネルのような複雑なソフトウェアでも効果的に脆弱性を発見できることを示しています。Linux などの重要なオープンソースプロジェクトのセキュリティを強化することで、それらを利用する多くのシステムやユーザーを保護できます。
私たちは、Daybreak の取り組みである Patch the Planet を通じて、本研究をさらに多くの重要なソフトウェアプロジェクトに広げ、メンテナーやセキュリティパートナーとともに信頼性の高い自動パッチ適用の仕組みを開発することを目指しています。攻撃者が利用できる機会を着実に減らし、脆弱性の発見と悪用にかかるコストを引き上げることで、最終的には期待される見返りが攻撃に見合わなくなる状態を目指しています。
各世代のモデルが、次世代のモデルでも侵害しにくいソフトウェアの構築に貢献するべきだと考えています。誰もが安心して、楽しみながらものづくりに取り組めるインターネットの実現に向けて、今後も取り組みを続けていきます。
