フロンティアAIモデルを利用した脆弱性ハンティング

概要

Oktaはここ数ヶ月間、OpenAIの「Daybreak Cyber​​ Partner Program」およびAnthropicの「Project Glasswing」の一環として、最先端のAIモデル（フロンティアAIモデル）を活用し、脆弱性の能動的な探索と自社製品のセキュリティ強化に取り組んできました。

これらのパートナーシップを通じて、私たちは「GPT-5.5 Cyber​​ Preview (TAC)」や「Mythos Preview」といった最先端モデルを利用し、多種多様な技術スタックや言語で記述された数百万行に及ぶコードのスキャンを実施しました。

私たちが目指した目標は、主に以下の2点です。

1. これらの最先端モデルを用いて脆弱性を発見し、お客様を確実に保護すること

2. その経験から得た知見を、今後のAI主導型のセキュリティ業務に活かすこと

本記事は、一般公開に先駆けてこれらの最先端技術を利用する機会を得た組織による一連の取り組みに、新たな知見を加えることを目的としています。

多くのOktaのお客様、特にテクノロジー分野のお客様が、現在こうした技術の導入計画を検討されていることでしょう。私たちの経験が皆様のご参考になればとの思いから、本記事では、スキャン用パイプラインの構築方法、スキャンの実施プロセス、そこから得られた学びについてご紹介します。

今回、最も重要な発見は、「人間の専門家とAIエージェントが互いに連携し、学び合うことで最良の成果が得られた」という点です。このプロセスを経て脆弱性を特定した後、私たちはパッチの開発とテストに向けた広範な作業を行いました。特定された脆弱性（CVE）に関する情報は、当社のTrust Siteでご確認いただけます。

システムの開発

私たちはまず、AIを用いた脆弱性スキャンに関するコミュニティで既に発表されている優れた研究成果を調査し、私たちの目標に合致する最良のアイデアを集約することから始めました。（参考にした主要な情報は付録に記載）

これらの研究成果に基づき、私たちはこの種のスキャンを実行できる新しいシステムをゼロから設計・実装することにしました。そして、進化に対応できる柔軟性を持ち、特定のベンダーに依存しないアーキテクチャを構築しました。このシステムは、脆弱性発見以外のタスクにも転用できることを目指しました。

以下は、私たちのアーキテクチャにおける主要な目標です。

• 安全性：多くのオーケストレーションプロジェクト（付録に記載）からヒントを得て、Pythonで軽量なカスタムオーケストレーターを構築しました。攻撃対象領域を縮小するために、強力な分離機能を備えるように設計しました。

• 柔軟性と拡張性：最小限の開発労力で、あらゆるコーディングハーネスやエージェントSDKを利用できるようシステムを設計しました。

• 透明性：リアルタイム追跡機能を構築し、人間のレビュー担当者がダッシュボードから状況を把握できるようにしました。また、各パイプラインステップとエージェントのセッション全体をキャプチャしました。

スキャンパイプラインの構築

重要な設計上の決定事項は、脆弱性を検出するために使用する手順とループのシーケンスであるスキャンパイプラインをどのように構築するかということです。

私たちは、コードをスキャンするために4つの異なるパイプラインを開発することにしました。これにより作業量は増えましたが、脆弱性発見の一部としてAIモデルを使用するアプローチを改善する機会として活用したいと考えました。

4つの異なるパイプラインを使用することで、どの手順がより効果的かを分析でき、製品タイプ、技術スタック、または検出する必要のある特定の種類の脆弱性に基づいて、新しい専門的なパイプラインを作成する方法についてのフィードバックを得ることができました。

もちろん、4つの異なるパイプラインで両方のモデル（GPT Cyber​​とMythos）を使用して数百のリポジトリをスキャンすることにはトレードオフがありました。重複した検出、潜在的に高い誤検出率、より負担の大きいトリアージプロセスが発生することを私たちは受け入れました。

また、AIエージェントに単に「脆弱性を探せ」と指示して自由に動き回らせるのではなく、私たちはグラフエンジニアリングの手法を採用しました。AIエージェントの挙動を人間が管理・把握できる状態に保ちながら、反復、ループ、分岐を含む複雑な手順やシーケンスを定義したのです。

そのために、各ステップは、コンテキストを段階的に読み込む方式を用い、CodexやClaude Codeの完全に独立したセッションとして実行されました。つまり、あるステップから次のステップへどのファイルを渡すかを慎重に制御したわけです（ただし、前のステップの検出結果から追加情報を読み込むべきかどうかを、AIエージェント側が自律的に判断して取得することは可能としています）。このようにしたのは、コンテキストウィンドウ内の情報量が過多になり、AIエージェントの判断精度が低下してしまう「コンテキストの肥大化（context bloat）」を防ぐためです。

どのようにスキャンしたのか

AIエージェントを稼働させる前に、具体的に何をスキャン対象とするかを決定する必要がありました。最短時間で最大の効果を上げるため、私たちはまず、保護において最も重要なコード、すなわちお客様自身がインストールするソフトウェアのスキャンから着手しました。

