［開発者向け］OpenAI「Codex Security」がSASTレポートを起点にしない理由

2026-03-17

はじめに

　OpenAIが2026年3月16日に公表したブログ記事では、AIセキュリティ解析ツール「Codex Security」がSAST（静的アプリケーションセキュリティテスト）レポートを起点にしない設計判断と、その背景にある技術的思想について解説しています。本稿ではその内容を紹介します。

参考記事

タイトル: Why Codex Security Doesn’t Include a SAST Report
著者: OpenAI
発行元: OpenAI Blog
発行日: 2026年3月16日
URL: https://openai.com/index/why-codex-security-doesnt-include-sast/

要点

Codex SecurityはSASTレポートではなく、リポジトリのアーキテクチャやトラストバウンダリー、意図された動作を起点に解析を行うツールである
SASTはデータフロー（ソースからシンクへの追跡）に優れているが、防御が実際に機能するかどうかの検証は苦手とされる
Codex Securityはマイクロファジング、z3ソルバー、サンドボックス実行を組み合わせ、脆弱性の存在を実証的に確認するアプローチをとっている
SASTレポートを起点にすると「探索範囲の早期固定化」「暗黙の前提の引き継ぎ」「システム評価の困難化」という3つの問題が生じる
すべての脆弱性がデータフローの問題ではなく、状態や不変条件に関わるバグへの対応も重要な課題である

詳細解説

SASTの仕組みとその限界

　SAST（Static Application Security Testing）は、コードを実行せずに脆弱性を静的に検出する手法です。基本的な考え方は「信頼できない入力の発生源（ソース）を特定し、データの流れを追跡して、サニタイズなしに危険な処理（シンク）に到達するケースを検出する」というものです。多くの実際のバグをカバーできる実績のあるアプローチであり、大規模なコードベースにおいても予測可能なトレードオフのもとで機能します。

　ただし、OpenAIによれば、SASTの課題はデータが「どこを通過したか」ではなく、「防御が本当に機能したか」にあります。例えばコードがsanitize_html()を呼び出している場合、静的解析ツールはサニタイザーの実行を確認できます。しかし、そのサニタイザーが特定のレンダリングコンテキスト、テンプレートエンジン、エンコーディング処理、後続の変換処理に対して実際に十分かどうかは判断が難しい状況です。「コードがサニタイザーを呼び出している」と「システムが安全である」の間には大きな差があると言えます。

変換の順序が生む脆弱性：CVE-2024-29041の例

　OpenAIが具体例として挙げているのは、バリデーションとデコードの順序に関わる問題です。WebアプリケーションがリダイレクトURLをアローリストの正規表現で検証した後、URLデコードして処理する場合、データフローとしては「信頼できない入力 → 正規表現チェック → URLデコード → リダイレクト」と追跡できます。

　しかし重要なのは、デコード前に実施された正規表現チェックが、デコード後の値に対しても有効な制約として機能しているかという点です。実際にCVE-2024-29041では、Expressがこの問題の影響を受けており、エンコードされたURLがアローリスト実装を回避できる状態でした。データフロー自体は明確でしたが、変換チェーンを通じて制約が維持されるかどうかが本質的な問題でした。こうした「操作の順序ミス」「部分的な正規化」「バリデーションと解釈の不一致」が実際の脆弱性につながるケースは少なくないと考えられます。

Codex Securityのアプローチ：「チェックの存在」から「不変条件の検証」へ

　Codex Securityは「検査リストのチェック」ではなく「不変条件が維持されるかどうかの検証」を目指す設計となっています。OpenAIによれば、具体的には以下の手法を組み合わせています。

　まず、リポジトリ全体のコンテキストを使って関連するコードパスを読み込み、意図と実装の不一致を探します。コードのコメントに「これはバグではない」と記述されていても、実際にバグがあれば検出される仕組みになっています。次に、問題箇所を最小のテスト可能なスライスに絞り込み、マイクロファジングを行います。制約が変換を通じてどう伝播するかの推論には、Pythonのz3ソルバーが利用可能で、整数オーバーフローなど複雑な入力制約問題に特に有効とされています。最終的には、サンドボックス環境でエンドツーエンドの概念実証（PoC）をデバッグモードでコンパイルしたコードを使って実行し、「問題の可能性」を「問題の実証」に変えます。

　この設計の核心は「チェックが存在する」という状態から「不変条件が維持される（あるいは維持されない）、そしてここにその証拠がある」という状態への転換にあります。モデルはその問いに答えるために最適なツールを選択する仕組みになっています。

SASTレポートを起点にしない3つの理由

　OpenAIは、SASTと組み合わせればよいのではないかという疑問に対して3つの問題を挙げています。

　第一に「探索範囲の早期固定化」です。 SASTの検出結果リストを起点にすると、すでにツールが調査した領域に注力しがちになります。同じ抽象化の枠組みを使うことで、ツールの世界観に合わない種類の問題を見落とす可能性があります。

　第二に「暗黙の前提の引き継ぎ」です。 多くのSASTの検出結果にはサニタイズやトラストバウンダリーに関する前提が含まれており、それが誤りや不完全だった場合、エージェントが「調査」ではなく「確認・却下」モードに移行してしまう懸念があります。

　第三に「システム評価の困難化」です。 SASTの出力から始めると、エージェント自身の分析による発見と他のツールから引き継いだ内容を区別することが難しくなります。システムの能力を正確に測定・改善するためには、この区別が重要とのことです。

SASTツールの役割は変わらない

　OpenAIはSASTツールが依然として重要であることも明示しています。セキュアコーディング標準の適用、単純なソース・シンク問題の検出、既知パターンの大規模スキャンなどにおいて、SASTは防御の多層化（defense-in-depth）として強力な役割を果たします。この記事はあくまでも「振る舞いを推論し検証結果を確認するエージェント」がSASTの結果リストを起点にすべきではない、という特定の設計判断に関する説明であると明示されています。

　また、すべての脆弱性がデータフローの問題ではないという点も強調されています。ワークフローバイパス、認可の欠落、「システムが誤った状態にある」といったバグは、汚染されたデータが単一の危険なシンクに到達するわけではなく、プログラムが何を常に真であると仮定しているかという「状態と不変条件」の問題です。こうした種類のバグへの対応も、Codex Securityが視野に入れている領域と考えられます。