AI 寫的程式碼，四分之一藏著弱點：該怎麼驗？

2026-06-12 13:30:00 AI 資安與企業規範

「AI 寫的程式碼，不是應該比人寫的更標準、更安全嗎？」

這是我在企業內訓最常被問的問題之一。我的回答常讓現場安靜幾秒：2023 年針對 GitHub Copilot 真實專案的大規模分析發現，依語言不同，約 25% 到 33% 的 AI 生成程式碼含潛在安全弱點，包括命令注入、跨站腳本這類高嚴重度類型。四分之一，不是邊角案例，是常態。

Addy Osmani 在《Beyond Vibe Coding》第三部「Trust and Autonomy」用兩章處理這件事。他的解釋很重要：AI 不是故意寫出爛程式碼，它從海量公開程式碼學來，好壞習慣都有；你沒特別要求，它就可能把不安全的寫法原樣端給你。

更麻煩的是心理面。2022 年史丹佛的研究發現：用 AI 助手寫程式的人，對安全性的信心更高，寫出來的卻更不安全。自信上升、警覺下降——做資安的人都知道，這是最危險的組合。這篇把書裡的弱點型態、驗證方法與信任邊界，整理成可以直接拿去用的版本。

這篇文章整理了 AI 生成程式碼的六種常見弱點型態、三層驗證防線與 code review 紅旗清單。適合正在用 AI 寫程式、卻不確定該怎麼驗證安全性的人閱讀。

六種最常見的弱點型態

書中列的常見弱點，我整理成六類。就算看不懂程式碼，認得型態也能問出對的問題：

寫死的金鑰與密碼:AI 可能把 API 金鑰、密碼直接寫進程式碼，程式碼一被分享，鑰匙就跟著外流。看到類似 api_key = "ABC123" 就是警報。
沒有參數化的資料庫查詢:AI 用字串拼接組查詢語句，讓使用者的輸入有機會變成指令——經典的 SQL injection。
太貼心的錯誤訊息：這是我上課必講的例子：登入失敗時，AI 傾向回覆「查無此帳號」或「密碼錯誤」——對使用者貼心，對攻擊者更貼心，因為這等於確認了哪些帳號存在，可以先蒐集再集中破解。安全的寫法是一律回「帳號或密碼錯誤」。同理，把內部錯誤細節吐給使用者，等於發地圖給攻擊者。
不安全的預設值：沒指定就用 HTTP、跳過憑證驗證、跨來源全開、用已淘汰的演算法存密碼。AI 選的是「方便」，不是「安全」。
授權邏輯缺角:AI 做得出「能登入」的系統，但常忘了檢查「這個人有沒有資格做這件事」——例如任何登入者都能刪別人的資料。這種邏輯洞，自動工具最難掃。
套件幻覺:AI 推薦的函式庫可能不存在或已無人維護；更狠的攻擊是有心人先註冊「AI 常幻覺的套件名」放進惡意程式碼等你安裝。裝套件前，先確認它存在、還活著。

驗的方法：三層防線

認得弱點之後，第八章給了驗證做法。我整理成三層，由便宜到貴：

第一層：自動掃描。靜態分析工具（像 Semgrep、CodeQL，或各語言的安全 linter）能抓出明顯型態：明文密碼比對、未參數化的查詢、弱加密。抓不到全部，但能先撈掉低級錯誤，還能排進每次提交的自動流程。

第二層：AI 互審。請 AI 檢查 AI：請同一個模型切換立場「檢查這段程式碼的安全弱點並解釋」，或把程式碼貼給另一家的模型審——不同模型的盲區不同，常能互相抓漏。書裡的定位很清楚：這是額外防線，不是安全認證。

第三層：人工檢核表。核心是追蹤資料的進出：資料進入系統的每個地方有沒有驗證？離開的每個地方有沒有淨化？金鑰放在哪？外部服務掛掉會怎樣？關鍵功能再補「安全測試」：驗證未授權的人真的拿不到資料、惡意輸入真的被擋下。

再加兩個提醒。訓練截止：模型的安全知識凍結在訓練那一刻，之後的漏洞它不知道，提示詞要主動餵現行標準，例如「依照最新版 OWASP Top 10 處理」。慢下來：產出越快，待稽核的表面積越大，越要刻意安排審查時間。

流程總覽

