Codex SecurityがSASTレポートを含まない理由

数十年にわたり、静的アプリケーションセキュリティテスト（SAST）は、セキュリティチームがコードレビューを拡張するための最も効果的な方法の一つでした。しかし、Codex Securityを構築する際、私たちは意図的な設計選択を行いました。静的解析レポートをインポートしてエージェントにトリアージを依頼することから始めるのではなく、リポジトリ自体（そのアーキテクチャ、信頼境界、意図された動作）から開始し、人間に時間を費やしてもらう前に発見した内容を検証するようにシステムを設計しました。

理由は単純です。最も困難な脆弱性は通常、データフローの問題ではありません。コードがセキュリティチェックを実行しているように見えるが、そのチェックがシステムが依存するプロパティを実際には保証していない場合に発生します。言い換えれば、課題はプログラム内でのデータの移動を追跡することだけではなく、コード内の防御が実際に機能するかどうかを判断することです。

問題：SASTはデータフロー用に最適化されている

SASTはしばしば明確なパイプラインとして組み立てられます：信頼できない入力のソースを特定し、プログラム内でデータを追跡し、そのデータがサニタイゼーションなしに機密シンクに到達するケースにフラグを立てます。これはエレガントなモデルであり、多くの実際のバグをカバーします。

実際には、SASTは大規模で実用的であり続けるために近似を行う必要があります。特に、間接参照、動的ディスパッチ、コールバック、リフレクション、フレームワーク重視の制御フローを持つ実際のコードベースにおいてです。これらの近似はSASTの欠点ではありません。実行せずにコードについて推論しようとする現実です。

それ自体は、Codex SecurityがSASTレポートから始めない理由ではありません。より深い問題は、ソースからシンクへの追跡に成功した後に何が起こるかです。

静的解析が苦手とする分野：制約とセマンティクス

静的解析が複数の関数とレイヤーにわたって入力を正しく追跡できたとしても、脆弱性が存在するかどうかを実際に決定する質問に答える必要があります：防御は本当に機能したのか？

一般的なパターンを考えてみましょう：コードが信頼できないコンテンツをレンダリングする前にsanitize_html()のようなものを呼び出します。静的アナライザーはサニタイザーが実行されたことを確認できます。通常判断できないのは、そのサニタイザーが特定のレンダリングコンテキスト、テンプレートエンジン、エンコーディング動作、および関連する下流変換に対して実際に十分かどうかです。

そこが厄介なところです。問題はデータがシンクに到達するかどうかだけではありません。コード内のチェックが、システムが想定する方法で実際に値を制約するかどうかです。

言い換えれば、「コードがサニタイザーを呼び出す」ことと「システムが安全である」ことには大きな違いがあります。

例：デコード前の検証

実際のシステムで常に現れるパターンがあります。Webアプリケーションがjsonペイロードを受信し、redirect_urlを抽出し、許可リスト正規表現に対して検証し、URLデコードし、結果をリダイレクトハンドラーに渡します。

従来のソースからシンクへのレポートはフローを記述できます：

信頼できない入力 → 正規表現チェック → URLデコード → リダイレクト

しかし、本当の質問はチェックが存在するかどうかではありません。そのチェックが後続の変換後も値を制約するかどうかです。正規表現がデコード前に実行される場合、リダイレクトハンドラーが解釈する方法でデコードされたURLを実際に制約するでしょうか？

それに答えるには、変換チェーン全体について推論する必要があります：正規表現が許可するもの、デコードと正規化がどのように動作するか、URL解析がエッジケースをどう扱うか、リダイレクトロジックがスキームと権限をどう解決するかです。

実際に重要な脆弱性の多くはこのように見えます：操作順序の間違い、部分的な正規化、解析の曖昧さ、検証と解釈の不一致です。データフローは見えています。弱点は制約が変換チェーンを通じてどのように伝播するか、または伝播に失敗するかにあります。

これは単なる理論的なパターンではありません。CVE-2024-29041では、Expressが不正なURLがリダイレクトターゲットのエンコードと解釈の方法により一般的な許可リスト実装をバイパスできるオープンリダイレクト問題の影響を受けました。データフローは単純でした。より困難な質問、そしてバグが存在するかどうかを決定した質問は、変換チェーン後も検証が有効かどうかでした。

私たちのアプローチ：動作から始めて、その後検証

Codex Securityは単純な目標を中心に構築されています：より強力な証拠で問題を表面化することによりトリアージを削減することです。製品では、これはリポジトリ固有のコンテキスト（脅威モデルを含む）を使用し、表面化する前に分離された環境で高シグナル問題を検証することを意味します。

Codex Securityが「検証」や「サニタイゼーション」のような境界に遭遇した場合、それをチェックボックスとして扱いません。コードが保証しようとしていることを理解し、その保証を反証しようとします。

