AI 生成漏洞模式
AI 生成程式碼中常見漏洞模式的概覽，包含模型為何產生不安全程式碼，以及這些模式如何與人類引入的漏洞不同。
AI 程式設計助理以顯著比率產生包含安全漏洞的程式碼。這不是任何個別模型的缺陷，而是這些模型被訓練方式的結構性後果：它們從既有程式碼的廣大語料庫學習，而既有程式碼包含漏洞。模型重現其訓練資料的統計模式，包含不安全模式。
為何 AI 模型產生脆弱程式碼
數個因素導致 AI 生成程式碼中漏洞的盛行。
訓練資料分布
程式碼生成模型的訓練資料壓倒性地由來自公共儲存庫的程式碼組成。此程式碼包含教學、範例、原型與從未預期用於生產的遺棄專案。注重安全的生產程式碼是訓練分布的少數。
模型學到 SELECT * FROM users WHERE id = ' 後接字串串接是常見模式，因為它頻繁出現在教學與 Stack Overflow 答案中。使用參數化查詢的安全替代方案在訓練資料中出現較不頻繁，所以模型較不可能建議它。
對功能性的最佳化
程式碼生成模型被最佳化以產生功能正確的程式碼——完成陳述任務的程式碼。安全性是非功能屬性，通常不是評估標準的一部分。使用字串串接正確查詢資料庫的函式與使用參數化查詢正確查詢的函式，以模型訓練目標衡量同等「正確」。
上下文敏感性
模型基於周圍上下文產生程式碼。如果既有程式碼庫使用不安全模式，模型會為一致性遵循這些模式。這意味著具有既有安全問題的專案會收到延續這些問題而非修正它們的建議。
不完整規格
開發者經常對 AI 程式設計工具提供不完整規格。「撰寫一個認證使用者的函式」不指定常數時間比較、速率限制、帳戶鎖定或稽核日誌。模型產生最小可行實作，通常不安全。
AI 漏洞與人類漏洞的差異
AI 生成漏洞有數個將它們與人類引入漏洞區別的特徵。
模式一致性。 當人類開發者引入 SQL 注入漏洞時，它可能出現在一個函式而非其他。AI 模型更一致：如果模型已學會對 SQL 查詢使用字串串接，它會在各處建議該模式。
意圖缺席。 人類開發者有時做有意識的安全權衡（「我稍後會加入輸入驗證」）。AI 模型沒有意圖——它們產生統計上最可能的延續。這意味著 AI 生成漏洞不是捷徑的結果，而是模式重現的結果。
脈絡依賴嚴重性。 相同的 AI 建議依上下文可能安全或不安全。處理可信資料時 pickle.loads() 呼叫安全，但處理使用者輸入時危險。模型不理解信任邊界。
可信的推諉性。 AI 生成漏洞看起來完全像人類會寫的程式碼。僅從程式碼無法判斷漏洞是由人類還是 AI 引入的，這使鑑識分析複雜。
漏洞類別
AI 生成漏洞聚集在數個類別：
輸入驗證失敗
最常見類別。模型經常產生在沒有驗證、清理或編碼的情況下處理輸入的程式碼。這包含 SQL 注入、跨站指令碼、命令注入與路徑遍歷。
加密弱點
模型經常建議已棄用演算法（密碼使用的 MD5、SHA1）、不安全模式（ECB）、硬編碼金鑰與不足的隨機性。加密 API 複雜，訓練資料包含遠多於正確使用的不正確使用範例。
認證與授權
產生的認證程式碼經常缺乏速率限制、使用時序脆弱比較、不安全地儲存密碼，並不完整實作授權檢查。這些模式難以透過靜態分析偵測，因為程式碼功能上正確。
資源管理
記憶體洩漏、檔案控制代碼耗盡與連線池耗盡在 AI 生成程式碼中常見。模型產生取得資源但可能在錯誤路徑中遺漏清理的程式碼。
資訊揭露
模型傾向產生暴露堆疊追蹤、檔案路徑、資料庫架構與內部狀態的詳細錯誤處理。這是因為詳細錯誤訊息在訓練資料（教學與範例）中比生產環境適當的錯誤處理更常見。
評估方法論
評估 AI 生成程式碼安全時：
- 識別 AI 生成部分 — 使用 git blame、PR 歷史與開發者訪談判斷哪些程式碼是 AI 生成的
- 應用基於模式的分析 — 使用本節的 CWE 對應檢查已知 AI 漏洞模式
- 測試信任邊界 — 驗證 AI 生成程式碼在每個邊界適當處理不可信輸入
- 審查加密使用 — 稽核所有加密程式碼的演算法選擇、模式選擇、金鑰管理與隨機性
- 檢查錯誤處理 — 驗證錯誤路徑不洩漏敏感資訊