快速摘要
研究顯示 AI 生成的程式碼中，安全漏洞的比例高於人類撰寫的程式碼。本文對照 OWASP Top 10，逐一分析 AI 最容易產生的漏洞類型，並提供具體的檢查方法。
AI 程式碼的安全現況
AI 寫的程式碼「看起來」很正確——語法正確、邏輯通順、可以運行。但安全性是另一回事。AI 模型是從大量開源程式碼中學習的，而開源程式碼中本身就包含大量安全漏洞。
常見的問題模式：
- 缺少輸入驗證和消毒（sanitization）
- 使用已知有漏洞的函式或套件版本
- 硬編碼密鑰和憑證
- 缺少錯誤處理，導致資訊洩漏
- 不安全的預設設定
OWASP Top 10 對照
| OWASP 排名 | 漏洞類型 | AI 產生頻率 | 範例 |
|---|---|---|---|
| A01 | Broken Access Control | 高 | AI 常忘記加入權限檢查 |
| A02 | Cryptographic Failures | 中 | 使用 MD5 而非 bcrypt |
| A03 | Injection | 高 | SQL 字串拼接、未消毒的用戶輸入 |
| A04 | Insecure Design | 高 | 缺少速率限制、CSRF 保護 |
| A05 | Security Misconfiguration | 高 | Debug 模式開啟、CORS * |
| A06 | Vulnerable Components | 中 | 引用舊版套件 |
| A07 | Auth Failures | 高 | Session 管理不當 |
| A08 | Data Integrity Failures | 中 | 未驗證外部資料 |
| A09 | Logging Failures | 高 | AI 很少自動加入日誌 |
| A10 | SSRF | 中 | 未驗證 URL 參數 |
AI 常犯的漏洞模式
1. SQL Injection
AI 經常生成字串拼接的 SQL 查詢，而非使用參數化查詢。這是最基本也最危險的漏洞。
2. 缺少輸入驗證
AI 生成的 API 端點通常直接使用用戶輸入，沒有驗證型別、長度或格式。
3. 硬編碼秘密
AI 在範例中經常使用硬編碼的 API Key 或密碼，開發者如果直接複製可能忘記替換。
4. 不安全的預設
CORS 設為 *、debug 模式預設開啟、不安全的 cookie 設定——AI 傾向於生成「能跑就好」的設定。
自動化檢查工具
- Semgrep：輕量級 SAST 工具，有預設的安全規則
- CodeQL：GitHub 內建的程式碼分析引擎
- Snyk Code：即時掃描程式碼漏洞
- Bandit：Python 專用的安全掃描
- ESLint Security Plugin：JavaScript 安全規則
安全審查工作流
- AI 生成程式碼
- 開發者初步審查邏輯正確性
- 執行自動化 SAST 掃描
- 人工檢查 SAST 報告的每一個警告
- 特別檢查：輸入驗證、認證授權、秘密管理
- 通過所有檢查後才合併
常見問題
AI 生成的程式碼比人寫的更不安全嗎？
研究顯示確實如此。AI 傾向生成功能正確但安全性不足的程式碼，因為它學習的開源程式碼中本身就有大量安全漏洞。關鍵不是不用 AI，而是確保有安全審查流程。
自動化掃描工具能抓到所有漏洞嗎？
不能。SAST 工具可以抓到已知模式的漏洞（如 SQL Injection），但邏輯漏洞、業務邏輯錯誤和設計缺陷需要人工審查。建議兩者結合使用。
如何訓練 AI 生成更安全的程式碼？
在 Prompt 中明確要求：使用參數化查詢、加入輸入驗證、不要硬編碼秘密、使用安全的套件版本。或者建立一個安全 Prompt 模板。