2026 年所撰寫的所有新程式碼中,有 41% 是 AI 生成。Gartner 預測這將在 2028 年前帶來軟體缺陷 2,500% 的增加。而本月,Anthropic 展示了其最新模型能自主發現並利用嚴重的軟體漏洞 — 隨後暫緩了正式發布。產業已從「AI 能協助寫程式」轉向「AI 能快速在龐大程式碼庫中發現、驗證並利用缺陷」。 這個轉變背後的數字,要求企業安全與 AI 程式碼審查採取新方法。

大多數關於 AI 安全的報導聚焦於生成風險。本分析則聚焦於審查缺口 — 以及企業在缺陷浪潮到來前必須做出的架構變更。

2026 年有多少程式碼是 AI 生成?

目前的現況:

  • 84% 的開發人員使用 AI 程式碼工具;51% 每日使用
  • 90% 的企業軟體工程師將在 2028 年前使用 AI 程式碼助手(Gartner,從 75% 上修)

這樣的採用率正在產生可衡量的下游後果:

  • Gartner 預測 prompt-to-app 方法將在 2028 年前增加軟體缺陷 2,500%
  • 到 2028 年,50% 的企業網路安全事件回應將聚焦於 AI 驅動的應用程式事件
  • AI 代理程式將在 2027 年前將利用帳號暴露的時間縮短 50%

這些不是理論風險。它們是 AI 生成程式碼擴展速度超過程式碼保證的預計後果。

AI 驅動的漏洞發現:真實成果

防禦能力是真實的,而且跨越每個主要 AI 廠商都在加速。

Anthropic:Claude 與 Project Glasswing

Anthropic 報告 Claude Opus 4.6 在經過充分測試的開源程式碼庫中發現了超過 500 個高嚴重性漏洞,包含數十年未偵測到的錯誤。在另一項與 Mozilla 的合作中,Claude 在兩週內發現了 22 個 Firefox 漏洞,其中 14 個評為高嚴重性。透過 Project Glasswing,Anthropic 正投入高達 $1 億的使用額度與 $400 萬捐款給開源安全組織。

Google:Big Sleep 與 Project Zero

Google 的 Big Sleep 代理程式 — Project Zero 與 DeepMind 之間的合作 — 已在開源軟體中發現 20 個安全漏洞。其中一個,SQLite 中的 CVE-2025-6965,是先前只有威脅行為者知道的關鍵記憶體損壞缺陷。Google 宣稱這是 AI 代理程式首次直接挫敗一次活躍的利用嘗試。Big Sleep 也在 FFmpeg 中發現了 13 個漏洞,儘管揭露過程與維護者產生了摩擦,部分維護者稱某些報告為「CVE slop」 — 凸顯了 AI 規模發現與上游維護產能之間的緊張。

OpenAI 與 GitHub:Codex Security 與 Copilot Autofix

OpenAI 的 Codex Security 在測試期間掃描了超過 120 萬次 commit,發現 792 個關鍵與 10,561 個高嚴重性發現,並協助向包含 OpenSSH、GnuTLS、PHP 與 Chromium 在內的專案通報漏洞,共獲配 14 個 CVE。GitHub 的 Copilot Autofix 在 2025 年解決了 460,258 個安全警示,將平均修復時間從 1.29 小時縮短至 0.66 小時 — 快了近 2 倍。

工具範圍關鍵發現
Anthropic Claude Opus 4.6開源程式碼庫500+ 個高嚴重性漏洞
Mozilla + ClaudeFirefox兩週內 22 個漏洞,14 個高嚴重性
Google Big Sleep開源(SQLite、FFmpeg)20 個漏洞,包含活躍利用
OpenAI Codex Security掃描 120 萬次 commit792 個關鍵、10,561 個高嚴重性發現
GitHub Copilot AutofixGitHub 儲存庫2025 年解決 460,258 個安全警示

英國國家網路安全中心得出類似結論:AI「幾乎肯定」會使網路入侵的某些環節更有效,增加網路威脅的頻率與強度,並在能跟上步伐的組織與不能的組織之間造成數位鴻溝。

