AIが、より速く穴を見つけるようになった

11月4日、OpenAIは、Linuxカーネルに対してAIエージェントを走らせた取り組みについて説明しました。Linuxカーネルは、Androidのスマートフォン、クラウドのインフラ、スーパーコンピューターを支えるソフトウェアです。10月中旬からの約10日間で、エージェントは948件の異なる欠陥について、実際に動作するエクスプロイトを作成しました。いずれも、通常のユーザーアカウントからマシンの完全な制御を奪えるものです。そしてそのすべてについて、パッチの候補も書きました。その1週間前、GoogleはGemini 4 Carbonを発表し、審査を経たサイバー防御の担当者にまず提供しました。欠陥が存在してから誰かがそれを見つけるまでの時間は縮まっており、ラボは防御側に先にたどり着いてほしいと考えています。

OpenAIが実行したこと

パイプラインは5つの段階からなり、OpenAIが11月5日にGPT-6 Cyberとして公開したサイバー向けモデルの上で動きました。偵察役のエージェントが、監査する価値のあるカーネルの部分を5'034か所選び出しました。コードの約7パーセントにあたります。分析役のエージェントは、それを12時間で2'308件の発見候補にまとめました。トリアージ役のエージェントは、隔離されたマシンでそれぞれの再現を試み、約4分の3にあたる1'724件で成功しました。OpenAIによると、誤った分析に基づく発見は3.1パーセントにすぎませんでした。その後の段階では、どの欠陥が悪用可能かを試してパッチを書き、何かを報告する前に人が結果をレビューしました。

この取り組みにかかったAPIクレジットは1'213'430ドル、エクスプロイト1件あたり約1'279ドルです。対象は、通常の保護機能を有効にした標準のデスクトップ版Linuxでした。7月に以前のモデルGPT-5.6 Solで行った取り組みでは、こうした欠陥が166件見つかっていました。そのあいだの3か月でカーネルは強化されていたにもかかわらず、新しいモデルは5倍を超える数を見つけました。

ラボが語る限界

OpenAIは、どこで失敗したかについて率直です。初期の実行では、パイプラインは200件のエクスプロイトの成功を報告しましたが、人によるレビューで、そのうち20件は割り当てられたものとは別の未知の欠陥を通じて完全な制御に達していたことがわかりました。「これは、エージェントによる悪用が成功した場合でさえ、適切な検証が必要であることを示している」とOpenAIは書き、各エクスプロイトが割り当てられた欠陥を使ったかどうかを独立して確認する仕組みを加えました。その教訓は、あらゆる自動化された仕事に当てはまります。「結果そのものを検証するだけでなく、結果に至る経路も検証すること」。

パッチにも手直しが必要でした。最初のパッチは機能したものの、ときに不要なコードを加えたり、その部分の慣習を無視したり、同じ欠陥の別のパターンを見落としたりしました。指示を増やし、繰り返し改善することで、良くなっていきました。OpenAIは、コストの数字を「どちらかといえば上限」と呼んでいます。これらの数字はすべてOpenAI自身のものです。11月5日の時点で、私たちはそれらについての独立した監査も、今回の一連の発見についてのカーネルのメンテナーによる公式な声明も見つけられていません。

まず防御側へ

10月28日のGoogleの発表も同じパターンをたどっています。GoogleはGemini 4 Carbonを「最先端のサイバーセキュリティと長い時間軸のタスクの能力を備えた、当社で最も強力なモデル」と呼び、欠陥の発見を測るSEC-bench Proで88.2パーセント、ExploitGymで54.8パーセント、パッチの作成を測るCWE-benchで71.0パーセントというスコアを報告しています。いずれもGoogle自身の数字で、ガードレールなしで測定されたものです。アクセスはサイバー防御の担当者の一部から始まり、Fairwind Programを通じて段階的に広がります。SecurityWeekによると、このプログラムには政府や重要インフラの事業者を含む650を超える参加者がいます。開発者、企業、消費者向けの公開は「できるだけ早く」と約束されていますが、日付は示されていません。

