AI 的資安漏洞：為什麼它寫出有破口的碼
更糟的是，當開發者試圖補上安全需求時，往往因為不熟悉而描述得模糊。例如「幫我加上防止 SQL 注入」這樣的提示，AI 可能只回你一段「把單引號替換掉」的程式碼，而這根本不是正解（正確做法是參數化查詢）。安全需求本身的複雜性與專業性，讓它很難被濃縮成一句自然的提示詞，於是 AI 只能摸著石頭過河。
原因五：開發者的過度信任與「自動完成慣性」
最後一個原因，也是最容易被忽略的：人。當 AI 的建議愈來愈像樣，開發者的審查意願就愈來愈低。心理學上這稱為「自動化偏誤」（automation bias）——人類傾向於信任自動化系統的輸出，尤其在系統多數時候都正確的情況下。
於是我們看到一種普遍的「自動完成慣性」：開發者按下 Tab 接受建議、按下 Enter 提交程式碼，卻沒有真正讀過那幾行程式碼。更有甚者，在 AI 生成測試並顯示「全部通過」後，便認為程式碼沒問題。問題是，AI 寫的測試往往只測「正常路徑」，不測「攻擊路徑」。一段有 SQL 注入的程式碼，配上只測正常輸入的測試，當然會全部通過。這種「自我驗證的假象」，是 AI 寫碼最危險的地方之一。
三、AI 最常寫出的破口類型：常見漏洞盤點
理解了成因，接著我們把鏡頭拉近，看看 AI 到底最常寫出哪些型態的漏洞。以下依照 OWASP Top 10 的分類，整理出幾個最具代表性的類別。
注入攻擊類（SQL Injection、Command Injection）
這是 AI 最常「踩雷」的類別。原因很簡單：字串拼接的寫法在訓練資料中太常見了。當你請 AI 寫「查詢資料庫」或「執行系統指令」的程式碼時，它有相當高的機率給你字串拼接的版本，而不是參數化查詢或安全 API。除了 SQL 注入，Command Injection 同樣常見：AI 可能寫出 os.system("ping " + user_input) 這樣的程式碼，讓攻擊者有機會注入 ; rm -rf / 之類的指令。這類漏洞的修補方式其實很成熟——參數化查詢、預編譯語句、避免拼接 shell 指令——但 AI 不會主動採用，除非你明確要求。
認證與授權的錯置（Broken Access Control）
AI 在處理「誰能做什麼」這類邏輯時，經常只實作「認證」（你是誰），卻漏掉「授權」（你能做什麼）。例如它可能寫出一個需要登入才能存取的 API，卻沒有檢查「這個使用者是否有權限修改這筆資料」。這在實務上就是所謂的 IDOR（Insecure Direct Object Reference）漏洞：攻擊者只要把 URL 裡的 /order/123 改成 /order/124，就能看到別人的訂單。AI 生成的程式碼之所以常有這類問題，是因為「檢查擁有者」這個步驟在訓練資料中經常被省略，而 AI 也就理所當然地漏掉了。
金鑰與敏感資訊的硬編碼
另一個高頻問題，是把 API Key、資料庫密碼、JWT Secret 直接寫死在程式碼裡。AI 非常擅長「讓程式碼能跑」，而寫死金鑰正是讓程式碼能跑最快的方式。於是它可能給你一段 const stripe = require('stripe')('sk_live_xxxxx') 的範例，而你如果沒有警覺，這把金鑰就會跟著程式碼一起進到 Git 版本控制裡。一旦 repo 外流或被公開，損失將難以估計。這類漏洞的可怕之處在於「寫起來毫無感覺」，但後果往往是災難性的。
依賴套件與供應鏈風險
AI 在建議套件時，傾向推薦「常見的」套件，這本身無可厚非。但問題在於，它有時會「幻覺」出不存在的套件名稱，或者建議使用已經停止維護、存在已知漏洞的舊版套件。前者可能被攻擊者利用，透過「搶註冊」惡意套件名稱來進行供應鏈攻擊（這被稱為 slopsquatting）；後者則讓專案直接繼承了舊套件的所有已知 CVE。當開發者不加思索地照著 AI 的建議安裝套件，等於把專案的安全性外包給了一台不會查 CVE 資料庫的機器。
輸入驗證與輸出編碼的疏漏
XSS、SSRF、路徑穿越、開放重定向……這些漏洞的共同根源，都是「沒有對輸入做驗證」或「沒有對輸出做編碼」。AI 生成的程式碼往往假設「使用者會乖乖輸入正常資料」，於是漏掉長度限制、型別檢查、特殊字元過濾、HTML 編碼等步驟。特別是在前後端都使用 AI 生成的專案裡，這種「兩邊都不驗」的情況尤其危險。
四、從流程面補洞：讓 AI 寫碼「安全左移」
知道問題在哪，接下來要談解法。核心觀念只有一個：不要期待 AI 自己變安全，而是要把安全機制嵌入整個開發流程。這就是所謂的「安全左移」（Shift Left Security）——在程式碼還沒進到生產環境之前，就把漏洞攔下來。
提示工程之外：把安全規則寫進 AI 的使用規範
很多人以為「只要提示詞寫得好，AI 就會寫出安全的程式碼」，這個想法只對了一半。好的提示詞確實有幫助——例如明確要求「使用參數化查詢」、「密碼使用 bcrypt」、「所有輸入都要驗證」——但提示詞的效果不穩定，而且每個開發者的提示品質參差不齊。
更可靠的做法，是建立團隊層級的「AI 使用規範」。具體而言，可以在專案根目錄放一份給 AI 讀的規則檔（例如 .cursorrules、copilot-instructions.md 或類似的機制），把團隊的安全底線寫進去：禁止字串拼接 SQL、禁止硬編碼金鑰、所有對外 API 必須驗證授權、密碼雜湊必須使用指定演算法等。這樣一來，AI 在生成程式碼時就會把這些規則納入上下文，而不必依賴每個開發者記得在提示裡補上。
靜態掃描與 AI 的協作：SAST、SCA、Secret Scanning
再怎麼小心，AI 還是可能寫出漏洞，所以第二道防線是自動化掃描。這裡有三類工具特別重要：
SAST（靜態應用程式安全測試）：直接掃描原始碼，找出注入、XSS、破損存取控制等問題。工具如 Semgrep、SonarQube、CodeQL 都支援在 CI 流程中自動執行。把它們接進 PR 檢查，AI 寫的程式碼就多了一層把關。
SCA（軟體組成分析）：掃描專案依賴的套件，比對已知 CVE。工具如 Dependabot、Snyk、Trivy 可以自動偵測「AI 建議安裝的套件」是否有已知漏洞或授權問題。
Secret Scanning（機密掃描）：專門偵測程式碼中是否夾帶金鑰、密碼、Token。GitHub 原生支援，也有 Gitleaks 等開源工具。這對防堵「AI 硬編碼金鑰」特別有效。
這三類工具不是要取代人工審查，而是要把「掃描結果」當成 AI 的第二雙眼睛。許多團隊甚至把掃描結果回饋給 AI，請它根據掃描報告自動修補——這種「AI 寫碼、AI 補洞、人來驗證」的模式，正在成為新一代開發流程的常態。
人機協作的正確姿勢：AI 產碼，人審碼
最後，也是最關鍵的一點：人必須留在迴圈裡。AI 可以是很好的「初稿產生器」，但它不該是最終的「品質守門人」。正確的協作姿勢應該是：
一、由人定義需求與安全邊界；二、由 AI 產出初稿；三、由人逐行審查，特別注意輸入處理、授權檢查、錯誤處理與敏感資訊；四、由自動化工具掃描；五、由人決定是否合併。這個流程看起來比「AI 一鍵生成」麻煩，但它能大幅降低漏洞流入生產環境的機率。
此外，審查時可以特別針對 AI 的「慣性弱點」加強檢查。例如看到字串拼接就停下來問「這是不是該用參數化查詢」；看到 API 路由就問「這裡有沒有檢查授權」；看到設定檔就問「有沒有寫死任何機密」。把這些問題變成團隊的 code review checklist，效果會比單純依賴工具更好。
五、企業與個人的實務建議：建立 AI 寫碼的資安防線
談完觀念與流程，最後給出可落地的實務建議。以下分成「給開發者」與「給企業」兩個層面。
給開發者的建議：
第一，永遠不要「盲按 Tab」。AI 的建議請當成「同事的初稿」，而不是「最終答案」，特別是涉及輸入、授權、金鑰的程式碼，務必逐行讀過。第二，把安全需求寫進提示，例如「請使用參數化查詢，並對輸入做型別與長度驗證」。第三，要求 AI 產出「攻擊路徑」的測試，而不只是正常路徑的測試。第四，養成使用 Secret Scanning 與 SCA 工具的習慣，就算只是個人專案也一樣。第五，遇到 AI 建議的套件，先查詢其維護狀態與已知漏洞，不要直接安裝。
給企業的建議：
第一，制定 AI 輔助開發的資安政策，明確規範哪些程式碼可以由 AI 生成、哪些必須人工撰寫（例如金流、認證、加密相關邏輯）。第二，把 SAST、SCA、Secret Scanning 接進 CI/CD，讓掃描成為合併前的必經關卡。第三，建立團隊層級的 AI 規則檔，把安全底線寫進 AI 的上下文。第四，針對開發者進行「AI 寫碼資安」的教育訓練，讓大家理解 AI 的慣性弱點。第五，定期抽查 AI 生成的程式碼，了解團隊的實際使用狀況與風險分佈。
這些建議看起來不新，但真正落實的團隊並不多。而正是那些「有落實」與「沒落實」之間的差距，決定了 AI 寫碼是提升生產力，還是引入災難。
六、結語：AI 不是資安問題的解方，也不是元兇——關鍵在人
回到文章開頭的問題：AI 為什麼會寫出有破口的碼？答案其實很樸素——因為它的訓練資料充滿不安全的範例、因為它的目標是「像正確」而非「安全」、因為它缺乏專案脈絡、因為安全需求難以被自然語言精確表達、也因為人類太容易信任它。
但這並不代表我們該拒絕 AI 寫碼。相反地，AI 已經證明能大幅提升開發效率，真正的關鍵在於我們怎麼用它。把 AI 當成「不知疲倦但缺乏安全意識的 junior 工程師」，讓它負責產出初稿，由人負責定義邊界、審查品質、把關安全，再搭配自動化掃描工具形成多層防線——這才是負責任的使用方式。
資安從來不是某個工具的責任，而是整個流程的責任。AI 寫出的破口，映照的其實是人類在流程設計上的疏漏。與其問「AI 為什麼不安全」，不如問「我們有沒有建立讓 AI 安全發揮的環境」。當提示規範、審查習慣、掃描工具與團隊文化都到位，AI 就會從「漏洞製造機」變成「生產力放大器」。這條路不輕鬆，但值得每一個擁抱 AI 的團隊認真走完。