您的 AI 供應鏈是您尚未管理的重大資安風險

問題所在

2024 年 2 月，JFrog 資安研究人員在機器學習領域最熱門的公開儲存庫之一 Hugging Face 上，發現了 100 多個惡意 AI 模型。這些模型並非單純出現故障，而是已被武器化。當開發人員下載其中一個模型並使用標準指令載入時，該模型會悄悄開啟通往遠端伺服器的後門——即反向 Shell（reverse shell）。攻擊者便能立即取得該開發人員系統的存取權限。

由名為「baller423」的使用者上傳的某個特定模型，利用名為 pickle 的常見檔案格式在載入過程中注入程式碼。當資料科學家執行標準的 torch.load() 指令那一刻，惡意程式碼便自動執行。它連線至屬於南韓研究環境開放網路（Korea Research Environment Open Network）的 IP 位址。

這並非理論上的風險，而是正在貴公司團隊每天可能使用的平台上真實發生。如果貴機構從公開來源提取 AI 模型（大多數企業確實如此），您所匯入的二進位檔案是人類無法以肉眼閱讀或審查的。與傳統軟體程式碼不同，AI 模型的權重是不透明的結構。惡意行為潛藏在數百萬個數值參數之中。您現有的程式碼審查流程根本無法察覺此問題。AI 供應鏈如今已成為貴公司技術堆疊中最脆弱且最缺乏治理的一環。

為什麼這對您的業務至關重要

此處所涉及的財務與監管風險敞口既真實且與日俱增。請參考本白皮書研究提出的以下數據：

• 83% 的機構缺乏自動化 AI 資安控制措施。 僅有 17% 具備任何自動化防禦機制。其餘機構正如研究人員所形容的，處於「盲目運作」狀態。
• 影子 AI（Shadow AI，即員工未經授權使用 AI 工具）佔企業 AI 使用量的 90%。 貴公司的 IT 與資安團隊目前很可能無法察覺機構內的大多數 AI 活動。
• 涉及未經審查 AI 工具的安全事件使資料外洩的平均成本增加了 $670,000。 這就是貴公司因未受治理的 AI 採用所付出的額外代價。
• 僅有 12% 的企業落實了具備實質技術控制的 AI 治理。 另有 56% 表示他們已「準備就緒」，卻缺乏相應的強制執行機制。
• 86% 的機構對 AI 如何在內部移動資料毫無能見度。 若您無法看清資料流向，便無法保護它們或證明合規性。

對貴公司的董事會與監管機構而言，問題相當明確：您能否向稽核員確切展示貴公司環境中正在運作哪些 AI 模型、它們來自何處，以及它們接觸了哪些資料？如果無法做到，您將面臨如 NIST AI 100-2 等新興框架下的合規缺口。您還將面臨始料未及的外洩事件所帶來的聲譽損害——因為該攻擊途徑是一個無人審查過的 AI 模型。

技術底層實際發生的狀況

要理解為什麼這種威脅如此難以察覺，不妨將 AI 模型想像成一個密封的食譜盒。傳統軟體就像以純文字寫成的食譜——您可以閱讀每條指示並找出危險之處。相較之下，AI 模型是一個上鎖的盒子，內部裝有數百萬個微小的轉盤。這些轉盤會產生輸出，但您無法打開盒子閱讀其中的指示。被下毒的模型在外觀和表現上與乾淨模型毫無二致——直到特定觸發條件啟動隱藏的行為為止。

這稱為資料投毒（data poisoning），其背後的數學原理令人震驚。來自 Anthropic 與 NVIDIA AI 紅隊（AI Red Team）的研究人員指出，僅對 0.00016% 的訓練資料下毒——即龐大資料集中的大約 250 份文件——就會永久破壞一個 130 億（13-billion）參數的模型。一旦投毒資料被烘焙進模型的權重中，添加再多乾淨資料也無法修復。這個後門是永久存在的。

