Episode 05 02 — The AI supply chain — and securing MCP
三句話摘要
AI 應用的供應鏈安全防護——如何保護預訓練模型、數據集、軟體包和 MCP 服務器這四個入口點。 供應鏈安全的核心是：在代碼執行之前，在信任邊界處用哈希驗證、簽名檢查和沙箱隔離把好三道門，才能把威脅擋在門外。 您邀請的威脅：與模型本身的攻擊不同，供應鏈攻擊不是破壞進來，而是您主動加載有毒元件。未簽名或簽名不符的製物直接失敗關閉，保持零信任態度——只允許已知良好的東西通過。
重點整理
重點- 1
您邀請的威脅：與模型本身的攻擊不同，供應鏈攻擊不是破壞進來，而是您主動加載有毒元件。未簽名或簽名不符的製物直接失敗關閉，保持零信任態度——只允許已知良好的東西通過。
- 2
命名空間重用的真實風險：被信任組織的命名空間過期後，攻擊者可以重新註冊同一名稱。您按名稱拉取的模型現在指向攻擊者的版本，成本極低但威力巨大。必須通過雜湊固定版本加簽名驗證來預防。
- 3
MCP 服務器是新攻擊面：MCP 是一個直插進代理的工具標準，一旦加載就以您的身份運行，擁有相同的密鑰、機密和爆炸半徑。需要嚴格審查來源、限制為最小必需權限、沙箱隔離，以及禁止硬編碼機密。
- 4
可見性與掃描缺一不可：維護所有已加載元件的完整清單（模型、數據集、包、MCP 服務器及其版本與雜湊），並掃描模型文件中的不安全反序列化風險，防止加載時代碼執行漏洞。
實用技巧與重點
乾貨- 四個供應鏈入口：預訓練模型、數據集、軟體包、MCP 服務器
- 三層防護機制（三個 Gate）：
- Gate 1：通過雜湊固定（pin by hash）+ 簽名驗證，未簽名或不符失敗關閉
- Gate 2：維護清單（eyebomb），記錄每個模型、數據集、包、MCP 服務器的版本與雜湊；掃描模型文件的不安全反序列化
- Gate 3：MCP 服務器審查、最小權限範圍、沙箱隔離、禁止硬編碼機密
- 攻擊模式：汙染的權重、中毒的數據、惡意包、惡意 MCP 服務器、命名空間重用
- 零信任原則：只允許已知良好的製物，其他全部阻止
結論
結論“供應鏈安全的核心是：在代碼執行之前，在信任邊界處用哈希驗證、簽名檢查和沙箱隔離把好三道門，才能把威脅擋在門外。”
完整解析
詳細現代 AI 應用的構成中，您自己編寫的代碼往往只是冰山一角。預訓練模型、公共數據集、第三方軟體包和 MCP 服務器這四大類外部元件，全部運行在您應用的進程內，即刻進入您的信任邊界。這就是供應鏈安全與傳統模型攻擊本質不同的地方——您不是被入侵，而是自願安裝了威脅。
供應鏈攻擊的成本極低卻影響深遠。最經典的案例是命名空間重用：當一個受信任組織對應的軟體包命名空間過期後，攻擊者可以搶先重新註冊相同的名稱。此後，所有按名稱拉取該包或模型的用戶，都會無意中指向攻擊者的版本。更危險的是 MCP 服務器——作為直接插入代理的工具標準，一旦加載就以應用的完整身份運行，擁有所有密鑰、環境變數和權限。
防護的三層把關必須同時部署。第一層是源頭驗證：所有外部製物必須通過雜湊值固定版本，並驗證加密簽名。未簽名或簽名不符的製物要直接失敗關閉，保持絕對的零信任態度。第二層是可見性與掃描：維護一份完整的清單記錄已加載的所有模型、數據集、包和 MCP 服務器及其版本、雜湊，並主動掃描模型文件中的不安全反序列化操作，防止加載時的代碼執行漏洞。第三層針對 MCP 的高風險特性：必須嚴格審查其來源、縮小其權限範圍至絕對最小必需，使用沙箱隔離運行，以及確保機密和環境變數決不能硬編碼在源碼中。
按照這套防護框架，未經驗證的製物永遠無法進入信任邊界。模型被精確固定、包被簽名驗證、MCP 被沙箱隔離，您的 AI 應用就能保持整潔與安全。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
