三月一個月就爆出 35 個 AI 程式碼 CVE：喬治亞理工追蹤「Vibe Coding 資安雷達」的警訊

三月單月 35 個 CVE，AI 生成程式碼的漏洞正在加速累積

如果您手上有一個「AI 幫忙寫的系統」正準備上線,最近有一組數字您一定要看:

喬治亞理工學院系統軟體與資安實驗室 (SSLab) 從 2025 年 5 月開始追蹤「Vibe Security Radar」專案,專門記錄直接來自 AI 生成程式碼的 CVE 漏洞 (Common Vulnerabilities and Exposures)。2026 年 1 月有 6 個,2 月 15 個,到了 3 月——單月就爆出 35 個。

這不是「AI 會犯錯」的老生常談,而是一個可量化、正在加速的資安債務。如果您的系統是用 Claude、Cursor、Copilot 這類工具「vibe coding」出來的,這些數字代表的風險,很可能已經藏在您的程式碼裡。

為什麼 AI 生成的程式碼特別容易出包?

根據多項 2026 年的研究數據,AI 生成的程式碼有幾個結構性的弱點:

• 安全漏洞發生率是人工的 1.57 倍,其中跨站腳本攻擊 (XSS) 的風險更高達 2.74 倍
• 邏輯錯誤與正確性問題比人工多 1.75 倍
• 41% 的 AI 生成後端程式碼會設定過於寬鬆的權限,讓攻擊面大幅擴張
• 67% 的開發者回報除錯時間增加,因為 AI 生成的程式碼需要更深入的人工檢查

更麻煩的是,這些漏洞不一定在開發階段就會被發現。Veracode 的 2026 年報告指出,82% 的組織都背負著「資安債」 (security debt),比去年的 74% 還高。AI 工具讓開發速度變快了,但資安檢查的速度跟不上,結果就是漏洞在系統裡靜靜累積,直到上線後才爆發。

如果您手上有 AI 寫的系統,上線前可以做什麼?

這不代表 AI 工具不能用,而是您需要把「AI 生成的程式碼」當成「資淺工程師寫的初稿」來對待——它需要審查、測試、加固,才能安全上線。

以下是實務上可以採取的三個步驟:

1. 自動化資安掃描,不要只靠人工 code review

靜態應用程式安全測試 (SAST) 和軟體組成分析 (SCA) 工具可以在程式碼送交 (commit) 的當下就抓出已知漏洞。如果您的系統是外包或 AI 生成的,這一層防護是最低成本、最快見效的做法。

許多工具 (如 Snyk、Checkmarx、GitLab Ultimate) 都能整合進 GitHub / GitLab 的 pull request 流程,讓資安檢查變成「自動擋的關卡」,而不是「事後才想起來的待辦事項」。

2. 把權限設定和 API 串接當成重點檢查項目

AI 生成的程式碼有個常見問題:為了「先跑起來」,權限會設得很寬鬆。例如資料庫帳號給了 admin 權限、API token 沒有時效限制、使用者角色沒有細分。

上線前,請您或您的技術顧問特別檢查:

• 資料庫帳號是否只有「需要的最小權限」?
• API 金鑰是否有設定過期時間和 IP 白名單?
• 使用者角色是否有明確區分 (例如一般使用者 vs. 管理員)?

3. 如果系統是外包或前任工程師留下的,請找人做一次「程式碼健診」

如果您手上的系統是:

• 外包廠商做到一半就失聯的
• 前任工程師用 AI 工具快速拼湊出來的
• 您自己用 ChatGPT / Cursor「邊學邊做」完成的

那麼上線前,最划算的投資就是找一位有資安經驗的技術顧問,做一次完整的程式碼審查 (code audit)。這不是要挑毛病,而是讓您在正式上線前,知道「哪裡有雷」、「哪些是可以先上線再慢慢修的」、「哪些是絕對不能帶到正式環境的資安漏洞」。

這筆錢,通常比系統上線後被駭、資料外洩、商譽受損的代價低得多。

速度很重要,但上線後不出包更重要

AI 工具讓開發變快了,這是好事。但如果速度換來的是「上線後才發現系統有洞」、「客戶資料被竊取」、「系統被植入後門」,那這個速度就不值得了。

喬治亞理工的「Vibe Security Radar」專案之所以重要,是因為它把「AI 生成程式碼的資安風險」從抽象的擔憂,變成了可追蹤、可量化的數據。三月單月 35 個 CVE,不是恐嚇,而是提醒:如果您的系統裡有 AI 寫的程式碼,上線前做一次完整的資安檢查,是責任,也是自保。

──

需要有人幫您看一下手上的系統嗎?
AI 上線專家專門協助台灣中小企業主把「想上線但不確定安不安全」的系統,透過程式碼健診、資安加固、上線前檢查清單,安穩送到正式環境。免費健診申請 →