AI 打造的程式碼真的安全嗎？建置者常見問答

幾乎每一次的導入通話中，我都會收到某種版本的這個問題，通常問得很小心，好像提問的人已經半預期會被說服不用擔心。他們不該被說服。安全性是少數幾個「保持適度偏執」恰到好處的領域之一——不論程式碼是人類還是模型寫的都一樣。以下是我實際被問到的問題，並盡量給出最直接的答案。

AI 寫的程式碼會比人類寫的更不安全嗎？

平均而言，且若不加以檢查，答案是——是的，稍微會。幾年前史丹佛的一項研究（Perry et al.，常被引用為第一個真正探討此議題的研究）發現，使用 AI 程式碼助手的開發者所產出的程式碼安全性比對照組更差——而更讓人擔心的是——他們對自己程式碼安全性的評分反而更高。信心提升了，品質卻下降了。Veracode 較近期的 GenAI 程式碼安全掃描也給出了具體數字：他們測試的 AI 生成程式碼樣本中，大約有四成引入了至少一個可被利用的缺陷，通常是些平常的問題，比如缺少輸入檢查或使用了弱預設值。這並不代表 AI 寫的程式碼注定不安全。這代表未經審查的 AI 程式碼，風險與未經審查的人類程式碼相同，而「未經審查」正是危險真正存在之處。一個寫程式很快又從不被檢查的模型，會犯下跟週五下午趕工的新手工程師一樣的錯誤——只是速度更快、數量更多。

我的 API 金鑰和機密資料會發生什麼事？

這是我真的會睡不著的一點，因為這種錯誤在發生之前根本看不出來。它的發生方式並不戲劇化——不會有電影裡那種伺服器被駭的場景。而是一把金鑰被貼到聊天視窗裡，被回顯進生成的檔案中，被提交進版本庫，然後六個月後，有人出於好奇對這個版本庫跑了機密掃描工具，才發現它一直以明文形式安靜地躺在裡面。在這個平台上，機密資料完全不會出現在生成的原始碼中——它們是在執行時從加密儲存空間注入，並限定於你的租戶範圍內，建構代理也被指示只能以名稱引用機密資料，絕不使用實際值。但如果你是在別處建構，或是在任何工具的聊天視窗中直接貼上憑證，就應該假設這段文字現在已經存在於某個訓練相關的日誌中，除非該供應商明確表示並非如此。原則上，任何你曾經打進聊天視窗的東西，一測試完就該立刻輪替更換。

有人能透過提示（prompt）駭進我的網站嗎，像是提示注入攻擊？

這裡有兩件不同的事常被混為一談，而這個區別很重要。針對建構器的提示注入——也就是有人誘騙正在建構你應用程式的 AI 去做你並未要求的事——是一個真實且已被研究過的風險，這也是為什麼建構代理只擁有範圍受限的工具權限，而非完整的 shell 存取權，也是為什麼任何涉及檔案系統或部署流程的操作，都會經過一份你日後可稽核的明確操作紀錄。而針對你上線後的應用程式的提示注入則是另一個獨立的問題，只有在你的應用程式本身在執行時嵌入了 LLM 時才適用——例如客服聊天機器人、AI 搜尋功能等。如果有的話，就要把任何使用者能輸入的文字視為對該模型而言不可信任的輸入，就像你會把它視為對 SQL 查詢而言不可信任的輸入一樣。這個規則本身並不新，新的只是這次是哪個系統在解析這段字串。

建構器在發布程式碼之前，會自行檢查漏洞嗎？

自動化檢查能可靠地抓出那些常見又枯燥的問題：寫死在程式碼中的機密資料、明顯需要驗證卻缺少驗證的端點、用字串拼接而非參數化方式建構的 SQL，以及有已知 CVE 的依賴套件。但它們不擅長抓出的，是業務邏輯上的漏洞——那種每一行程式碼單獨看都沒問題，漏洞卻藏在兩個功能之間沒人想到要一起檢查的縫隙裡。例如折扣碼可以無限疊加推薦獎金，或是密碼重設流程洩漏了某個電子郵件是否存在於系統中。這類問題需要真正理解這個應用程式是做什麼用的的人才能發現，而不只是理解程式碼做了什麼——目前無論是不是 AI，還沒有任何掃描工具能可靠地找出這些問題。自動化審查是底線，不是上限。

