為何 Codex Security 不包含 SAST 靜態分析報告

2026 年 3 月 16 日

為什麼 Codex Security 不包含 SAST 報告

數十年來，靜態應用程式安全測試（SAST）一直是安全團隊擴展程式碼審查效率最有效的方法之一。

但在我們開發 Codex Security 時，我們做了一個深思熟慮的設計選擇：我們並非從匯入靜態分析報告並要求代理程式（agent）進行分類（triage）開始。我們將系統設計為從儲存庫（repository）本身開始——包括其架構、信任邊界和預期行為——並在要求人工投入時間處理之前，先驗證其發現的結果。

原因很簡單：最困難的漏洞通常不是資料流（dataflow）問題。它們發生在程式碼看似執行了安全檢查，但該檢查實際上並未保證系統所依賴的屬性。換句話說，挑戰不僅在於追蹤資料如何在程式中流動，而在於判斷程式碼中的防禦措施是否真的有效。

問題所在：SAST 針對資料流進行了優化

SAST 通常被框架化為一個乾淨的管道：識別不可信輸入的來源（source），追蹤資料在程式中的流動，並標記資料在未經淨化（sanitization）的情況下到達敏感接收點（sink）的案例。這是一個優雅的模型，且涵蓋了許多現實中的漏洞。

在實務中，為了在規模化時保持運算可行性，SAST 必須進行近似處理——特別是在具有間接引用、動態派發、回呼（callbacks）、反射（reflection）和重度依賴框架控制流的現實程式碼庫中。這些近似處理並非對 SAST 的指責，而是試圖在不執行程式碼的情況下對其進行推理的現實限制。

但這本身並不是 Codex Security 不從 SAST 報告開始的原因。

更深層的問題在於，當你成功追蹤到從來源到接收點的路徑後，會發生什麼事。

靜態分析的困境：約束與語義

即使靜態分析正確地追蹤了跨多個函數和層級的輸入，它仍然必須回答那個真正決定漏洞是否存在的問題：

防禦真的奏效了嗎？

以一個常見模式為例：程式碼在渲染不可信內容之前呼叫了類似 sanitize_html() 的函數。靜態分析器可以看到淨化器（sanitizer）已執行。但它通常無法判斷該淨化器對於特定的渲染上下文、模板引擎、編碼行為以及涉及的下游轉換是否真的足夠。

這就是棘手之處。問題不僅在於資料是否到達接收點，而是在於程式碼中的檢查是否真的按照系統假設的方式約束了數值。

換句話說：「程式碼呼叫了淨化器」與「系統是安全的」之間存在巨大差異。

範例：解碼前的驗證

這是一個在現實系統中經常出現的模式。

一個 Web 應用程式接收 JSON 負載，提取 redirect_url，根據允許列表（allowlist）正則表達式進行驗證，進行 URL 解碼，然後將結果傳遞給重定向處理程序。

經典的來源到接收點報告可以描述此流程：

不可信輸入 → 正則檢查 → URL 解碼 → 重定向

但真正的問題不在於檢查是否存在，而在於該檢查在隨後的轉換之後，是否仍然約束著該數值。

如果正則表達式在解碼之前運行，它是否真的能按照重定向處理程序解釋的方式，約束解碼後的 URL？

要回答這個問題，意味著需要對整個轉換鏈進行推理：正則表達式允許什麼、解碼和正規化（normalization）的行為、URL 解析如何處理邊緣案例，以及重定向邏輯如何解析 scheme 和 authority。

現實中許多重要的漏洞看起來都像這樣：操作順序錯誤、部分正規化、解析歧義，以及驗證與解釋之間的不匹配。資料流是可見的，但弱點在於約束如何在轉換鏈中傳遞——或未能傳遞。