AI 生成程式碼漏洞:資料

方程式的另一半比較不令人放心。

Georgetown University 安全與新興技術中心發現,五個受測模型產生的程式碼片段中,近一半包含「往往具影響力且可能導致惡意利用」的錯誤。針對 GitHub Copilot 的「Asleep at the Keyboard」研究發現,在 89 個高風險 CWE 情境中,1,689 個生成程式有 40% 存在漏洞。來自 Stanford 與 DryRun Security 的較新資料顯示,87% 的 Copilot 提取請求引入漏洞,且 AI 生成程式碼的漏洞密度比人類撰寫的程式碼高 2.7 倍

供應鏈維度使情況更糟。USENIX Security 上關於套件幻覺的論文發現,產生程式碼的 LLM 以 商業模型 5.2%、開源模型 21.7% 的比率推薦不存在的套件,涵蓋 576,000 個生成樣本。攻擊者可透過以這些幻影名稱發布惡意套件來利用重複的幻覺。

而且有具體的財務成本。IBM 2025 年《資料外洩成本》報告將美國平均外洩成本定在創紀錄的 $1,022 萬。影子 AI — 開發工作流程中未經授權的 AI 工具 — 每次外洩平均增加 $67 萬成本,並增加 10 天的偵測與圍堵時間。經歷 AI 相關安全事件的組織中,97% 缺乏適當的 AI 存取控制,63% 完全沒有正式的 AI 治理政策。

早期抓到錯誤的投資報酬率

當 41% 的程式碼是 AI 生成時,移左安全的經濟學被放大。IBM 系統科學研究所發現,發布後發現的錯誤,修復成本最高可達設計階段識別出的100 倍。根據 IBM 2025 年報告,在安全計畫中廣泛使用 AI 與自動化的組織,每次外洩節省 $190 萬,並將外洩生命週期縮短 80 天。AI-in-review 的經濟論點,與 AI-in-generation 的風險論點一樣強而有力。

針對 AI 管線的軟體供應鏈攻擊

這不是理論風險。它正在發生。

2026 年 3 月,LiteLLM 供應鏈攻擊入侵了每天被下載 340 萬次的 PyPI 套件。攻擊者部署了三階段負載:針對 50+ 類密碼的憑證收割器、Kubernetes 橫向移動工具組,以及持續性後門。入口是先前對 Trivy 漏洞掃描器 — 一個安全工具本身 — 的入侵。

同樣在 2026 年 3 月,TeamPCP 強制推送了 75 個惡意版本標籤到 Trivy GitHub Action,將竊取憑證的負載注入跨越數千個儲存庫的 CI/CD 管線。一個安全掃描器 — 本應用來偵測漏洞的工具 — 被武器化用來對付 AI 供應鏈。

IBM X-Force 報告,自 2020 年以來大型供應鏈入侵增加了近 4 倍。ReversingLabs 的 2026 年報告顯示,開源平台上的惡意軟體增加 73%,且攻擊特別針對 AI 開發管線。供應鏈攻擊從 2024 年初的每月 13 起,增加到 2025 年 10 月的每月 41 起。2025 年,兩次重大的 npm 生態系攻擊使用 AI 生成程式碼,從 526+ 個套件竊取憑證。

OpenAI 自己 2026 年 4 月的 Axios 事件證明,AI 廠商自身仍暴露在風險中:一個惡意的 Axios 版本被 OpenAI macOS 簽署流程中使用的 GitHub Actions 工作流程下載並執行。根本原因是工作流程設定錯誤 — 使用浮動標籤而非特定 commit 雜湊。

這個模式是遞迴的:AI 產生包含漏洞的程式碼,本應捕捉這些漏洞的安全工具本身被入侵,而跟上步伐的唯一方式是在防禦端以同等強度部署 AI。這不是人類規模審查能單獨解決的問題。

AI 開發工具作為攻擊面:OWASP LLM Top 10

