なぜ Codex Security に SAST レポートを含めないのか
静的アプリケーションセキュリティテスト（SAST）は何十年にもわたり、セキュリティチームがコードレビューをスケールするための最も有効な方法の一つでした。しかし、Codex Security を設計するとき、私たちは意図的な設計判断を下しました。SAST のレポートを取り込んでエージェントに振り分けさせる、という出発点は採りませんでした。代わりにリポジトリ自体（アーキテクチャ、信頼境界、意図された振る舞い）から出発し、発見したものを人間に通知する前に検証する設計にしました。
その理由は簡単です。最も難しい脆弱性は多くの場合データフローの問題だけではないからです。コードがセキュリティチェックを実行しているように見えるが、そのチェックが実際にシステムが依存する性質を保証していない、というケースが頻出します。言い換えれば、課題は単にデータがプログラムをどう移動するかを追跡することではなく、コード中の防御が本当に機能しているかを見極めることです。
問題：SAST はデータフローに最適化されている
SAST はしばしばクリーンなパイプラインとしてフレーム化されます：未信頼入力のソースを特定し、プログラムを通じてデータを追跡し、そのデータがサニタイズなしで機密性の高いシンクに到達するケースをフラグする。これは優雅なモデルで多くの実際のバグをカバーします。
しかし実運用では、特にインディレクション、動的ディスパッチ、コールバック、リフレクション、フレームワーク中心の制御フローを含む実コードベースでは、SAST はスケーラビリティを保つために近似を行わざるを得ません。これらの近似は SAST を批判するためのものではなく、コードを実行せずに推論しようとする現実です。
それ自体は、Codex Security が SAST レポートから始めない理由ではありません。より深刻な問題は、ソースからシンクへの追跡に成功したあとで何が起きるかです。
静的解析が苦手な領域：制約と意味論
静的解析が入力を複数の関数やレイヤーにわたって正しく追跡したとしても、脆弱性が実際に存在するかを決定する質問に答えなければなりません：防御は本当に機能したか？
よくあるパターンを考えてみましょう：レンダリング前に sanitize_html() のような関数を呼んで未信頼コンテンツをサニタイズしているコード。静的解析器はサニタイザが実行されたことを検出できますが、そのサニタイザが実際に「特定のレンダリングコンテキスト、テンプレートエンジン、エンコーディングの振る舞い、下流の変換」に対して十分かどうかを判定することは通常できません。ここが難しくなるポイントです。
問題は単にデータがシンクに到達するか否かではありません。コード中のチェックが、システムが想定しているように値を制約しているかどうか、が問題なのです。言い換えると「コードがサニタイザを呼んでいる」ことと「システムが安全である」ことの間には大きな違いがあります。
例：デコード前のバリデーション
実際のシステムでよく見られるパターンです。ウェブアプリが JSON ペイロードを受け取り、redirect_url を抽出し、allowlist の正規表現で検証し、URL デコードして結果をリダイレクトハンドラに渡す。
古典的なソース→シンクのレポートは次のように流れを記述できます：
untrusted input → regex check → URL decode → redirect
しかし真の問題はチェックが存在するかどうかではなく、変換の後にそのチェックが依然として値を制約しているかどうかです。もし正規表現が URL decode の前に実行されていると、リダイレクトハンドラが解釈するデコード後の URL を実際に制約できているでしょうか？
これに答えるには変換チェーン全体を推論する必要があります：正規表現が何を許可するか、デコードや正規化がどう振る舞うか、URL パーシングがエッジケースをどう扱うか、リダイレクトロジックがスキームやオーソリティをどう解決するか。多くの実用的な脆弱性はこうした順序のミス、部分的な正規化、パースの曖昧さ、バリデーションと解釈の不一致の形を取ります。
これは単なる理論上のパターンではありません。CVE-2024-29041 (opens in a new window) では、Express が不正な URL がエンコードされた後の解釈方法により一般的な allowlist 実装を回避できるオープンリダイレクト問題の影響を受けました。データフロー自体は単純でしたが、バグが存在するかを決めたのは「検証が変換チェーン後でも有効かどうか」でした。
私たちのアプローチ：振る舞いから始め、検証する
Codex Security は単純な目標を中心に構築されています：より強い証拠でトリアージを減らすこと。製品では、これはリポジトリ固有のコンテキスト（スレットモデルを含む）を使い、高シグナルの問題を隔離された環境で検証してから提示する、ということを意味します。
Codex Security が「バリデーション」や「サニタイズ」のように見える境界に遭遇したとき、それをチェックボックスとみなすことはしません。コードが何を保証しようとしているかを理解しようとし、その保証を反証しようとします。実務ではこれは次のような混合的手法になります：
- リポジトリ全体のコンテキストを踏まえて関連するコードパスを読み、意図と実装の不一致を人間の研究者と同じ方法で探す。コメントも参照しますが、モデルがコメントを盲信するわけではありません。実際にバグがあれば
//Halvar says: this is not a bug のようなコメントは混乱させません。
- 問題を最小のテスト可能なスライスに還元する（例：単一入力まわりの変換パイプライン）ことで、システム全体のノイズなしに推論できるようにする。この意味で Codex Security は小さなコードスライスを抽出し、それらに対するマイクロファザーを自動生成します。
- 各チェックを独立に扱うのではなく、変換を横断する制約の伝播について推論する。適切な場合は、充足可能性（satisfiability）として形式化することも含みます。つまり、モデルに z3-solver を備えた Python 環境へのアクセスを与え、必要に応じて人間が複雑な入力制約問題に対処するようにそれを使わせます。これは特に非標準アーキテクチャでの整数オーバーフロー等を調べる際に有用です。
- 可能な場合はサンドボックス化された検証環境で仮説を実行し、「これは問題になりうる」か「これは実際に問題であるか」を区別する。デバッグモードでコードをコンパイルした上でのエンドツーエンド PoC に勝る証拠はありません。
キーとなるシフトはこうです："チェックが存在する"で止めるのではなく、システムは "不変量が成立している（あるいはしていない）、こちらがその証拠だ" へと押し進めます。そしてモデルはその仕事に最適なツールを選びます。
なぜ Codex Security に SAST レポートを事前に与えないのか
合理的な反応として「両方やればいいのでは？」というものがあるでしょう。SAST レポートでスタートしてからエージェントに深く推論させる、というやり方です。既知の狭いバグクラスには事前計算された所見が有用な場合もありますが、文脈の中で脆弱性を発見・検証するよう設計されたエージェントにとって、SAST レポートを出発点にすることは三つの予測可能な失敗モードを引き起こします：
- 早すぎる絞り込みを助長する可能性
- 所見リストはツールが既に見た場所の地図です。これを出発点にすると、システムが同じ領域、同じ抽象の中で過剰に時間を使い、ツールの世界観に合わない問題クラスを見落とすバイアスが生まれます。
- 解きほぐしにくい暗黙の判断を導入すること
- 多くの SAST 所見はサニタイズやバリデーション、信頼境界についての仮定をエンコードしています。それらの仮定が間違っているか不完全である場合、それを推論ループに入れることでエージェントの動機が「調査」から「確認または却下」へとずれてしまい、望ましい挙動ではなくなります。
- 推論システムの評価を難しくすること
- パイプラインの出発点が SAST 出力だと、エージェントが独自に発見したものと他のツールから受け継いだものを分離するのが困難になります。その分離は、システムの能力を正確に測定し、時間とともに改善するために重要です。
したがって、私たちは Codex Security をセキュリティ調査が始まる地点から始めるように作りました：コードとシステムの意図から出発し、検証によって人間に割り込む前に信頼度を引き上げるのです。
SAST ツールの重要性は変わらない
SAST ツールは、それらが設計された目的に対しては非常に有用です：セキュアコーディング基準の強制、単純なソース→シンク問題の検出、既知パターンの大規模な検出など。ディフェンス・イン・デプスの強力な一部になりえます。
この投稿の主題はより狭く、振る舞いを推論し所見を検証するよう設計されたエージェントが、静的な所見リストにアンカーして作業を始めるべきでない理由についてです。合わせて指摘しておくべき制限は、純粋なソース→シンク思考の関連制約です：すべての脆弱性がデータフロー問題ではありません。多くの実際の失敗は状態や不変条件の問題です—ワークフローのバイパス、認可のギャップ、プログラムが常に真であると想定しているものが崩れるバグなど。これらのバグでは、汚染された値が単一の“危険なシンク”に到達するわけではありません。リスクはプログラムが常に真であると仮定していることにあります。
今後の展望
セキュリティツールのエコシステムは今後も改善を続けると期待しています：静的解析、ファジング、ランタイムガード、エージェント的ワークフローはすべて役割を持ち続けます。私たちが Codex Security に期待するのは、セキュリティチームに最もコストのかかる部分、つまり「これが怪しい」に対して「これは本当の問題だ、こう壊れる、そしてシステム意図に合った修正はこれだ」という形に落とし込むことです。
リポジトリのスキャン、所見の検証、修正案の提示方法について詳しく知りたい方は、ドキュメント（opens in a new window）を参照してください。