人工智慧助理產生的程式碼中，近一半都存在安全漏洞，即便這些程式碼看起來功能齊全且已達到生產就緒狀態。這並非空穴來風：Veracode 發布的《GenAI 代碼安全 2025》報告對 80 項編碼任務中的一百多種語言模型進行了測試，結果發現 45% 的樣本未能通過安全測試，其中不乏 OWASP Top 10 等經典安全漏洞。.
在企業環境中應用最廣泛的程式語言Java中，失敗率高達72%。同時，史丹佛大學發表在ACM CCS會議上的研究表明，使用人工智慧助理的開發人員不僅編寫出安全性更低的程式碼，而且還聲稱他們相信自己編寫的程式碼是安全的。.
Gartner 預測，到 2028 年，大型公司中 75% 的軟體工程師將使用 AI 助理進行程式設計。在巴西，GitHub 對 500 名大型公司受訪者進行的一項調查（於 2024 年發布）顯示，超過 97% 的開發人員已經在工作中使用這些工具，這一比例與美國、德國和印度等經濟體的比例相當。.
語言模型的局限性
問題的根源在於這些系統的本質。語言模型並不「理解」技術意義上的安全問題。它們基於機率運行，重現訓練資料中存在的模式。由於這些數據既包含最佳實踐，也包含存在漏洞的實現，因此結果往往反映出這種模糊性。.
這類漏洞尤其危險，因為它不會以明顯的錯誤形式出現。安全漏洞可能潛伏數月之久，系統看似正常運行，卻暗藏著資料外洩、未經授權的存取以及為未來的攻擊埋下隱患。.
實際上，我們觀察到的是已知缺陷的放大，而且規模更大。其中最常見的包括注入問題、查詢使用不當、輸入驗證不足、API呼叫建構不安全。在許多情況下，該模型提出的解決方案看似標準，但卻忽略了資料來源、信任限製或特定業務規則等上下文細微差別。.
身份驗證和授權失敗也時有發生。人工智慧產生的工作流程往往會簡化流程，省略中間驗證步驟或賦予比實際需要更廣泛的權限。在企業環境中，這種簡化可能會導致未經授權的使用者存取敏感資料或管理功能。.
另一個相關因素是依賴項的使用。模型通常會建議外部函式庫來解決特定問題，但它們並非總是考慮這些元件的安全性或成熟度。在某些情況下，它們甚至會推薦過時或不存在的軟體包，這會為供應鏈攻擊帶來可乘之機，例如惡意註冊與模型本身推薦名稱相同的程式庫。.
如何安全地應用人工智慧
核心問題不再是組織是否會在開發中使用人工智慧，而是如何建構與程式碼投入生產環境速度相符的控制措施。將所有語言模型輸出視為不受信任的第三方程式碼，並將針對人工智慧特定漏洞模式校準的靜態和動態分析直接整合到持續整合/持續交付 (CI/CD) 管線中，是解決問題的起點。.
在影子人工智慧暴露組織資產之前對其進行映射和控制是第二步，任何經批准的工具清單都無法取代有效的技術控制措施來防止外部提供者的資料外洩。.
因此，正在形成的是一種發展理念的根本性轉變。人工智慧不會取代軟體工程師，但它會改變這個專業人員的角色。工作重點從編寫程式碼轉移到驗證、解釋和確保產生的程式碼符合安全性、品質和合規性要求。.
Gartner 在《2026 年預測報告》中估計，如果不重新設計審查流程，到 2028 年，人工智慧驅動的程式碼產生方法將使軟體缺陷增加 2500%。這並非災難性的預測，而是基於目前採用率和已記錄的漏洞率所做出的規模預測。.
歸根究底，風險不在於技術本身，而是如何融入流程。那些將人工智慧視為加速器而不調整管控措施的組織，往往會以超過其應對能力的速度累積漏洞。相反，那些建構完善的治理、可觀測性和工程規範的組織，能夠在不犧牲安全性的前提下提高生產力。.
