AI 供應鏈安全：模型、套件、API 的信任鏈風險

AI 供應鏈跟傳統軟體有什麼不同

傳統軟體的供應鏈風險在於程式碼套件——npm、PyPI、Maven 上的第三方函式庫可能被植入惡意程式碼。AI 專案的供應鏈多了兩個攻擊面：模型檔案和 API 服務。

你下載的預訓練模型可能被動過手腳。你串接的 AI API 服務可能在某天改變了資料處理政策。這些風險跟傳統的程式碼相依性風險疊加在一起，讓 AI 專案的供應鏈安全變得更複雜。

模型供應鏈風險

Hugging Face 上的惡意模型

Hugging Face 是 AI 界的 GitHub，上面有超過百萬個模型。但跟 GitHub 一樣，任何人都可以上傳模型，平台無法逐一審核。

已知的攻擊手法：

Pickle 反序列化攻擊：PyTorch 的 .pt 和 .bin 模型檔案使用 Python 的 pickle 格式儲存。pickle 在載入時會執行任意程式碼。攻擊者可以在模型檔案中植入惡意程式碼，你一載入模型就會被執行。

import torch
model = torch.load("malicious_model.pt")  # 載入的瞬間就可能執行惡意程式碼

後門模型（Backdoored Models）：模型在正常輸入下表現正常，但遇到特定的觸發模式時會產生攻擊者預設的輸出。例如一個文本分類模型，在看到特定的關鍵字組合時固定回傳「安全」，讓惡意內容通過審核。

偽造的熱門模型：攻擊者用跟知名模型相似的名稱上傳惡意模型（typosquatting）。例如 meta-llama/Llama-2-7b 是官方模型，但 meta_llama/Llama-2-7b（底線而非連字號）可能是惡意的。

防護措施：

優先使用 .safetensors 格式的模型檔案。safetensors 只儲存張量資料，不執行程式碼，從根本上防止反序列化攻擊。

from safetensors.torch import load_file
model_weights = load_file("model.safetensors")  # 安全：只載入資料，不執行程式碼

檢查模型來源：只使用官方組織帳號發布的模型。查看模型的下載量、社群評價和更新歷史。

在沙箱環境中載入模型：第一次載入不確定的模型時，用 Docker 容器或虛擬機隔離，監控是否有異常的網路連線或檔案操作。

模型雜湊驗證

下載模型後，比對檔案的雜湊值跟發布者提供的是否一致。

sha256sum model.safetensors
# 比對 Hugging Face 上模型頁面顯示的 SHA256

如果沒有官方的雜湊值可比對，至少在團隊內部記錄你使用的模型版本和雜湊值，確保所有環境用的是同一個模型。

套件供應鏈風險

PyPI 和 npm 上的 AI 相關惡意套件

AI 開發常用的 Python 和 JavaScript 套件生態系都有惡意套件的問題。攻擊者會用跟熱門 AI 套件相似的名稱發布惡意套件。

已發現的案例：

openai-python（正確套件是 openai）：安裝後會竊取環境變數中的 API Key。

langchain-community（正確寫法）vs langchain_community（混淆命名）：不同的命名慣例造成混淆。

pytorch-nightly（正確是 torch）：釣魚套件盜取認證資訊。

防護措施：

# 安裝前確認套件來源
pip show openai  # 查看套件資訊
pip install openai --dry-run  # 模擬安裝，檢查相依性

# 使用 pip-audit 掃描已知漏洞
pip install pip-audit
pip-audit

# npm 方面
npm audit

鎖定版本：在 requirements.txt 或 package-lock.json 中固定確切版本號，不要用 >= 或 ^ 等範圍指定。

私有套件庫：企業環境考慮架設私有的 PyPI 或 npm registry（如 Nexus、Artifactory），只允許經過審核的套件進入。

API 供應鏈風險

API 供應商的信任邊界

使用第三方 AI API（OpenAI、Anthropic、Google）時，你的資料會經過供應商的基礎設施。這帶來幾個風險：

資料政策變更：供應商可能在服務條款更新時改變資料的使用方式。例如是否將 API 輸入用於模型訓練、資料保留期限的調整。

服務中斷：如果你的核心業務依賴單一 AI API 供應商，服務中斷就是業務中斷。

模型版本更新：供應商可能在不通知的情況下更新模型版本，改變模型的行為特徵。你基於舊版本調整好的 Prompt 可能在新版本上表現不同。

防護措施：

多供應商策略：重要功能至少有一個備援的 API 供應商。用 LiteLLM 或類似的代理層統一 API 介面，方便切換。

API Key 權限最小化：每個應用使用獨立的 API Key，設定用量上限。不要跨應用共用 Key。

版本固定：在 API 呼叫中指定模型的確切版本（如 gpt-4-0613 而非 gpt-4），避免供應商自動升級帶來的行為改變。

監控供應商通知：訂閱 API 供應商的狀態頁面和變更通知，及早因應政策或功能變更。

AI SBOM（軟體物料清單）

傳統軟體用 SBOM 記錄所有相依元件。AI 專案的 SBOM 應該多記錄：

模型來源和版本（Hugging Face repo、commit hash）。

訓練資料的來源和授權（如果是自訓練的模型）。

推論框架版本（PyTorch、TensorFlow、ONNX Runtime）。

API 供應商和使用的模型版本。

Prompt 模板版本（如果用版本控制管理 Prompt）。

格式上可以參考 SPDX 或 CycloneDX 的 AI/ML 擴展。這些標準還在發展中，但現在開始記錄，比之後回頭整理容易。

安全與限制

AI 供應鏈安全面臨的根本挑戰：

模型是黑盒子。跟程式碼不同，你沒辦法「閱讀」一個模型的權重來判斷它有沒有被植入後門。目前的偵測方法都是用統計測試，有誤判的可能。

生態系太新。相比 npm 和 PyPI 有多年的安全掃描基礎設施，AI 模型的安全掃描工具還在早期階段。Hugging Face 有基本的惡意模型掃描，但覆蓋率有限。

合規標準未定。台灣和國際上都還沒有針對 AI 供應鏈安全的明確法規要求。但參考軟體供應鏈安全（如美國的行政命令 14028），AI 供應鏈法規只是時間問題。

建議的最低標準：只用 safetensors 格式的模型、固定所有套件版本、定期執行 pip-audit 和 npm audit、記錄你使用的所有 AI 元件的版本資訊。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題