OpenAI 於 2026 年 7 月 13 日將 Codex Security 開源上架，這個以 TypeScript 撰寫的應用安全工具在三個多月內累積 11,163 顆星標與 878 次分支，並於 10 月 20 日推出 0.5.1 版。它把漏洞探索、候選驗證、修補產生與既有修復複驗收進同一條命令列流程，以 Apache 2.0 許可證釋出，同時提供 TypeScript SDK 與 GitHub Action。在同類工具多數停留在告警列表的背景下，這個專案選擇處理安全掃描最難的一段：如何讓輸出真的被修掉。
Codex Security 是什麼？
Codex Security 是 OpenAI 開源的應用安全工具，內含命令列介面與 TypeScript SDK，可掃描儲存庫或 Git 差異，驗證漏洞後產生修補。
專案定位介於靜態分析工具與 AI 編碼代理之間。傳統靜態分析依靠規則匹配，覆蓋面廣但誤報率高；編碼代理具備推理能力，卻缺乏可重複的掃描流程與報告格式。Codex Security 的做法是把兩者接起來，由代理執行探索與驗證，再把結果納入結構化的掃描紀錄、嚴重度分級與 SARIF 匯出格式，讓輸出可以進入既有的安全作業流程。
工具以 @openai/codex-security 套件發布於 npm，同時提供縮寫指令 cs。除了獨立使用，它也可以作為 Codex 外掛在對話中觸發，或透過 GitHub Action 排程執行。這種三種入口的設計，反映 OpenAI 對使用場景的判斷：探索階段適合對話式互動，例行掃描適合自動化，兩者共用同一套掃描引擎。
Codex Security 有哪些核心功能？
功能涵蓋完整流程：掃描儲存庫、路徑或 Git 差異；驗證候選發現並產生補丁；起草 SECURITY.md 與威脅模型；匯出 SARIF 或發布至 Linear。
掃描範圍的彈性是最直接的功能差異。使用者可以掃描整個儲存庫，也可以用 --path 限定目錄、用 --diff 只檢查從某個基準修訂到 HEAD 的變更。第三種模式對持續整合特別有用，因為它把掃描成本壓在每次提交的實際改動上，而不是反覆重掃整個程式庫。
驗證環節則是這個工具與一般掃描器的分界線。官方文件描述的做法是：探索階段先大量產生候選發現，再由驗證階段逐項確認可利用性，通過驗證的項目才會進入報告，並可進一步產生補丁。同一條流程也支援反方向操作，也就是檢查既有修補是否真的關閉了原本的問題。這種雙向驗證在版本迭代頻繁的專案中價值明顯，因為修補回歸是安全團隊常見的隱性成本。
政策與威脅模型是第二組功能。cs policy 指令可以起草 SECURITY.md，草稿保存在儲存庫之外，使用者檢視差異後再決定是否複製回專案，避免工具直接改動版控內容。掃描與政策生成同時會保存威脅模型，可透過 cs export 單獨匯出。對於需要向稽核單位說明風險假設的團隊，這份文件往往比告警清單更有說服力。
第三組功能落在協作層。已保存的掃描可以瀏覽、比對與去重，嚴重度可依組織自訂的準則重新評估，工具也會從原始碼與 Git 歷史推測每個發現的負責人。輸出格式包含 SARIF、JSON 與 CSV，並可直接發布到 Linear 或自架的發現管理服務。這使得掃描結果不再停留於單次會話，而能進入 issue 追蹤系統形成待辦。
如何快速開始使用 Codex Security？
環境需求為 Node.js 22.13 以上的 22.x 分支，或 24.x、26.x，另需 Python 3.10 以上。以 npm 全域安裝後登入，於儲存庫目錄執行掃描指令。
安裝流程與一般 npm 全域工具相同，但官方文件特別提示兩個容易忽略的細節。其一是 cs 這個短指令若已被其他工具佔用，或 npm 在建立連結時回報 EEXIST 錯誤，就應改用完整的 codex-security 指令，或以 npx 直接執行而不做全域安裝。其二是 Python 3.10 環境需要額外安裝 tomli 套件，較新版本則已內建對應能力。
掃描模式有三種選擇。標準模式適合日常檢查，--mode deep 會啟動平行探索 worker，把儲存庫或選定路徑拆給多個 worker 並行分析，代價是時間與額度消耗上升。--max-time 15 則是給標準調查設定建議時限，讓單次掃描的成本可以預估。對首次接觸的使用者，建議先以單一目錄搭配標準模式執行，觀察報告結構與誤報比例，再決定是否擴大範圍。
持續整合的接法也已封裝完成。官方範例工作流程在 Ubuntu 24.04 上先安裝 bubblewrap 與 apparmor-profiles，載入限制 user namespace 的 AppArmor 設定，再執行掃描 Action。這段前置安裝不是可選項，因為掃描過程會執行程式碼與工具鏈，需要作業系統層級的隔離。工作流程預設只產出報告，使用者可設定嚴重度門檻，讓達到門檻的發現直接使工作失敗。
模型後端不限於 OpenAI。文件列出 Amazon Bedrock、OpenRouter、Fireworks AI 與 Cheaper Inference 四種替代路徑，其中 Bedrock 使用 AWS 憑證，不需要額外的 OpenAI 登入。對已經在特定雲平台建立模型存取管制的組織，這條設計降低了合規審查的阻力。
Codex Security 的技術架構有何特點？
架構以掃描為單位組織：探索 worker 並行產生候選發現，驗證階段過濾誤報，補丁階段生成修補，報告階段輸出威脅模型與多種格式。
從語言組成可以看出設計取向。TypeScript 佔程式庫約 968 萬位元組，遠高於 Python 的 274 萬位元組，另有 JavaScript、Rust 與 Shell 等少量成分。這意味著主體邏輯與使用者介面集中在 Node 生態，Python 部分主要承擔分析與工具鏈整合，而非核心流程。對以 Python 為主的資料團隊，這種分工需要額外的執行環境，但換來的是跨平台一致的命令列體驗。
掃描產物的組織方式值得注意。每次掃描會保存報告、發現清單、覆蓋範圍與威脅模型，形成可回溯的紀錄。覆蓋範圍欄位記錄了哪些路徑被排除、哪些因為工具缺失而未能檢查，這種透明設計在安全審查中比結果本身更關鍵，因為它讓管理者知道報告的盲區在哪裡。
被移除的功能也透露產品方向的調整。文件明確記載本地的 serve 指令與瀏覽器儀表板已經移除，既有資料庫與掃描產物仍可讀取，但新的檢視介面改由 Codex 桌面版或雲端發現服務承擔。這是把使用者介面從自架元件轉向既有客戶端的典型取捨，好處是維護面積縮小，代價是純命令列環境的體驗變得間接。
Codex Security 與現有安全掃描工具如何比較？
與靜態分析相比，它多了驗證與修補生成，誤報處理成本較低；與純編碼代理相比，它提供可重複流程與 SARIF 輸出，代價是需模型額度。
比較的關鍵維度是誤報成本。靜態分析工具依賴規則庫，能在數分鐘內掃描大型程式庫，但輸出常需要人工逐一判讀；Codex Security 把驗證交給模型，通過驗證的發現數量下降，單條發現的處理價值上升。對人力有限的小型團隊，這種取捨通常划算；對需要完整覆蓋面的大型組織，兩類工具更可能是互補而非替代。
第二個維度是資料邊界。掃描過程會把程式碼與相關上下文送往模型後端，這是所有 AI 安全工具的共同前提。專案支援多種後端，並可透過 Bedrock 走既有雲端憑證，但無論選擇哪一種，程式碼離開本地的本質不變。對於原始碼不得外流的產業，這個限制往往直接決定工具能否採用。
第三個維度是治理能力。Codex Security 提供嚴重度自訂準則、負責人建議、去重與發現管理服務整合，這些屬於企業導入的必要條件，而非加分項。專案同時要求部分資安請求與受保護發現需取得 Trusted Access for Cyber 核准，並提供 Daybreak Blue 存取方案，說明它在能力邊界上做了分級管制。
Codex Security 的關鍵數據表現如何？
截至 2026 年 10 月 22 日，專案累積 11,163 顆星標、878 次分支、193 個未結問題，最新版本 0.5.1，採 Apache 2.0 許可證。
版本節奏是這組數據中最值得注意的部分。專案在三個多月內累積 38 個版本標籤，10 月 16 日至 20 日之間連續推出 0.4.0、0.5.0 與 0.5.1，涵蓋 npm 套件與 GitHub Action 兩條發布線。這種頻率說明專案仍在快速調整階段，功能與介面都可能變動，導入時應預留升級成本。
星標與分支的比例則反映關注結構。878 次分支相對 11,163 顆星標屬於中等水平，說明多數使用者仍在觀望或評估，尚未進入深度客製。193 個未結問題對應這個階段也屬正常範圍，但意味著使用者在遇到邊界情境時，可能需要自行判斷或等待修復。
企業導入 Codex Security 需要注意什麼？
三項前置條件應先確認：程式碼可送往所選模型後端、環境具備指定 Node 與 Python 版本、粗估掃描額度。專案仍在 0.x 階段，宜先試行。
第一項是資料治理。掃描會把程式碼片段與相關上下文送到模型，即使選擇自架路徑，模型推論仍在外部完成。導入前應由法務與資安共同確認哪些儲存庫可以掃描，並用 --path 與排除清單把敏感目錄擋在流程之外。這一步的設計品質，往往比工具本身的檢出率更影響實際成效。
第二項是執行環境。專案要求 Node.js 22.13 以上的 22.x 分支，或 24.x、26.x，另需 Python 3.10 以上。在 CI 映像中固定版本是必要動作，否則 Node 主版本升級可能造成套件解析失敗。若使用官方 Action，還需安裝 bubblewrap 與對應的 AppArmor 設定，這在容器化 runner 中不一定預設可用。
第三項是成本控制。深度掃描以平行 worker 展開，額度消耗隨儲存庫規模與 worker 數量上升。建議先在單一元件上量測一次完整掃描的時間與用量，再換算為每月例行掃描的預算。--max-time 參數提供建議時限，但它是顧問性質而非硬性上限，實際用量仍需觀察。
最後是流程整合的現實。工具能把發現發布到 Linear 或自架服務，也能輸出 SARIF 供既有平台讀取，但嚴重度準則、負責人規則與修復期限仍需組織自行定義。把工具接上流程只是起點，真正決定成效的是後續的分派與追蹤紀律。
出處連結有哪些？
本文數據取自 openai/codex-security 官方儲存庫、README、版本發布紀錄與 GitHub API，資料讀取時間為 2026 年 10 月 22 日。
官方儲存庫：https://github.com/openai/codex-security
完整功能說明與指令參數刊載於儲存庫的 README 與 sdk/typescript/docs/cli.md，內容涵蓋掃描範圍、深度模式設定、政策生成、匯出格式與 CI 範例。GitHub Action 的輸入參數與 PR 掃描設定另見 github-action/README.md，容器化大量掃描的做法則記錄在 docker/README.md。
總結：Codex Security 適合什麼團隊？
需要把掃描結果直接轉為修補的團隊最適合，尤其人力有限、無法消化大量誤報的小型安全團隊；原始碼不得外流的組織應暫緩。
這個專案的價值不在檢出率數字，而在把流程後半段補齊。多數掃描工具的終點是一份報告，Codex Security 的終點是一組經過驗證的發現，加上對應的補丁與複驗結果。對安全人力稀缺的組織，這種設計能直接把報告轉為待辦，省下最耗時的判讀環節。
限制同樣清楚。0.x 版本的節奏意味著介面仍在變動，38 個版本標籤分布於三個多月，升級與回歸測試必須納入例行工作。程式碼需送外部模型處理，對受監管產業構成實質門檻。把這兩個前提納入評估，再對照團隊現有的掃描流程，才能判斷它究竟是補位工具，還是新一層維護負擔。