這不僅僅是理論上的模式。在 CVE-2024-29041 中，Express 受到開放重定向（open redirect）問題的影響，由於重定向目標的編碼和解釋方式，畸形的 URL 可以繞過常見的允許列表實現。資料流很直接，但更難的問題（也是決定漏洞是否存在的問題）是：在轉換鏈之後，驗證是否仍然有效。

我們的做法：從行為開始，然後驗證

Codex Security 的建立圍繞著一個簡單的目標：透過呈現具有更強證據的問題來減少分類工作。在產品中，這意味著使用特定於儲存庫的上下文（包括威脅模型），並在呈現問題之前，先在隔離環境中驗證高訊號問題。

當 Codex Security 遇到看起來像「驗證」或「淨化」的邊界時，它不會將其視為一個已勾選的方塊。它會試圖理解程式碼試圖保證什麼——然後試圖證偽（falsify）該保證。

在實務中，這通常看起來像是以下各項的結合：

這是關鍵的轉變：系統不再止步於「檢查已存在」，而是推向「不變量（invariant）是否成立（或不成立），以及證據在此」。而模型會選擇最適合該任務的工具。

為什麼我們不使用 SAST 報告來引導 Codex Security

一個合理的反應是：為什麼不兩者兼顧？從 SAST 報告開始，然後使用代理程式進行更深層次的推理。

在某些情況下，預先計算的發現是有幫助的——特別是對於狹窄、已知的漏洞類別。但對於一個旨在發現並驗證上下文漏洞的代理程式來說，從 SAST 報告開始會產生三個可預見的失敗模式。

首先，它會鼓勵過早的縮小範圍。發現列表是工具已經查看過的地方的地圖。如果你將其作為起點，可能會使系統偏向於在相同的區域投入不成比例的精力，使用相同的抽象，並遺漏不符合該工具世界觀的漏洞類別。

其次，它會引入難以撤銷的隱含判斷。許多 SAST 發現都編碼了關於淨化、驗證或信任邊界的假設。如果這些假設是錯誤的——或者僅是不完整的——將它們餵入推理循環可能會使代理程式從「調查」轉向「確認或駁回」，這不是我們希望代理程式做的。

第三，這會使評估推理系統變得更加困難。如果管道從 SAST 輸出開始，就很難區分代理程式透過自身分析發現的內容與它從另一個工具繼承的內容。如果你想準確衡量系統的能力（這是系統隨時間改進所必需的），這種區分非常重要。

因此，我們構建 Codex Security 是為了從安全研究的起點開始：從程式碼和系統意圖出發，並使用驗證來提高信心門檻，然後才去打擾人工。

SAST 工具仍然非常重要

SAST 工具在它們設計的領域表現出色：執行安全編碼標準、捕捉簡單的來源到接收點問題，以及在可預見的權衡下大規模檢測已知模式。它們可以是深度防禦的重要組成部分。

這篇文章的觀點較為狹窄：它是關於為什麼一個旨在推理行為並驗證發現的代理程式，不應該將其工作錨定在靜態發現列表上。

同樣值得指出純粹「來源到接收點」思維的一個相關局限性：並非每個漏洞都是資料流問題。許多現實中的失敗是狀態和不變量問題——工作流繞過、授權漏洞以及「系統處於錯誤狀態」的錯誤。對於這些類型的漏洞，受污染的數值並未到達單個「危險接收點」。風險在於程式假設永遠為真的事情失效了。

展望未來

我們預期安全工具生態系統將持續改進：靜態分析、模糊測試（fuzzing）、運行時防護和代理型工作流都將各司其職。

我們希望 Codex Security 擅長的是對安全團隊來說成本最高的部分：將「這看起來很可疑」轉化為「這是真實存在的，這是它失敗的方式，以及這是符合系統意圖的修復方案」。

如果您想了解更多關於 Codex Security 如何掃描儲存庫、驗證發現並提出修復建議的資訊，請參閱我們的文件。

延伸閱讀

安全 | 2026 年 3 月 11 日

產品 | 2026 年 3 月 10 日

產品 | 2026 年 3 月 6 日