沉睡後門與開源模型：你部署的不只是能力，也是供應鏈風險
開放權重 LLM 可能藏有『沉睡後門』：平常正常，遇到觸發詞就亂輸出。把模型當成 production dependency，供應鏈體檢與部署風險控管就成了必修。
最近看到一個很值得所有「用開源模型的人」警覺的議題：沉睡後門（sleeper agent）。
你下載一個開放權重（open weights）的 LLM 來 fine-tune 或部署，平常做一般測試都很正常；但只要遇到特定觸發詞，就開始亂輸出：塞漏洞程式碼、吐仇恨內容、或做出你根本不會在正常情況下允許的行為。
這不是科幻，而是供應鏈風險。
當模型變成你產品的一部分，模型就跟依賴套件一樣：你不是只在買能力，你也在承擔風險。
為什麼這類「沉睡後門」特別難抓？
因為它的設計目標就是躲過你平常會做的測試。
多數團隊的模型驗證流程，其實偏向功能面：能不能答題？能不能寫 code？能不能遵守政策？
但 sleeper agent 的攻擊面是「條件式行為」：平常像正常人，遇到某個 token/語境/格式就變臉。
換句話說，你越依賴抽樣測試，它越容易藏起來。
供應鏈體檢要怎麼做？幾個務實的方向
我覺得這類風險的防守，不會只有單一招，而是一套工程流程。
- 把模型也納入 SBOM 思維
你需要知道：模型從哪來、是誰發佈的、權重版本、訓練/合成資料線索、以及你做了哪些改動。
很多人部署開源模型的方式，還停留在「抓個 checkpoint 下來就跑」，但這在供應鏈時代風險太高。
- 建立觸發詞/觸發條件的掃描與 fuzz
如果後門是靠 trigger 觸發，那防守就要設計「大量條件」去撞它。
實務上你可以：
- 用不同語言、不同編碼、不同格式（JSON、YAML、Markdown）生成觸發條件
- 把模型放進固定 harness 裡跑 replay
- 把輸出用規則與分類器做二次檢測
- 對「寫程式碼」類輸出加上安全掃描
如果你的模型會產生程式碼，最直接的防線是把輸出當成不可信輸入。
你要掃：已知漏洞模式、可疑 import、危險 API、以及明顯的資料外洩片段。
- 把風險管理做進部署策略
用 canary、A/B、逐步放量，把「模型升版」當成高風險變更。
只要你一口氣把新模型全量上線，你就等於把整個產品的安全押在一次運氣上。
結語
開放權重 LLM 很迷人，因為它讓你擁有更多控制權。
但控制權的另一面是責任：你要自己做供應鏈治理、做安全體檢、做部署風險控管。
當我們開始把模型當成 production dependency，團隊才有機會真正享受開源的紅利，而不是在某一天被「沉睡後門」反噬。
(原文連結)
