AI 程式開發的資安風險與防護——台灣開發者必讀的安全指南
AI 程式工具的資安風險與防護實踐——程式碼外洩、不安全生成碼、供應鏈攻擊的應對策略，含企業導入安全框架。
「把公司的程式碼交給 AI，安全嗎？」
這是台灣開發者在導入 AI 程式工具時最常問的問題。不管是 Claude Code、Cursor、GitHub Copilot 還是 OpenClaw——只要 AI 能讀取你的程式碼，資安就是繞不開的話題。
iThome 過去一年的報導中，AI 工具相關的資安事件是最密集的主題之一。從三星員工將機密程式碼貼進 ChatGPT，到研究人員發現 AI 生成的程式碼含有已知漏洞——這些不是假設性的風險，是已經發生的事。
這篇指南整理 AI 程式開發的三大資安風險類型，以及對應的防護實踐。不是要嚇你不用 AI，而是讓你用得安心。
AI 程式工具的三大資安風險
在深入每個風險之前，先看全貌：
| 風險類型 | 嚴重程度 | 發生頻率 | 主要影響 |
|---|---|---|---|
| 程式碼與機密資料外洩 | 高 | 中 | 智慧財產權、客戶資料 |
| AI 生成不安全程式碼 | 中-高 | 高 | 應用程式漏洞 |
| 供應鏈與依賴套件風險 | 高 | 低 | 系統被入侵 |
三個風險的性質不同，防護策略也不同。逐一說明。
風險一：程式碼與機密資料外洩
問題本質
當你使用 AI 程式工具時，你的程式碼會被傳送到模型供應商的伺服器。這意味著：
- 你的專有演算法、商業邏輯可能被第三方存取
- 程式碼中硬編碼的 API key、資料庫密碼可能被暴露
- 客戶資料（如果出現在程式碼或測試資料中）可能外洩
真實案例
2023 年，三星半導體部門的工程師將內部程式碼貼進 ChatGPT 請求除錯協助，導致機密原始碼外洩。三星隨後全面禁止員工使用生成式 AI 工具。
這不是個案。任何將程式碼傳送到外部 API 的工具都有這個風險——包括 Claude Code、Copilot、Cursor。
風險程度評估
不同使用方式的風險不同：
| 使用方式 | 資料傳輸 | 風險等級 |
|---|---|---|
| API 呼叫（Claude Code、OpenClaw） | 程式碼傳到模型供應商 | 中 |
| 雲端 IDE（Cursor） | 程式碼傳到服務供應商 | 中 |
| 本地模型（Ollama + 開源模型） | 不傳出 | 低 |
| 網頁聊天（手動貼程式碼） | 可能被用於訓練 | 高 |
防護措施
1. 確認資料使用政策
Anthropic（Claude Code）明確表示 API 呼叫的資料不會用於模型訓練。但你應該自己確認每個工具的政策：
- Anthropic API：不用於訓練（需確認最新條款）
- OpenAI API：不用於訓練（需確認最新條款）
- 免費版網頁聊天：可能用於訓練
2. 不要在程式碼中硬編碼機密
這本來就是基本功，但 AI 工具讓它變得更重要：
# 錯誤：機密寫在程式碼裡
DB_PASSWORD = "super_secret_123"
# 正確：用環境變數
DB_PASSWORD = os.environ.get("DB_PASSWORD")
3. 使用 .gitignore 和 .claudeignore
Claude Code 支援 .claudeignore 檔案，語法跟 .gitignore 一樣。把敏感檔案排除在 AI 的讀取範圍外：
# .claudeignore
.env
.env.*
credentials/
secrets/
*.pem
*.key
4. 權限控制
Claude Code 預設在執行任何檔案操作前都會詢問你。不要為了方便把所有操作設成自動接受——特別是在處理敏感專案時。
風險二：AI 生成不安全的程式碼
問題本質
AI 模型是從大量開源程式碼中學習的。這些程式碼中有很多包含安全漏洞。AI 可能會生成看起來正確、但實際上有安全問題的程式碼。
常見的生成漏洞類型
SQL Injection
# AI 可能生成這樣的程式碼
query = f"SELECT * FROM users WHERE id = {user_id}"
# 安全的寫法
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_id,))
XSS（跨站腳本攻擊）
// AI 可能生成這樣的程式碼
element.innerHTML = userInput;
// 安全的寫法
element.textContent = userInput;
不安全的密碼學
# AI 可能生成這樣的程式碼
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()
# 安全的寫法
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
硬編碼的預設值
// AI 可能生成帶有不安全預設值的程式碼
const corsOptions = {
origin: '*', // 允許所有來源——不安全
credentials: true
};
防護措施
1. 永遠審查 AI 生成的程式碼
這是最重要的一條。AI 生成的程式碼不是「正確答案」，是「草稿」。特別注意：
- 輸入驗證和消毒
- 認證和授權邏輯
- 密碼學相關程式碼
- CORS 和安全標頭設定
- 檔案上傳處理
2. 在 CLAUDE.md 中加入安全規範
## 安全規範
- 所有 SQL 查詢必須使用參數化查詢
- 使用者輸入必須經過驗證和消毒
- 密碼雜湊使用 bcrypt，不用 MD5 或 SHA
- CORS 設定必須指定允許的來源，不用 *
- API endpoint 必須有認證和授權檢查
把安全規範寫進 CLAUDE.md，AI 在生成程式碼時就會遵守這些規則。
3. 使用靜態分析工具
AI 生成程式碼後，用自動化工具掃描：
# JavaScript/TypeScript
npx eslint --ext .ts,.js src/ --rule 'no-eval: error'
# Python
bandit -r src/
# 通用依賴漏洞掃描
npm audit
pip-audit
4. 安全測試
對 AI 生成的程式碼跑安全測試，特別是處理使用者輸入的部分：
# OWASP ZAP 自動化掃描
zap-cli quick-scan http://localhost:3000
# 或用 AI 本身來做安全審查
> 幫我檢查 src/api/auth.ts 有沒有 OWASP Top 10 的安全漏洞
風險三：供應鏈與依賴套件風險
問題本質
AI 可能建議你安裝不存在的套件（幻覺），或者建議過時、有已知漏洞的套件版本。攻擊者已經開始利用這個特性——在 npm 或 PyPI 上註冊 AI 常見幻覺的套件名稱，植入惡意程式碼。
防護措施
1. 驗證套件是否存在且可信
AI 建議安裝任何套件時，先確認：
- 套件在 npm/PyPI 上確實存在
- 有合理的下載量和維護歷史
- 最近有更新（不是被棄用的套件）
- GitHub repo 有合理的 star 數和 contributor
2. 鎖定版本
// package.json — 用精確版本，不用 ^
{
"dependencies": {
"express": "4.18.2",
"prisma": "5.10.0"
}
}
3. 定期掃描依賴
# npm
npm audit
# Python
pip-audit
# 自動化：GitHub Dependabot 或 Snyk
防護最佳實踐：完整檢查清單
把上面的防護措施整理成一份可執行的檢查清單：
每日開發
- 不在程式碼中硬編碼任何機密
- AI 生成的程式碼經過人工審查才 commit
- 處理使用者輸入的程式碼特別注意安全
- 新安裝的套件先驗證來源和可信度
專案設定（一次性）
- 建立
.claudeignore排除敏感檔案 - 在 CLAUDE.md 中加入安全規範
- 設定 ESLint/Bandit 等靜態分析工具
- 啟用
npm audit/pip-audit自動掃描
多專案安全隔離
如果你同時處理多個專案——特別是不同客戶的專案——隔離是關鍵。你不希望客戶 A 的 API key 出現在客戶 B 的對話脈絡中。
檔案系統層面，每個專案有自己的目錄和 .env。AI 脈絡層面，每個專案應該有自己的隔離空間。MemClaw 的工作區設計就是為了解決這個問題——每個專案一個獨立工作區，脈絡完全隔離，不會有跨專案的資訊洩漏。
用工作區隔離保護多專案安全 → memclaw.me
企業環境
- 制定 AI 工具使用政策（允許/禁止的場景）
- 確認供應商的資料使用政策和合規認證
- 建立程式碼審查流程（AI 生成的程式碼需要人工 review）
- 定期安全稽核
企業導入的安全框架
如果你是技術主管，正在評估是否讓團隊使用 AI 程式工具，以下是一個分階段的安全框架：
第一階段：評估與政策
- 盤點現有風險：團隊目前是否已經在用 AI 工具？（很可能是的，即使沒有正式導入）
- 制定使用政策：哪些場景允許、哪些禁止
- 選擇工具：優先選擇有明確資料政策的工具（API 模式優於免費網頁版）
第二階段：受控導入
- 從非敏感專案開始：內部工具、文件生成、測試程式碼
- 建立安全護欄：
.claudeignore、CLAUDE.md 安全規範、靜態分析 - 培訓團隊：AI 生成程式碼的安全審查要點
第三階段：擴大使用
- 逐步開放到核心專案：有了經驗和流程後再擴大
- 自動化安全檢查：CI/CD 中加入安全掃描
- 定期回顧：每季檢視安全事件和政策調整
想了解更完整的企業 AI 工具導入流程，可以參考 內鏈: 技術主管的 AI 工具導入指南——從評估到落地的完整框架。
常見問題
Claude Code 會把我的程式碼拿去訓練嗎？
根據 Anthropic 的 API 使用條款，透過 API 傳送的資料不會用於模型訓練。Claude Code 使用的是 API 模式。但條款可能更新，建議定期確認最新版本。
本地模型（如 Ollama）是不是更安全？
從資料外洩的角度來說，是的——程式碼不會離開你的電腦。但本地模型的能力通常不如雲端模型，而且「生成不安全程式碼」的風險依然存在。安全不只是資料傳輸的問題。
台灣有相關法規嗎？
台灣的《個人資料保護法》適用於 AI 工具處理個資的場景。如果你的程式碼或測試資料中包含客戶個資，使用 AI 工具時需要特別注意合規。金融業和醫療業有更嚴格的規範。
完全不用 AI 工具是不是最安全的？
從資安角度來說，不用確實消除了 AI 相關的風險。但這也意味著放棄了生產力提升。更務實的做法是：了解風險、建立防護、在可控的範圍內使用。
總結
AI 程式工具的資安風險是真實的，但也是可管理的。關鍵在三件事：
- 知道風險在哪——程式碼外洩、不安全生成碼、供應鏈攻擊
- 建立防護——
.claudeignore、安全規範、程式碼審查、靜態分析 - 隔離環境——不同專案的脈絡不混在一起
不是不用 AI，是用對方法。
從這裡開始：
- 在你的專案中建立
.claudeignore和安全規範 - 安裝 MemClaw 確保多專案脈絡隔離——免費開始
- 把本文的檢查清單加到你的開發流程中
延伸閱讀：