一旦 AI 嵌入 IDE、程式碼審查機器人、CI 工作流程與瀏覽器代理程式,問題就從「模型會寫出有錯的程式碼嗎?」擴大到「我們在環境中增加了哪些新的失敗模式?」

GitHub 自己針對 VS Code 代理程式模式的安全研究顯示,間接提示注入可暴露 GitHub 權杖、機密檔案,或在未明確取得使用者同意下啟用任意程式碼執行。OpenAI 的代理程式安全指引表示,提示注入「常見且危險」。Microsoft 的零信任指引表示,組織應假設間接提示注入不可避免,並為圍堵而設計。

**OWASP LLM 應用程式 Top 10(2025 年版)**將這些風險編纂成典。十個類別中有七個自 2023 年版本起變更,新增了:

  • 過度代理權 — LLM 被授予對工具與動作過多的控制
  • 系統提示洩漏 — 隱藏系統指令的暴露
  • 向量與嵌入弱點 — 利用 RAG 與向量資料庫
  • 無界限消耗 — 資源耗盡與成本攻擊

供應鏈上升到第三位。敏感資訊揭露上升到第二位。提示注入仍是第一位。

MITRE ATLAS — AI 系統的對抗性威脅框架 — 作為回應快速擴張。5.4.0 版(2026 年 2 月)包含 84 項技術、56 項子技術與 42 個真實世界案例研究,新技術包含「發布中毒 AI 代理程式工具」與「逃逸到主機」。2026 年 1 月,ATLAS 新增了涵蓋 MCP 伺服器入侵與透過 MCP 通道間接提示注入的案例研究。AI 賦能的對手攻擊年增 89%

建構企業 AI 程式碼審查管線

AI 驅動程式碼審查的理由不是程式碼助手不好。而是程式碼產生擴展產出的速度快於人類審查擴展保證的速度。Anthropic 表示「近期內全球相當比例的程式碼將由 AI 掃描」。OpenAI 將 Codex Security 定位為一個應用程式安全代理程式,可建立系統上下文、建立威脅模型、驗證發現並提出修補建議。

NIST SP 800-218A 讓這項義務明確化:審查標準不區分人類撰寫與 AI 生成的程式碼,因為所有原始碼在使用前都應評估漏洞。CISA 延伸了相同原則:「軟體必須在設計上安全,而人工智慧也不例外。」

針對企業團隊的實用近期架構:

  1. 經人類審查的 AI 生成 — 開發人員在架構決策中仍保持參與
  2. 自動化 SAST 與 CodeQL 掃描 — 在 commit 時捕捉已知漏洞模式
  3. 依賴項審查與密碼掃描 — 在合併前阻擋供應鏈風險與憑證外洩
  4. AI 驅動的漏洞審查 — Anthropic 的 Claude Code Security、OpenAI 的 Codex Security 或 GitHub Copilot Autofix 作為強制關卡
  5. 持續監控 — 對靜態分析無法捕捉的行為進行執行時偵測

GitHub 的 Copilot 程式碼代理程式現在會自動對每個提取請求執行 CodeQL 分析、依賴項審查與密碼掃描 — 不需要 GitHub Advanced Security 授權。Copilot 的 AI 驅動密碼偵測在測試中達到94% 的誤報減少


需要協助設計 AI 安全開發管線?聯絡 Big Hat Group進行架構審查。


使用 Azure Virtual Desktop 與 Windows 365 的爆炸半徑設計

爆炸半徑設計是一項安全架構原則,透過隔離敏感工作負載、限制橫向移動,以及最小化攻擊者從任何切入點能觸及的資料與系統,來限制任何單一入侵造成的損害。

如果入侵機率上升 — 而每個資料來源都顯示如此 — 那麼爆炸半徑縮減就變得與預防同等重要。

Microsoft 的 Azure Virtual DesktopWindows 365 雲端電腦平台為管理員提供了真正的控制項來縮小損害:僅應用程式傳遞,呈現個別應用程式而非完整桌面;Azure Firewall 鎖定連出流量;Conditional Access 用於 MFA 與政策執行;剪貼簿與磁碟重新導向可在單向或雙向停用;以及 Application Control for Windows 限制在受管理環境中執行哪些程式碼。