そして、コードベース全体にAIエージェントを配備し、まずは「広範囲」を対象にスキャンを行いました。このアプローチでは（誤検知を含め）大量の結果が生成されることは承知していましたが、たとえ誤検知であっても将来の調査に向けたヒントになり得ると考え、そのトレードオフを受け入れました。

アンド、単に一度コードをスキャンするだけでなく、何が最も効果的かを見極めるために試行錯誤を重ね、人間とAIエージェントの双方に様々な方法でスキャンを実施しました。

具体的には、主に2つのアプローチを並行して進めました。

1. AIエージェントがコードリポジトリを自律的にスキャンできるようにする

2. 人間の専門家とAIエージェントを組み合わせ、人間の専門家が自身の着想や特定の領域について調査するようAIエージェントに指示する（その目的は、人間の専門家の関与によってAIエージェントがより迅速に結果に到達できるかどうかを検証することでした）

AIエージェントの実行状態を記録・再現する新しいアプローチ

私たちは、実行されたすべてのステップとセッションを記録しました。これにより、人間の専門家は任意の時点に遡り、AIエージェントの動作を確認できるようになりました。パイプラインが複雑であっても、人間の専門家がプロセスの途中でモデルの興味深い挙動に気づけば、その時点に立ち返って詳細を調査することが可能です。

また、この手法によって、パイプライン内で何が起きたのかを完全に検証することもできました。自律型AIエージェントは「ブラックボックス（中身が不透明なシステム）」であるという一般的な見解に対し、私たちはこのアプローチを通じて、対話的な形を含めた検証・調査を可能にすることを目指しました。

エクスプロイト開発、フォレンジック、マルウェア解析の経験がある方なら、この手法に馴染みがあるかもしれません。解析中の特定の時点に立ち戻れることは有益であり、私たちはまさにその手法を応用しました。当社のエンジニアの一人が、エクスプロイト開発における「タイムトラベル・デバッグ」という手法に着想を得たのです。これは、プログラムの実行を記録し、その動作履歴を前後に行き来できるようにするものです。

マルウェアの実行前後におけるシステムの状態を確認するために仮想マシンのスナップショットを取ったことがある方なら、それと似た手法だとお分かりいただけるでしょう。この手法自体は新しいものではありませんが、その適用方法において私たちは独自のアプローチをとりました。

これを実現するため、私たちはセッションを再構築（再現）する上で本当に必要な『最小限の情報』だけを特定しました。標準のCodexやClaude Codeを実行すると、不要な追加情報が大量に収集されてしまうためです。

そこで、オーケストレーションシステムにロジックを組み込み、不可欠な情報だけを保持するようにしました。これにより、パイプラインの各ステップが完了しセッションが記録されると、人間の専門家はCodexやClaude Codeを起動し、その特定のステップに対応する対話型セッションとしてデータを読み込み、次に何をすべきかモデルを「誘導」できるようになります。この作業を支援するためにセッションビューアツールを使用し、人間の専門家がHTMLビューア上で実行履歴（トレース）を確認して、モデルの動作を検証できるようにしました。パイプラインは独立したステップで構成されているため、このアプローチにより、プロセスの各ステップを変更して、それが結果にどのような変化をもたらすかを検証することが可能になりました。

このアプローチによって、私たちは大きな価値を引き出すことができました。モデルによるスキャン中に人間の専門家が興味深い点に気づけば、その箇所を読み込むことができたのです。

モデルを適切に誘導できる人間の専門家と組み合わせることで、素晴らしい成果が得られるということが分かりました。

どのようにトリアージしたか

4つのパイプラインと、人間とAIエージェントが連携する手法を用いてスキャンを行った結果、重複を含め、モデルから多数の検出結果が得られました。私たちは、それらの調査対象をトリアージ（優先順位付け）し、実際に悪用可能な脆弱性であるかどうかを検証するという課題に直面しました。そして、このトリアージを迅速に行う必要がありました。プロジェクト全体を通じて実践してきた通り、ここでも人間の専門家とAIエージェントを組み合わせることで、可能な限り効率的に作業を完了させました。

スキャン結果のうち、重大度が最も高いものやCVE（共通脆弱性識別子）が割り当てられる可能性のあるものについては、それらが真陽性（実際に存在する脆弱性）であった場合の影響が極めて大きいため、優先的にトリアージを行いました。

モデルが脆弱性の重要度を過大評価する傾向が見られたため、モデルの想定と実際の運用環境との間に乖離がある場合には、その重要度評価を引き下げました。例えば、あるモデルはコードがインターネットに直接公開されると想定していましたが、実際にはそのような構成にはなっていなかった、といったケースです。

このような誤検知（フォールス・ポジティブ）を減らすため、AIエージェントが出力した結果や判定が正確であるかどうかを人間が調査、検証し、将来的に同様の誤検知を減らせるようパイプラインの改善を行いました。