このパターンを作ったのは4月のAnthropicのMythosで、OpenAIもそれに倣っています。GPT-6 Cyberはまず、許可を得たセキュリティテストのためのOpenAIのプログラムDaybreak Redの顧客のうち、承認を受けた一部に提供されます。OpenAIは自社のPreparedness Frameworkのもとで、このモデルをサイバーセキュリティについてCriticalと評価しています。その理由を、発表はこう述べています。「フロンティアモデルを使ってソフトウェアを守れる期間が限られていることは明らかだ」。

メンテナーの側

あらゆる発見は、それを修正しなければならない誰かのもとに届きます。3月、カーネルの古参メンテナーGreg Kroah-Hartman氏はThe Registerに対し、AIで作られた報告がその約1か月前に、がらくたから本物へと変わったと語りました。「いまでは本物の報告が来ている」。5月にはLinus Torvalds氏が、多くの人が同じツールで同じバグを見つけるため、「AIによる報告が洪水のように続き、セキュリティのメーリングリストは基本的にほぼ手に負えなくなった」と書きました。報告者への同氏の助言はこうです。「AIツールを使ってバグを見つけたなら、ほかの誰かもそれを見つけている可能性が高い」。7月には、カーネルチームがある日曜日と月曜日の2日間で432件のCVEを公開しました。

OpenAIのスキャンが進むあいだにも、メンテナーやほかのコントリビューターは、同じ欠陥の多くをすでに修正していました。10日後の時点で、61件はアップストリームで修正済み、43件はパッチが順番待ちで、299件は公の場で議論されていました。OpenAIは、カーネルコミュニティのガイダンスに従い、これまでに304件の重大な発見をパッチの候補とともに開示したとしています。私たちの見方では、いま希少な資源は、修正をレビューし、テストし、リリースする人々の注意力です。

企業にできること

ほとんどの企業は、こうした修正を受け取るソフトウェアを動かしているだけで、修正はしばしば大きな塊で届きます。OpenAIは自ら結論を引き出しています。当面、「利用可能な最新のパッチが当たっていない」システム上の低い権限のアカウントは、「十分な資源を持つ攻撃者にとっては、実質的にroot権限と同等とみなすべき」だというのです。私たちの見方では、そこから4つのことが導かれます。

より速くパッチを当て、自社で何を動かしているかを把握すること。Akamaiの最高情報セキュリティアーキテクトJan Schaumann氏は7月、カーネルの個々の変更に優先順位をつけることはもはや現実的ではないと書き、The Registerに対し、大きな組織にとっては難しいものの、「自動化され、定期的で、頻繁な更新」が唯一の妥当なやり方に思えると語りました。そのためには、すべてのサーバー、デバイス、サービスと、それぞれを誰が更新するのかをまとめた最新のリストが必要です。

すばやくパッチを当てるサプライヤーを選び、重大な修正が届くまでにどれくらいかかるかを尋ねましょう。ソフトウェアベンダーには、こうしたモデルをどう使っているかを尋ねます。自社のコードをスキャンしているか、モデルの報告をどう検証しているか、DaybreakやFairwindのようなプログラムに参加しているか。

機微なデータは自社が管理するシステムに置き、アクセスを役割ごとに制限しましょう。そうすれば、他社のサービスに欠陥があっても、さらされるものは少なくなります。管理しているからといってパッチを当てる義務がなくなるわけではなく、その義務が自社のものになるのです。OpenAIはまた、何かが悪用されたときの被害を抑えるために、サンドボックスと隔離を推奨しています。

私たちの立ち位置

私たちはセキュリティスキャナーを作ってはいません。私たちの役割は、このリストの最後の点です。提供中のTwinは、会社のアシスタントにひとつの頭脳を与えます。アクセスは役割ごとに設定され、すべての書き込みはユーザーごとのサインインで行われ、すべてのステップが記録されます。ホスティング先はスイス、EU、米国、あるいはその会社自身のハードウェアです。パートナーのEigna Labsが構築し、先行アクセスの段階にあるEignaは、企業自身のクラウドやサーバーで動くプライベートモデルで、閉じたネットワークの中でオフラインで動くように設計されています。企業が動かすほかのあらゆるものと同じく、どちらも常に最新の状態に保たなければなりません。