針對敏感或舊版應用程式,一個可辯護的模式:在可能時採用僅應用程式傳遞、嚴格限縮的網路連出、無不必要的本機重新導向、強大的身分控制,以及應用程式允許清單。現代 VDI 與雲端電腦平台讓這種圍堵架構,比舊式「一切都在本機工作站上」的模型容易落地營運得多。(這正是 Big Hat Group 為在 Windows 365 雲端電腦上執行敏感應用程式的客戶所部署的架構模式。)


Big Hat Group 部署 Windows 365 雲端電腦與 Azure Virtual Desktop 環境,正是採用這些圍堵模式。如果您的組織執行敏感或舊版應用程式,聯絡我們以討論您環境的爆炸半徑架構。


Microsoft Secure Future Initiative:企業影響

這不是附帶專案。Microsoft 的 Secure Future Initiative 動用了相當於 35,000 名全職工程師投入安全 — 數位史上最大的網路安全工程投入。成果包含 99.5% 的程式碼內活躍密碼偵測與補救、99.6% 的防釣魚 MFA 執行率、Microsoft 參考架構中全新的 Zero Trust for AI 支柱,以及 Microsoft 365 中專屬的 AI Administrator 角色

Microsoft 發布了實用的「Patterns and Practices」指南,讓其他組織能採用 SFI 原則,且 95% 的 Microsoft 員工完成了防範 AI 驅動網路攻擊的培訓。對於建構 AI 治理計畫的企業,SFI 框架提供了經驗證的起點。

企業 AI 安全檢查清單:2026 年的 6 項行動

底線很明確:Mythos 是頭條,但真正的策略變革,是漏洞發現的工業化,以及重新設計管線與工作站以實現圍堵的需要。

1. 稽核您的 AI 工具清查

影子 AI 每次外洩增加 $67 萬成本,97% 的 AI 相關外洩缺乏適當存取控制。了解您的環境中正在執行哪些 AI 工具。IBM 發現 63% 的組織沒有正式的 AI 治理政策。

2. 在合併關卡中加入 AI 驅動的安全審查

GitHub Copilot Autofix、Anthropic Claude Code Security 與 OpenAI Codex Security 現在都可用。讓安全審查成為強制的管線階段,而非可有可無的事後追加。在 commit 時捕捉到的錯誤,成本比在生產中發現的低 100 倍。

3. 強化您的軟體供應鏈

將依賴項釘到特定 commit 雜湊。為新套件設定最低發布天數。對每個提取請求執行依賴項審查。LiteLLM 與 Trivy 攻擊顯示,即使安全工具也可能被入侵。

4. 實施爆炸半徑控制

使用 Azure Virtual Desktop 或 Windows 365 進行敏感應用程式的僅應用程式傳遞。限制剪貼簿、磁碟重新導向與連出網路存取。套用應用程式允許清單。

5. 採用 AI 治理框架

NIST AI 600-1、OWASP LLM 應用程式 Top 10 與 MITRE ATLAS 提供分類法。Microsoft 的 SFI Patterns and Practices 提供操作手冊。CISA 的 Secure by Design 原則對 AI 程式碼的適用,與對人類程式碼的適用相同。

6. 培訓您的團隊

Gartner 表示,到 2027 年,80% 的工程人力將需要為生成式 AI 提升技能。安全意識必須是該培訓的一部分,而非獨立的軌道。

AI 賦能開發時代的贏家,不是更快產生 AI 程式碼的團隊。而是能更快審查 AI 生成程式碼、更快修補漏洞,並透過企業安全控制更好地圍堵失敗的團隊。


Big Hat Group 協助企業在安全的 AzureWindows 365 環境中部署 AI 代理程式 — 從治理框架與 AI 安全審查管線,到爆炸半徑架構。聯絡我們以討論這些企業 AI 諮詢能力如何契合您的組織。