它安裝的第三方套件呢？這算是供應鏈風險嗎？

是的，而且老實說，這比 AI 撰寫的程式碼本身還更是一個真實世界的風險。大多數應用程式按程式碼行數計算，有 80% 到 95% 都是依賴套件；建構器所寫的程式碼，只是架在 npm、PyPI 或其他生態系統之上的一層薄薄的膠合層。一個惡意或被劫持的套件，無論是誰或什麼東西寫了周圍的膠合程式碼，都能讓你陷入危險——可以看看 event-stream 和 colors.js 事件，了解這在現實中會如何發生。緩解方式其實很枯燥卻很有效：釘住版本號而不是追蹤最新版、優先選擇有真正維護紀錄的套件而非上週才發布的套件，並將依賴套件稽核（`npm audit`、`pip-audit`，或任何適合你技術堆疊的工具）當作一項持續的習慣，而不是上線前做一次就好的步驟。

如果發生資料外洩，誰要負責？

幾乎在法律上都是你——如果那是你的應用程式，也是你客戶的資料。這常讓人意外，因為有些人以為「AI 寫的」會把責任轉移到別處。它不會，就像僱用承包商並不會把建築法規違規的責任從屋主身上移開一樣。平台會對自己所控制的基礎設施負責：機密資料如何儲存、租戶資料如何隔離、託管層本身是否有更新修補。但你所指定的應用程式邏輯、你選擇蒐集的資料，以及你提供給使用者的條款，都是屬於你的責任。如果你正在處理任何敏感資訊——付款細節、健康資訊，或任何受 GDPR 或 CCPA 規範的內容——請去閱讀你所使用平台實際的資料處理協議，而不要假設「由 AI 建構」代表某種額外的法律保障層。它並不代表這個意思。

有位創辦人曾半開玩笑地告訴我，她比較信任 AI 寫的程式碼勝過自己寫的，因為「至少它凌晨兩點不會累」。也許吧。但疲憊的人類通常知道自己累了。AI 不會意識到自己剛剛犯了錯，不論程式碼是完美無瑕還是漏洞百出，它都會用完全相同、充滿自信的語氣告訴你程式碼已經完成了。信心並不是安全性的訊號，不論來源是人還是 AI。

我上線前該不該花錢做一次真正的安全稽核？

如果你需要收款、儲存任何監管機構會認定為個資（PII）的資料，或是要為某個日後也會要求 SOC 2 報告的企業客戶建構產品——那就該做，而且別讓成本打消你的念頭。針對小型應用程式的一次聚焦稽核，依範圍不同，費用大約落在幾百到幾千美元之間，相較於一封資料外洩通知信的成本來說算便宜。如果你在做的是興趣專案、內部工具，或是沒有真正使用者資料涉及風險的東西，付費稽核就有點過頭了；改用免費又便宜的層級就好——依賴套件掃描、手動走一遍每一個驗證邊界（使用者 A 能不能透過修改網址看到使用者 B 的資料？），以及找第二雙人類的眼睛檢查任何涉及金錢或密碼的部分。

人們最常犯的安全性錯誤是什麼？通常什麼時候發生？

不是在上線當下，而是在三個月後，當應用程式正常運作、也沒人再去關注它的時候。可能是一個沒有防護的管理路由，因為它一直以來只被建構它的那個人以自己的身分登入測試過。可能是一個在正式環境中會回傳完整堆疊追蹤資訊的除錯端點。可能是一個原本「只是用來測試」、後來卻從未輪替更換的資料庫預設密碼。這些都不是什麼罕見的問題。它們就等同於因為當時很趕而把備用鑰匙放在門墊下，之後就忘了這件事。解方不是更好的工具，而是一個五分鐘的習慣：每個月花五分鐘，先以攻擊者的角度看看你的應用程式，再以驕傲的建構者角度去看它。