実際には、これは以下の組み合わせのように見える傾向があります：

• セキュリティ研究者が行うように、完全なリポジトリコンテキストで関連するコードパスを読み、意図と実装の不一致を探します。これにはコメントも含まれますが、モデルは必ずしもコメントを信じないため、実際にバグがある場合、コードの上に//Halvar says: this is not a bugを追加しても混乱しません。

• システムの残りの部分が邪魔にならないように、問題を最小のテスト可能なスライス（例：単一入力周辺の変換パイプライン）に削減します。この意味で、Codex Securityは小さなコードスライスを抽出し、それらのマイクロファザーを書きます。

• 各チェックを独立して扱うのではなく、変換を通じた制約について推論します。適切な場合、これは充足可能性問題としての形式化を含むことができます。言い換えれば、モデルにz3-solverを持つPython環境へのアクセスを与え、特に複雑な入力制約問題に答える際に人間が行うように、必要に応じてそれを上手に使用します。これは非標準アーキテクチャでの整数オーバーフローや類似のバグを調べるのに特に有用です。

• 可能な場合、サンドボックス化された検証環境で仮説を実行し、「これは問題になる可能性がある」と「これは問題である」を区別します。デバッグモードでコンパイルされたコードでの完全なエンドツーエンドPoCより良い証明はありません。

これが重要な変化です：「チェックが存在する」で止まるのではなく、システムは「不変条件が成り立つ（または成り立たない）、そしてここに証拠がある」に向けて押し進めます。そしてモデルはその仕事に最適なツールを選択します。

なぜCodex SecurityをSASTレポートでシードしないのか

合理的な反応は：なぜ両方をしないのか？SASTレポートから始めて、エージェントを使ってより深く推論する。

事前計算された発見が有用なケースがあります。特に狭い、既知のバグクラスに対してです。しかし、コンテキスト内で脆弱性を発見し検証するように設計されたエージェントにとって、SASTレポートから始めることは3つの予測可能な失敗モードを作り出します。

第一に、早期の狭小化を促進する可能性があります。発見リストは、ツールがすでに調べた場所のマップです。それを出発点として扱うと、同じ地域、同じ抽象化を使用して不釣り合いな努力を費やし、ツールの世界観に適合しない問題クラスを見逃すようにシステムをバイアスする可能性があります。

第二に、解くのが困難な暗黙の判断を導入する可能性があります。多くのSAST発見は、サニタイゼーション、検証、または信頼境界についての仮定をエンコードします。これらの仮定が間違っている、または単に不完全である場合、それらを推論ループに供給することで、エージェントを「調査」から「確認または却下」にシフトさせる可能性があり、これは私たちがエージェントに行ってほしいことではありません。

第三に、推論システムの評価を困難にする可能性があります。パイプラインがSAST出力から始まる場合、エージェントが独自の分析を通じて発見したものと別のツールから継承したものを分離することが困難になります。その分離は、システムの能力を正確に測定したい場合に重要であり、これはシステムが時間とともに改善するために必要です。

そこで私たちは、セキュリティ研究が始まる場所から始まるようにCodex Securityを構築しました：コードとシステムの意図から、人間を中断する前に信頼度バーを上げるために検証を使用して。

SASTツールは依然として非常に重要

SASTツールは、設計された目的に対して優秀です：安全なコーディング標準の実施、単純なソースからシンクへの問題の捕捉、予測可能なトレードオフで大規模な既知パターンの検出。それらは多層防御の強力な部分になり得ます。

この投稿はより狭い範囲です：動作について推論し発見を検証するように設計されたエージェントが、静的発見リストに固定されてその作業を開始すべきでない理由についてです。

純粋なソースからシンクへの思考の関連する制限も指摘する価値があります：すべての脆弱性がデータフローの問題ではありません。多くの実際の失敗は状態と不変条件の問題です。ワークフローバイパス、認可ギャップ、「システムが間違った状態にある」バグです。これらのタイプのバグでは、汚染された値は単一の「危険なシンク」に到達しません。リスクは、プログラムが常に真であると仮定することにあります。

今後の展望

セキュリティツールエコシステムは改善し続けると予想しています：静的解析、ファジング、ランタイムガード、エージェントワークフローはすべて役割を持つでしょう。Codex Securityが得意になりたいのは、セキュリティチームにとって最もコストがかかる部分です：「これは疑わしく見える」を「これは本物で、ここに失敗の仕方があり、ここにシステム意図に合致する修正がある」に変えることです。

Codex Securityがリポジトリをスキャンし、発見を検証し、修正を提案する方法について詳しく知りたい場合は、私たちのドキュメントをご覧ください。