AI 生成代碼的安全風險：數據、機理與治理 · 行業洞察

AI 已經在寫你公司相當比例的代碼——這不是預測，是現狀。真正的問題是：這些代碼的安全水位如何？實證研究給出的答案並不樂觀。

數據怎麼説

早在 2021 年，紐約大學團隊的《Asleep at the Keyboard》就發現：在高風險場景下，GitHub Copilot 生成的程序約 40% 存在可利用漏洞。
2025 年 Veracode 對 100 餘個模型、80 個編碼任務的橫向測試顯示：約 45% 的任務中 AI 引入了 OWASP Top 10 級別的安全缺陷，且這一比例並未隨模型迭代明顯下降——模型寫的代碼能跑得更好，卻沒有更安全。
斯坦福的對照實驗則揭示了更危險的一層：使用 AI 助手的開發者寫出的代碼更不安全，但他們對自己代碼安全性的信心反而更高。

安全缺陷率沒有質變，代碼產量卻在數量級增長。固定的漏洞率乘以暴漲的分母，等於漏洞絕對數量的洪水。

訓練語料帶病。模型從海量公開代碼中學習，也把其中的老舊寫法、棄用 API 和典型漏洞模式一併學了進去。

上下文缺失。模型看不到你的威脅模型：這段輸入來自不可信用户嗎？這個接口暴露在公網嗎？缺少這些語境，它會默認「樂觀場景」。

提示不含安全約束。開發者的指令幾乎總是「實現這個功能」，而不是「安全地實現這個功能」。研究反覆證明，不明確要求，模型就不會主動加固。

幻覺依賴（slopsquatting）。模型會以可觀比例虛構不存在的包名，攻擊者批量搶注這些名字即可守株待兔——AI 時代特有的仿冒包攻擊，我們在供應鏈投毒的演化一文中有更多案例。

如果代碼在秒級產生，安全就不能停留在「上線前掃一遍」。四個可落地的動作：

實時檢測：在代碼寫下的同刻完成分析——無論作者是人還是 AI。這要求引擎理解業務語義與數據流，而不是逐條匹配規則，否則誤報會在 AI 的產量下把團隊淹沒。安勢 CleanCode Security Agent 將誤報率控制在 15% 以下、增量掃描小於 60 秒，正是為這個節奏設計的。
修復閉環：檢測、研判、修復收斂進同一個回合，讓 AI 引入的問題由 AI 當場修掉，而不是進入積壓隊列。
依賴准入：對 AI 建議引入的每一個依賴做存在性與信譽校驗，掐斷幻覺包與仿冒包。
CI 卡點兜底：流水線上保留最終關卡，讓繞過實時檢測的代碼在合入前被攔下。

沒有度量的治理只是姿態。建議把三個指標納入研發效能看板：

AI 代碼佔比與漏洞密度分開統計：知道 AI 寫了多少，還要知道 AI 寫的那部分每千行引入多少缺陷，兩條曲線分開看才能定位問題。
檢測時延：從代碼寫下到問題被發現的時間。目標是從「天」壓縮到「秒」，這直接決定修復成本——上下文還在開發者腦子裏時修復，與兩週後從積壓隊列裏撈出來修復，成本差一個數量級。
修復閉環率：檢出的問題有多少在同一開發回合內被修掉。這是衡量「檢測工具」與「安全能力」差距的唯一指標。

相應地，安全團隊的角色也在變：從逐行審查代碼的「守門人」，轉為規則與上下文的供給者——把企業的威脅模型、安全編碼規範、可用組件白名單編碼進 AI 的工作上下文與流水線卡點，讓每一次生成都在約束內進行。管一個水龍頭的時代結束了，現在要管的是水廠。

AI 不會放慢速度等安全。團隊能選擇的，只是讓安全跑進生產時刻，還是留在事後追趕。