—
title: “AI 寫的程式碼有漏洞，誰來抓？OpenAI Codex Security 的答案讓資安界沉默了”
slug: “openai-codex-security-ai-vulnerability-scanner”
date: “2026-03-28”
description: “OpenAI Codex Security 上線 30 天掃描 120 萬筆 commit，揪出 11,000 個高危漏洞、14 個正式 CVE。它不是傳統掃描器，而是像真正資安研究員一樣建 threat model、驗證可利用性。這對企業 AI 導入有什麼啟示？”
tags: [AI, 資安, OpenAI, CodexSecurity, 企業AI]
author: “黃敬峰（AI峰哥）”
seo_title: “OpenAI Codex Security：AI 資安研究員 30 天掃出 14 個 CVE”
seo_description: “OpenAI Codex Security 上線一個月掃描 120 萬筆 commit，揪出 11,000 個高危漏洞含 14 個 CVE。了解它如何像真正的資安研究員一樣運作，以及對企業的啟示。”
focus_keyphrase: “Codex Security”
—
> 社群版講了核心觀念，本文加上獨家深度分析、CVE 實例解析和企業導入建議。
—
## 重點回顧
OpenAI 在三月初上線了 Codex Security，一個月內掃描 120 萬筆程式碼提交紀錄，揪出 11,000 多個高危漏洞（含 792 個 critical），並在 OpenSSH、GnuTLS、Chromium 等知名開源專案中取得 14 個正式 CVE。它的運作方式不是傳統比對式掃描，而是像真正的資安研究員一樣建立威脅模型、驗證可利用性、附上修補方案。
—
## 【獨家】CVE 實例解析：AI 到底找到了什麼
光說 14 個 CVE 可能沒有感覺，讓我拆開幾個具體的例子。
GnuTLS 的三連發
GnuTLS 是很多 Linux 系統預設的 TLS 加密函式庫。Codex Security 在裡面找到了三個漏洞：
- CVE-2025-32990：certtool 的 Heap-Buffer Overflow。簡單說，就是處理憑證的工具在記憶體管理上有問題，攻擊者可以透過特製的憑證讓程式崩潰，甚至執行任意程式碼。
- CVE-2025-32989：SCT 擴展解析的 Heap Buffer Overread。解析 Certificate Transparency 資料時會讀取超出緩衝區的記憶體，可能洩漏敏感資訊。
- CVE-2025-32988：otherName SAN 匯出的 Double-Free。記憶體被釋放兩次，這是經典的安全漏洞類型，可能導致程式崩潰或被利用來執行惡意程式碼。
GOGS 的認證繞過
GOGS 是一個輕量級的 Git 自架服務（類似 GitHub 的自建版）。Codex Security 在裡面找到了兩個嚴重問題：
- CVE-2025-64175：雙因子認證（2FA）繞過。啟用了 2FA 的帳號可以被繞過驗證直接登入。
- CVE-2026-25242：未授權存取繞過。不需要登入就能存取應該受保護的資源。
這些不是理論上的漏洞。每一個都經過沙盒環境驗證，確認可以被實際利用。以前要找到這種等級的漏洞，資安研究員可能需要花好幾週甚至幾個月深入分析程式碼。
—
## 【獨家】為什麼傳統工具抓不到這些
如果你的公司有在用資安掃描工具，像 SonarQube、Snyk、Checkmarx，你可能會問：這些工具不是早就有了嗎？
問題在於，傳統工具的運作原理是
規則比對（pattern matching）。它維護一個已知漏洞模式的資料庫，然後把你的程式碼跟這些模式比對。符合就標紅，不符合就放行。
這種做法有三個根本性的限制：
1. 無法理解上下文
一段程式碼是不是安全的，取決於它在整個系統中的位置。同樣一個 SQL 查詢，放在內部工具裡可能沒問題，放在面對外部用戶的 API 裡就是 SQL injection 的溫床。傳統工具看不到這個差異。
Codex Security 會先建立整個專案的 threat model：哪些是對外的入口點、哪些是信任邊界、哪些地方處理敏感資料。它是帶著全局觀去找漏洞的。
2. 無法驗證可利用性
傳統工具會告訴你「這裡可能有問題」，但不會告訴你「這個問題真的可以被攻擊者利用」。結果就是大量誤報，工程師看到滿螢幕的紅字就麻木了。
Codex Security 會在沙盒環境裡實際嘗試利用漏洞。通過驗證的才會被標記，所以它的 critical 漏洞出現率不到 0.1%——噪音極低。
3. 無法發現新型漏洞
規則比對只能找到已知模式。但真正危險的往往是全新的攻擊向量。Codex Security 因為是用 AI 理解程式碼的語意，所以可以發現傳統工具遺漏的問題。
—
## 【獨家】AI 寫 Bug 又 AI 抓 Bug：矛盾還是務實？
這裡有一個很有趣的矛盾需要談。
今年三月，Help Net Security 發佈了一份報告，指出主流的 AI 程式碼助手——包括 Claude Code、OpenAI Codex、Google Gemini——都會重複產出已知的資安錯誤。不是新型態的漏洞，是
十年前就被公開揭露的老問題。
所以 OpenAI 推出 Codex Security，某種程度上是在幫自己的產品善後。AI 寫的程式碼有安全問題？那就用另一個 AI 來檢查。
聽起來有點荒謬，但我覺得這其實很務實。
就像汽車工廠有自動焊接機器人，也有自動品質檢測機器人。製造端和品管端用不同的自動化系統，是完全合理的。
我在企業培訓時常常跟學員說：AI 是工具，不是魔法。你用 ChatGPT 寫完程式碼，不代表那段程式碼就是安全的。
生成和審查是兩個不同的步驟，不能混為一談。
—
## 阿峰觀點：企業該怎麼看待 AI 資安
我服務過超過 400 家企業，觀察到一個很明顯的趨勢：大部分公司在導入 AI 的時候，腦袋裡只有「效率」兩個字。
用 AI 寫報告更快、做簡報更快、寫程式碼更快。但很少有人在想：
AI 產出的東西，品質和安全性夠不夠？
Codex Security 的出現，代表 AI 正在從「生產力工具」進化為「品質管控工具」。這個轉變很關鍵。
如果你是企業決策者，我建議你現在就開始想三件事：
第一，AI 產出需要被審查。不管是報告、程式碼、還是行銷素材，AI 生成的內容不應該直接送出。需要有一個審查流程，而這個審查流程本身也可以用 AI 來加速。
第二，資安不是 IT 的事。當你的團隊開始用 AI 寫程式碼，資安就變成所有人的事。ChatGPT 企業版用戶現在可以免費試用 Codex Security 一個月，至少讓你的開發團隊試一下。
第三，開源專案維護者要注意。OpenAI 有一個「Codex for OSS」計畫，提供免費的安全掃描。如果你有在維護開源專案，這是一個值得申請的資源。它已經透過這個計畫發現了 13 個高影響力的漏洞，包括路徑穿越、阻斷服務和認證繞過。
—
## 本文提到的資源
—
想了解怎麼在你的企業中安全地導入 AI？阿峰老師服務過超過 400 家企業，從金融到製造、從科技到醫療。
→
www.autolab.cloud
—
### 關於作者
黃敬峰（AI峰哥），企業 AI 實戰培訓專家，400+ 企業合作、10,000+ 學員。
核心心法：「會用、懂用、好用、每天用」
官網：https://www.autolab.cloud