Vibe Coding 真的安全嗎？ CMU 這篇論文主要研究的是「基於真實世界任務的Agent 生成程式碼漏洞基準測試」，雖然AI Agent 在程式碼生成的「功能性」上表現越來越好，但在「安全性」上卻令人震驚地脆弱。即便是在功能上完美運行的程式碼，有超過80% 都包含嚴重的安全漏洞。 背景：什麼是"Vibe Coding"？為什麼它很危險？ 「Vibe Coding」 是一種新興的程式設計範式：程式設計師不再逐行編寫程式碼，而是用自然語言給予模糊或高層的指令，讓LLM Agent 去自動完成複雜的編碼任務。 現況：這種方式大大提高了效率，75% 的受訪者正在使用它。 隱憂：使用者往往只看程式碼「能不能跑通」（功能性），而很少有能力或意願去深究程式碼「是否安全」。論文指出，這種盲目信任正將巨大的安全風險引入生產環境。 研究方法：SUSVIBES 基準測試為了驗證安全性，團隊建構了一個名為SUSVIBES 的全新基準測試集。 真實來源：有別於以往僅測試簡單的單一檔案/單函數，SUSVIBES 從真實世界的開源專案（GitHub）中挖掘了200 個歷史上曾發生過安全漏洞的複雜功能需求。 測試流程： · 找到一個被修復過的漏洞（例如：修正了SQL 注入的某個版本）。 · 將程式碼回滾到修復前，並讓AI Agent 重新實作這個功能。 · 雙重驗證：既跑「功能測試」（看功能是否實現），也跑「安全測試」（看是否重現了原來的漏洞）。 核心發現：令人不安的“高分低能” 團隊測試了目前最頂尖的Agent 框架（SWE-Agent, OpenHands）和模型（Claude 4 Sonnet, Gemini 2.5 Pro, Kimi K2）。結果非常具有警示意義： 功能強但極度不安全： · 表現最好的組合（SWE-Agent + Claude 4 Sonnet）能解決61% 的任務（功能正確）。 · 但是，在這些功能正確的程式碼中，只有10.5% 是安全的。 換句話說，超過80% 的「好程式碼」實際上含有嚴重漏洞（如競態條件、權限繞過、注入攻擊等）。 模型差異： · Claude 4 Sonnet：功能最強，但產生的漏洞也最多。 · Gemini 2.5 Pro：雖然功能通過率較低（19.5%），但在它能解決的問題裡，安全性相對較好（被評為相對「最安全」的模型）。 · Kimi K2：處於中間水平。 安全性提示（Prompting）無效： · 研究人員嘗試告訴AI：「請注意安全」、「請檢查是否有CWE 漏洞」。 · 結果：不只安全性沒有顯著提升，反而導致AI 過度敏感，連正常的功能都寫不對了（功能通過率下降約6%）。 案例分析：漏洞是如何產生的？ 論文中舉了一個生動的例子（Django 框架中的密碼驗證函數）： · 任務：實作一個verify_password 函數。 · AI 的做法：程式碼寫得很漂亮，邏輯也對。但是，當遇到無效用戶時，AI 為了「效率」直接回傳了False。 · 安全後果：這製造了一個**時間側通道攻擊（Timing Side-Channel）**漏洞。駭客可以透過回應時間的微小差異，判斷出一個使用者名稱是否存在於系統中。 · 結論：AI 往往只關注“邏輯正確”，而完全不懂“安全工程”的深層原則（如恆定時間比較）。 總結與建議這篇論文是對當前AI 程式設計熱潮的一記警鐘。 · 對於開發者：絕對不要盲目信任AI 產生的程式碼，尤其是涉及認證、加密、資料解析等敏感模組。 "能跑通" $\neq$ "安全"。 · 對於企業：在採用AI 程式設計工具（如Cursor, Claude Code）時，必須強制引入人工安全審查或自動化的安全掃描（SAST/DAST），不能只依賴單元測試。 · 未來方向：簡單的Prompt 提示無法解決安全性問題，我們需要專門針對安全性訓練的新一代Agent。 論文原文
