OpenAI Codex Security：為何系統避免使用 SAST 報告作為種子

OpenAI 設計了 Codex Security，以根據架構、信任邊界與預期行為來分析儲存庫，而非僅僅對現有的靜態應用程式安全測試（SAST）報告進行分流。此方式確保系統專注於安全防禦在實際運作中是否真的有效，而不是僅驗證程式碼中是否存在安全檢查。

SAST 在複雜漏洞偵測中的限制

靜態應用程式安全測試（SAST）主要針對資料流分析進行最佳化——追蹤從來源到敏感匯點的未受信任輸入。雖然對許多錯誤有效，但此模型在面對現代程式碼庫的語意實際情況時會遇到困難。

資料流 vs. 安全不變式

SAST 工具常會偵測到已呼叫清理函式（例如 sanitize_html()），但通常無法判斷該清理函式是否足以應對特定的渲染情境、模板引擎或後續轉換。關鍵的差距在於「程式碼呼叫了清理函式」這一事實，與「系統是安全的」這一結論之間的不同。

轉換鏈的挑戰

許多關鍵漏洞源於操作順序錯誤或解析歧義，導致檢查在轉換後被繞過。例如，若正則表達式驗證發生在 URL 解碼之前，解碼後的 URL 可能不再受原始檢查的限制。OpenAI 引用了 Express 中的 CVE-2024-29041 作為例子，該案例的資料流相當直接，但漏洞產生於驗證在轉換鏈之後失效。

Codex Security 的行為驗證方法

Codex Security 不將安全檢查視為勾選框，而是嘗試了解程式碼片段的預期保證，並透過多種技術方法試圖推翻該保證：

  • Contextual Analysis: 系統在完整的儲存庫上下文（包括註解）中閱讀程式碼路徑，以辨識意圖與實作之間的不符。
  • Micro-fuzzing: 系統抽取轉換管線中最小的可測試切片，並編寫微型 fuzz 測試器以單獨測試它。
  • Constraint Reasoning: 對於複雜的輸入限制，例如非標準架構上的整數溢位，系統使用配備 z3-solver 的 Python 環境，將問題形式化為可滿足性問題。
  • Sandboxed Execution: 系統在沙箱環境中執行假設，產生端對端概念驗證（PoC），並以除錯模式編譯程式碼，以區分理論風險與實際漏洞。

為何 Codex Security 不從 SAST 報告作為種子

OpenAI 明確避免將 SAST 報告作為代理的起始點，以免出現以下三種特定失敗模式：

  1. Premature Narrowing: 從發現清單開始會使代理偏向工具已識別的區域與抽象，可能錯過超出工具視野的問題。
  2. Implicit Judgments: SAST 發現常會編碼對信任邊界的假設。若這些假設不正確，代理可能從「調查」轉變為僅「確認或駁斥」工具的假設。
  3. Evaluation Difficulty: 以 SAST 輸出作為種子會使衡量代理獨立發現能力變得困難，而這是系統迭代改進所必需的。

SAST 在深度防禦中的角色

OpenAI 指出，SAST 工具仍然對於落實安全程式碼標準與大規模偵測已知模式至關重要。然而，它們不足以發現狀態與不變式問題——例如授權缺口或工作流程繞過——此類情況中沒有單一「受污染的值」抵達「危險匯點」，但程式對系統狀態的基本假設被違反。

Sources