OpenAI Codex Security: システムがSASTレポートのシーディングを回避する理由

OpenAIは、Codex Securityを、既存のStatic Application Security Testing（SAST）レポートをトリアージするのではなく、アーキテクチャ、信頼境界、意図された動作に基づいてリポジトリを分析するように設計しました。このアプローチにより、システムはコードにセキュリティチェックが存在することを単に確認するのではなく、実際にセキュリティ防御が機能しているかに焦点を当てます。

複雑な脆弱性検出におけるSASTの限界

Static Application Security Testing（SAST）は主にデータフロー解析—信頼できない入力をソースから機密シンクへ追跡すること—に最適化されています。多くのバグに対して有効ですが、このモデルは現代のコードベースのセマンティックな実態に苦労します。

データフロー vs. セキュリティ不変条件

SASTツールはしばしばサニタイザ（例：sanitize_html()）が呼び出されたことを特定しますが、通常はそのサニタイザが特定のレンダリングコンテキスト、テンプレートエンジン、または下流の変換に対して十分かどうかを判断できません。重要なギャップは「コードがサニタイザを呼び出す」という事実と「システムが安全である」という結論との違いです。

変換チェーンの課題

多くの重大な脆弱性は、操作順序のミスや変換後にチェックが回避されるパースの曖昧さから生じます。例えば、正規表現による検証がURLデコードの前に行われると、デコードされたURLは元のチェックによってもはや制約されなくなります。OpenAIは、ExpressにおけるCVE-2024-29041 を例に挙げ、データフローは単純だったものの、変換チェーン後に検証が保持されなかったために脆弱性が存在したと指摘しています。

Codex Securityの行動検証アプローチ

セキュリティチェックをチェックボックスとして扱うのではなく、Codex Securityはコードの意図された保証を理解し、その保証をいくつかの技術的手法で反証しようとします。

コンテキスト分析: システムはコメントを含むリポジトリ全体のコンテキストでコードパスを読み取り、意図と実装の不一致を特定します。
マイクロファジング: システムは変換パイプラインの最小テスト可能スライスを抽出し、単体でテストするマイクロファジングツールを書きます。
制約推論: 非標準アーキテクチャ上の整数オーバーフローなど、複雑な入力制約に対して、システムはz3-solverを備えたPython環境を使用し、問題を充足可能性の質問として形式化します。
サンドボックス実行: システムは仮説をサンドボックス環境で実行し、デバッグモードでコンパイルされたコードでエンドツーエンドの概念実証（PoC）を生成し、理論的リスクと実際の脆弱性を区別します。

Codex SecurityがSASTレポートからシードしない理由

OpenAIは、エージェントの出発点としてSASTレポートの使用を明示的に回避し、以下の3つの特定の失敗モードを防ぎます。

早期の狭窄: 発見リストから開始すると、エージェントはツールが既に特定した領域や抽象に偏り、ツールの視野外の問題を見逃す可能性があります。
暗黙の判断: SASTの発見はしばしば信頼境界に関する前提をエンコードしています。これらの前提が誤っている場合、エージェントは「調査」から単にツールの前提を「確認または却下」するへとシフトするかもしれません。
評価の難しさ: SAST出力でシードすると、エージェントの独立した発見能力を測定することが難しくなり、システムの反復的改善に必要です。

防御の深層におけるSASTの役割

OpenAIは、SASTツールが安全なコーディング標準の適用や既知パターンの大規模検出に依然として重要であると指摘しています。しかし、単一の「汚染された値」が「危険なシンク」に到達しないが、システム状態に関するプログラムの根本的な前提が破られるような状態や不変条件の問題（例：認可のギャップやワークフローのバイパス）を発見するには不十分です。