事件背景：會執行，不等於能安全上線
生成式 AI 已從補完幾行程式碼，走向能修改多個檔案、建立相依套件，甚至操作測試與部署流程的代理式開發。然而，Veracode 2026 年研究指出，模型在語法與功能上的進步，尚未同步轉化為安全性。eSecurity Planet 對報告的整理顯示，整體安全通過率約為 56%，換言之，約 44% 的受測生成任務出現可偵測的弱點；相較之下，語法通過率已接近百分之百。原始報導見：https://www.esecurityplanet.com/threats/veracode-finds-ai-generated-code-still-struggles-with-security/
這裡必須先區分「研究事實」與「延伸解讀」。研究測量的是特定基準任務能否通過靜態應用程式安全測試（SAST），不是宣稱現實世界所有 AI 程式碼都有 44% 含漏洞；同樣地，能編譯或通過語法檢查，也只代表程式結構成立，並不保證資料驗證、權限控管與輸出編碼正確。
測試如何運作
Veracode 延續既有框架，以 Java、JavaScript、C# 與 Python 四種語言，搭配 SQL 注入、跨網站指令碼（XSS）、日誌注入及不安全密碼演算法四類 CWE，組成 80 項任務。模型依註解補完函式，而題目刻意允許安全與不安全兩種實作，再以 Veracode 自家 SAST 判定結果。2026 年報告頁列出的夏季資料顯示，GPT-5.5 以 68% 居首，但 11 個模型中有六個落在 50% 至 53%；程式碼專用模型平均 51%，一般模型平均 52%。第一方報告頁：https://www.veracode.com/resources/analyst-reports/2026-genai-code-security-report/
語言與弱點類型的落差更值得注意。報導整理的年度結果中，Python 安全通過率約 63%，Java 僅約 30%；SQL 注入與不安全密碼演算法約有 83%及 87% 通過，XSS 與日誌注入卻只有約 15%及 12%。合理推論是：模型可能較容易重現具明確、安全慣例的局部寫法，遇到需要理解資料流、輸出情境或跨元件信任邊界的問題時，表現便快速下降。但這只是與結果相符的解釋，不能由該基準單獨證明模型的內部成因。
為何現在值得注意
問題不只是「AI 偶爾寫錯」，而是產生程式碼的速度可能超過審查與修補能力。過去一名工程師一次提交有限範圍的變更；代理式工具則能快速建立多個檔案、引入套件及調整建置設定。如果組織仍以提交數量、交付速度或功能通過率衡量效率，安全缺陷就可能被轉化為大量待處理的安全債。
作者觀點是，真正的管理單位不應是「用了哪個最強模型」，而是「一項變更在進入正式環境前，經過哪些可稽核的控制」。因為報告顯示模型規模與程式碼專用訓練並未帶來穩定的安全優勢，只靠升級模型，不足以取代安全開發生命週期。
實際影響與可行控制
OWASP 的 AI 安全編碼指引提供了獨立交叉驗證：它要求對 AI 建議的套件查核是否真實存在、對每份相依清單執行弱點稽核、讓 CI/CD 在發現已知漏洞時失敗，並為每項 AI 變更指定可追溯的人類負責人。對能操作儲存庫與部署流程的代理，還應採最小權限、隔離執行環境與人工核准閘門。來源：https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html
- 在合併請求階段執行 SAST、祕密掃描與相依套件分析，不因程式碼由 AI 產生而降低門檻。
- 對驗證、付款、個資、權限及建置部署設定，要求具名人工審查與測試證據。
- 記錄工具、模型版本、提示脈絡及核准者，讓事故發生後能追查變更來源。
- 限制代理的寫入、網路與憑證權限，避免一段不安全輸出直接變成供應鏈事件。
容易忽略的研究限制
首先，Veracode 同時是研究發布者與應用安全產品供應商，且結果由自家 SAST 判定；這不代表數據無效，但讀者應保留利益關係與工具偵測範圍的意識。其次，80 項受控任務只涵蓋四種語言及四類 CWE，不能直接外推到行動 App、韌體、雲端權限或完整系統架構。第三，測試著重未提供安全指引時的「開箱」表現，不能回答安全提示、檢索既有規範或多輪修正後能改善多少。
此外，SAST 擅長辨識部分原始碼模式，卻無法單獨覆蓋執行期設定、商業邏輯及真正可利用性。因此，56% 是一個基準通過率，不是事故機率，也不能用來比較任何一家企業的實際風險。NIST 的 SSDF 同樣主張把組織準備、軟體保護、安全產出與漏洞回應整合進生命週期，而非把單一掃描器當成完整答案：https://csrc.nist.gov/projects/ssdf
對台灣團隊的意義與後續指標
台灣的金融、製造、醫療與政府資訊系統仍有大量 Java 與委外開發，恰好與報告中表現最弱的語言，以及責任容易跨組織斷裂的情境重疊。採購契約若只要求功能驗收，卻未要求 AI 使用揭露、弱點掃描、相依清冊及修補時限，就可能把效率收益留給供應商，將後續風險轉嫁給業主。
後續不必只追逐排行榜，而應觀察四項指標：相同任務跨版本的安全通過率是否持續改善；XSS、日誌注入與 Java 等弱項是否收斂；AI 變更進入正式環境前的掃描覆蓋率與人工審查率；以及弱點新增速度是否仍高於修補速度。AI 寫程式的商業價值是真實的，但只有當安全驗證也能同步規模化，速度才不會變成更快累積風險的另一個名字。