私たちが学んだこと

人間とAIエージェントが協調し、最良の成果を実現する

本プロジェクト全体を通じ、最も優れた成果が得られたのは、人間の専門家とAIエージェントを組み合わせた場合でした。スキャン作業は、私たちとAIエージェントとの間の相互メンタリングのプロセスでもありました。まず、追加の文脈情報なしでAIエージェントにコードをスキャンさせることで、彼らから新しいアプローチや手法を学びました。その後、そのコードベースに関する私たちの知見（組織的な知識）を活かし、AIエージェントがどこに注目すべきかを教え込みました。例えば、過去の脆弱性に関する情報を「ヒント」として追加の文脈情報に含めるといった試みを行いました。

私たちは、そのコードベースに精通した人間の専門家をAIエージェントと連携させ、特定の攻撃対象領域（アタックサーフェス）、製品機能、複雑性の高い箇所を重点的に探索するよう誘導しました。その結果、人間の専門家がAIエージェントを導くことで、より大きな成果が得られることが分かりました。自律的なAIエージェントだけでは見落としていたであろう脆弱性や問題点を発見できたのです。

例えば、認証アルゴリズムや暗号プリミティブといった、リスクの高い機能を実装しているコード領域を、人間の専門家は把握している場合があります。AIエージェントが自力でコードベースをあてもなく探索するのではなく、潜在的な脆弱性が存在する箇所へ可能な限り近づくよう誘導することで、より優れたパフォーマンスを発揮させることができました。

AIエージェントは時に、脆弱性のありかへと我々を導く猟犬のような役割を果たしました。AIエージェントが報告した内容そのものは必ずしも実際の脆弱性ではないことも多々ありましたが、人間の専門家はそれを調査の手がかりとして活用し、AIエージェントに追加の調査を促したり、さらなる文脈を関連付けたりすることで、最終的に新たな脆弱性を発見するに至りました。

本プロジェクトは、プロダクトセキュリティチームのエンジニアたちの尽力なしには実現し得なかったでしょう。これらのモデルによって発見された脆弱性を報告する前には、数週間にわたり、それらの脆弱性のトリアージ（優先順位付け）、再現、そして報告を行うための多大な労力が費やされました。

他の研究者との協力

前述の通り、私たちは他のAI研究者が公開・非公開を問わず作成・共有してきた成果から、多くのことを学びました。それらが皆様のAI研究の一助となればとの思いから、インスピレーションの源となったいくつかの参考資料へのリンクを文末に掲載しています。

こうしたプログラムへの参加を通じて、AnthropicやOpenAI、さらには同様のモデルを用いて実験を行っている他の組織と連携するというメリットが得られました。

Anthropicは、各参加者がアプローチを共有するための週次ミーティングを主催し、参加企業間（Visa、Capital One、Cloudflareなど、ツールをオープンソース化した企業もありました）の連携を促進しました。こうした連携のおかげで、他のチームの取り組みと比較・検討を行うことができました。

ある事例では、別のチームが我々と同様のパイプラインアプローチを独自に採用しており、それによって我々のユースケースに対する方針が正しいものであると確信を深めることができました。

また、OpenAIは専任の担当者を配置し、参加企業間のセッションを通じて継続的に支援してくれました。これは、開発の障害となる課題を解決するためのブレインストーミングにおいて大いに役立ちました。例えば、我々の最大規模のリポジトリは非常に容量が大きく、そのスキャン方法について検討していた際、OpenAIから大規模リポジトリをモデルがスキャン可能な小さなサブコンポーネントに分割する手法が提案されました。これにより、我々が検討していたアプローチが実現可能な方向性であることを確認できました。

試行と反復による継続的な改善

私たちは当初から、このプロジェクトを学びの機会とすることを意図的に目指していました。単一のパイプラインを使用する方が簡単だったでしょうが、あえて4つのパイプラインを採用しました。セッションを記録したり、人間の専門家とAIエージェントとの連携にこだわったりしなければ、より簡単かつ低コストで済んだはずです。試行が一度でうまくいかなかった場合は、反復（イテレーション）を重ねて再挑戦しました。こうした反復的なアプローチは、単に学びを得るだけでなく、一度スキャンして「成功」と結論付けるのではなく、より良い結果を導き出すことにもつながりました。

この取り組みはここで終わりではありません。私たちは豊富なデータセットを蓄積しており、次のステップや改善策について数多くのアイデアを持っています。脅威に悪用される前にセキュリティ上のギャップを見つけ出し、それを塞ぐという極めて重要な任務を遂行する中で、今後も反復と学習を続けていきます。

付録

パイプラインダイアグラム

これらの図は、私たちが構築した「madara-scorecard」と「sink-thorough」という2つのパイプラインを示しています。これらは、グラフエンジニアリングのアプローチにおいて採用した複雑さの異なる構成や、反復・ループ・分岐をどのように活用したかを表しています。