flowchart TD A["AI 產出程式碼"] --> B["第一層:自動安全掃描"] B --> C["第二層:AI 互審(換一個模型)"] C --> D["第三層:人工檢核資料進出點"] D --> E{"每一段都能解釋?"} E -->|否| F["請 AI 解釋或重寫"] F --> D E -->|是| G["補安全測試再合併"] G --> H{"碰真實資料或對外服務?"} H -->|是| I["找懂資安的人最後把關"] H -->|否| J["小步上線，保留回滾"] I --> J

我的經驗：我重建 pbtw.tw 後把第二層變成固定習慣：每次較大的改動，開一個乾淨對話請 AI 當審查員專門挑毛病。它抓到的問題不見得都嚴重，但「有一道流程必經」本身，就擋掉了「趕著上線就算了」的僥倖。

Code review 的紅旗清單

審查 AI 程式碼時，有四面紅旗最值得記住：

「測試都過了」被當成「正確」:AI 的測試可能跟它的程式碼錯在同一個地方。AI 寫的測試也是建議，不是標準答案。
一次合併一大包:AI 產出快，人就容易積一大坨再審。書的建議相反：小步、頻繁提交，十個小變更比一個巨型變更好審得多。
解釋不出來的程式碼：問「這段為什麼這樣寫」，如果答案接近「AI 寫的，應該沒問題」，停下來。團隊必須理解程式碼庫的每一段——這是全書的底線，我在原型到生產那篇也寫過。
過度自信的語氣:AI 說「已完成並通過測試」的篤定程度，跟事實無關。把語氣和證據分開看。

信任邊界：當 AI 從「建議」變成「動手」

第十章把問題推進一步：自主背景代理(autonomous agents)不只建議程式碼，它能直接讀寫你的程式碼庫、執行指令、自己做完變更等你合併。書中的比喻是副駕駛與自動駕駛的差別——而自動駕駛改寫了信任模型。

三個新風險值得認識。一，連貫的錯誤：代理一旦在開頭誤解需求，會把錯誤一路貫徹到底，做出「內部完全一致、整體答非所問」的成品，審起來比零散錯誤更費力。二，審查瓶頸被放大：代理可以一夜生出多個大型變更，書裡形容審那些東西像考古。三，資安上最關鍵：代理本身是新的攻擊面。被誤導或入侵的代理會直接提交、甚至部署；如果它會讀外部內容，還可能被藏在內容裡的指令操弄——手法見〈Prompt Injection 白話文〉。

書裡的原則是「信任但驗證」，我翻成三條線：權限上，代理只碰任務需要的範圍，在隔離環境跑，不碰正式系統；流程上，產出一律走審查，人看過才合併；範圍上，適合代理的任務（目標明確、可驗證、影響可控）和不適合的（架構決策、模糊需求、敏感資料）分清楚。

我自己的判斷基準更簡單：會議成本計算機那種不碰真實資料、不連內部系統的小工具，信任邊界可以畫得很鬆；但只要工具開始想「自動讀取真實名單」「串接內部系統」，性質就變了，三層防線一層都不能省。個人的判斷，接下來要變成組織的規範——這部分我在〈Vibe Coding 資安指南〉寫過 HR 與 IT 的版本。

常見問題

問：我完全看不懂程式碼，這套驗法跟我有關嗎？
答：有。第一、二層你都做得到：掃描工具多半免費，AI 互審只是複製貼上加一句提示詞。做不到的是最後的人工把關——所以重點是知道何時該找人：碰真實個資、對外服務、串接公司系統的時候。

問：用最新最強的模型，弱點會不會少很多？
答：會少，但不會歸零。模型再強也受訓練截止限制；授權邏輯這類「要懂你的業務才會對」的問題，跟模型強弱無關。驗證流程是常數，模型是變數。

問：請生成程式碼的同一個 AI 檢查自己，算數嗎？
答：有用，書裡也推薦。但它有共同盲區，跨模型互審效果更好——而且兩者都只是輸入，不是放行章。

問：小工具也要全套三層嗎？
答：看碰不碰真實資料、有沒有別人用。兩個都沒有，第一層加「自己看得懂」就夠；任何一個成立，至少做到資料進出檢核；兩個都成立，全套，並考慮找人把關。

AI 把寫程式的門檻降到歷史新低，但安全的門檻一公分都沒降——只是從「會不會寫」變成「會不會驗」。如果你的團隊正面對員工自建工具、導入 AI 開發的治理問題，我的企業 AI 資安課程教的就是把這套驗證流程與信任邊界，變成組織的制度。

這篇文章萃取自我的筆記〈書摘筆記|Beyond Vibe Coding(Addy Osmani)〉(/note-beyond-vibe-coding-osmani/)

#AI 資安 #Vibe Coding #程式碼審查 #AI 代理