這些被投毒的模型就像「潛伏特工」（sleeper agents）。它們能通過每項標準測試與基準評測，在貴公司的 QA 環境中表現完全正常。然而，當它們遇到特定觸發條件時——例如一段獨特的文字字串、特定的影像特徵，甚至是位元層級的輸入篡改——模型便會切換到惡意模式。這可能意味著繞過身分驗證、外洩敏感資料，或是生成由貴公司下游系統自動執行的有害程式碼。

這項危險不僅限於模型本身。甚至連旨在保護您的資安掃描工具也出現漏洞。JFrog 在廣泛用於審查 AI 模型的工具 PickleScan 中發現了三個零日漏洞（zero-day vulnerabilities）。攻擊者可以透過篡改副檔名，使受損模型看起來「安全」。研究顯示，目前高達 96% 的掃描器警報皆為誤報（false positives），這會讓貴公司的資安團隊對真正的威脅麻木不仁。

什麼有效（以及什麼無效）

讓我們先檢視三種無法解決問題的常見方法：

• 依賴公開儲存庫的信任評分。 Hugging Face 並非經過嚴格審查的軟體供應商。在那裡發現的 100 多個惡意模型證明了熱門度與可用性並不等於安全性。
• 制定缺乏自動化強制執行的 AI 治理政策。 一份政策文件無法阻止開發人員在凌晨兩點下載未經審查的模型。若沒有技術防護屏障，77% 的員工將繼續把專有資料貼入公開的 AI 工具中。
• 對 AI 模型檔案執行標準程式碼掃描器。 傳統的靜態分析工具缺乏檢查模型權重的上下文能力。它們無法偵測隱藏在數值參數中的後門，或嵌入在模型元資料中的惡意範本。

真正有效的方法，是將每個 AI 模型視為潛在的惡意可執行程式碼。以下是分為三個步驟的架構原則：

1. 輸入——建立機器學習軟體物料清單（ML-BOM）。 在任何模型進入貴公司環境之前，先生成一份記載其來源、訓練資料、框架依賴項與密碼編譯簽章的防篡改記錄。可以將其視為每個 AI 構件的監管鏈文件。像 CycloneDX 與 SPDX 3.0 等標準現在已專門為此目的支援 AI 專用設定檔。貴公司的 資料溯源與可追溯性實踐 在此奠定了基石。

2. 處理——在載入時強制執行密碼編譯驗證。 貴公司的推論伺服器（即運作 AI 模型的系統）應包含一個「准入控制器」（Admission Controller），在模型載入記憶體之前對照信任登錄庫檢查每個模型的數位簽章。這意味著只有由貴機構自身金鑰簽署的模型才能執行。使用硬體安全模組（HSM）來管理這些金鑰。全面禁用 pickle 格式，轉而採用不允許包含可執行程式碼的 SafeTensors 格式。

3. 輸出——在執行階段持續監控模型行為。 將模型輸出與乾淨的驗證基準進行比對，以偵測代表後門啟動的漂移或異常現象。套用輸入清理層，在查詢抵達模型前重新轉述其語句，藉此瓦解精心設計的觸發有效負載（trigger payloads）。對查詢實施速率限制，以防止模型提取攻擊。

稽核軌跡的優勢正是讓這種方法對貴公司合規團隊極具價值的原因。每個模型都有簽署的 ML-BOM；每次部署都有經過驗證的簽章鏈；每次推論都有受到監控的輸出。當您的監管機構或稽核員詢問「您如何知道此 AI 模型是安全的？」時，您可以出示密碼編譯證明——而非僅是一份政策文件。

對於處於 AI 資安與韌性領域的機構而言，這已不再是可有可無的選項。AI 資安與軟體供應鏈安全性的融合，意味著貴公司現有的 CI/CD 管道防護必須延伸涵蓋模型構件。如果您的模型是安全的，但運作該模型的 Python 函式庫受到侵害，您的系統依然會被攻破。對軟體與 AI 資產採取統一的 資安評估與強化 方法，是彌合這一缺口的唯一途徑。

閱讀完整技術分析 以獲取詳細的實作指引，或 探索互動版本 以了解這些控制措施如何對應至貴公司的特定環境。