AI軟件供應鏈正在迅速擴展，不僅包括開源開發工具，還涵蓋了開發者共享定制模型、智能體、提示詞及其他資源的協作平臺。隨著第三方AI組件和服務使用的增加，安全威脅也隨之擴大——這種威脅在許多方面可能比傳統軟件供應鏈問題更為復雜、隱蔽且有害。

當公司急于嘗試AI技術時，往往缺乏對傳統軟件開發那樣嚴格的監督，而攻擊者則迅速意識到，這些超出典型安全監控范圍的新平臺和可共享資產可被利用來入侵系統和數據。

“這種模式并不新鮮，它與我們反復在軟件開發中看到的如出一轍，”軟件供應鏈管理公司Sonatype的首席技術官Brian Fox告訴記者，“每當有新鮮且令人興奮的事物出現，無論是容器化、無服務器，還是現在的AI，企業都會迅速行動以獲取利益，但安全往往滯后。AI的獨特之處在于其復雜性增加：預訓練模型、不透明的數據源，以及像提示詞注入這樣的新攻擊途徑。這些因素使得傳統安全實踐更難應用。”

AI依賴項中的缺陷和惡意代碼日益增多

就在上周，應用安全公司Backslash的研究人員警告說，數百個公開共享的Model Context Protocol(MCP)服務器存在不安全配置，這可能會在部署這些服務器的系統上開啟任意命令執行漏洞。MCP服務器將大型語言模型(LLM)與第三方服務、數據源和工具連接起來，以提供更好的推理上下文，使它們成為構建智能體的不可或缺的工具。

今年6月早些時候，AI安全初創公司Noma Security的研究人員警告稱，LangChain的Prompt Hub中的一個功能可能被攻擊者濫用，以分發竊取API令牌和敏感數據的惡意提示詞。LangChain的Prompt Hub是LangSmith平臺的一部分，用于構建、測試和監控基于AI的應用程序的性能。

LangSmith用戶可以在Prompt Hub中相互分享復雜的系統提示詞，這些提示詞的行為類似于智能體。在開發此類提示詞時，有一個功能是指定一個代理服務器，通過該服務器將所有API請求路由到LLM提供商。

“這一新發現的漏洞利用了采用‘Prompt Hub’上上傳的包含預配置惡意代理服務器的智能體的不知情用戶(這違反了LangChain的服務條款)，”Noma Security的研究人員寫道，“一旦采用，惡意代理就會秘密攔截所有用戶通信——包括API密鑰(包括OpenAI API密鑰)、用戶提示詞、文檔、圖像和語音輸入等敏感數據——而受害者卻毫不知情。”

LangChain團隊隨后向包含自定義代理配置的智能體添加了警告，但這一漏洞凸顯出，如果用戶不注意，尤其是當他們在自己的系統上復制和運行他人的代碼時，善意的功能也可能帶來嚴重的安全后果。

正如Sonatype的Fox所提到的，問題在于，對于AI而言，風險超出了傳統可執行代碼的范疇。開發者可能更容易理解為什么在他們的機器上運行來自PyPI、npm、NuGet和Maven Central等存儲庫的軟件組件如果未經安全團隊事先審查會帶來重大風險，但他們可能不會認為測試LLM中的系統提示詞或甚至是他人分享的定制機器學習(ML)模型也存在同樣的風險。

攻擊者完全明白，AI供應鏈在監督方面落后于傳統軟件開發，并已開始利用這一點。今年早些時候，研究人員在Hugging Face(最大的機器學習資產共享平臺)上托管的人工智能模型中發現了惡意代碼。

這些攻擊利用了Python的序列化Pickle格式。由于PyTorch作為廣泛使用的ML庫(用Python編寫)的流行，Pickle已成為存儲和分發ML模型的常見方式，然而，目前還沒有多少安全工具能夠掃描此類文件中的惡意代碼。

最近，研究人員在PyPI上發現了一個偽裝成阿里巴巴AI SDK的惡意組件，其中包含一個Pickle格式的“毒藥”模型，內部藏有惡意隱藏代碼。

安全工具仍在追趕AI供應鏈風險

“目前的大多數工具都無法充分掃描AI模型或提示詞中的惡意代碼，而攻擊者已經在利用這一差距，”Sonatype的Fox說，“雖然一些早期解決方案正在出現，但企業不應等待。他們需要立即擴展現有的安全政策，以覆蓋這些新組件——因為風險是真實存在且不斷增長的。”

DistributedApps.ai的首席AI官兼云安全聯盟(CSA)AI安全工作組聯合主席Ken Huang也表示贊同：“團隊常常優先考慮速度和創新，而非嚴格的審查，特別是隨著vibe coding(借助LLM驅動的代碼助手開發整個應用程序，人類通過自然語言提示作為監督者給出輸入)的興起，使得快速生成和分享代碼變得更加容易。這種環境促進了捷徑和對AI輸出的過度自信，導致集成了不安全或未經驗證的組件，增加了供應鏈被入侵的可能性。”

CSA是一個促進云計算安全保障實踐的非營利性行業協會，最近發布了一份由Huang與50多位行業貢獻者和審閱者共同編寫的《智能體AI紅隊指南》，其中一章探討了測試AI智能體供應鏈和依賴項攻擊的方法，這些攻擊可能導致未經授權的訪問、數據泄露或系統故障。

全面的MLSecOps方法

“依賴項掃描器、鎖文件和哈希驗證有助于將包固定到受信任的版本，并識別不安全或虛假的依賴項，”Huang告訴記者，“然而，并非所有威脅——如微妙的數據投毒或基于提示詞的攻擊——都能通過自動掃描檢測到，因此分層防御和人工審查仍然至關重要。”

Huang的建議包括：

? Vibe coding風險緩解：認識到vibe coding可能引入不安全或不必要的依賴項，并強制對AI生成的代碼和庫進行人工審查。鼓勵對所有AI生成的建議(特別是包名和框架推薦)持懷疑態度并進行驗證。

? MLBOM和AIBOM：建立機器學習或AI物料清單將為企業提供所有數據集、模型和代碼依賴項的詳細清單，為AI特定資產提供透明度和可追溯性。模型卡和系統卡有助于記錄預期用途、局限性和倫理考慮，但不解決技術供應鏈風險，MLBOM/AIBOM通過關注來源和完整性來補充這些。

? 持續掃描和監控：將模型和依賴項掃描器集成到CI/CD管道中，并監控部署后的異常行為。

? 零信任和最小權限：默認將所有第三方AI資產視為不受信任，隔離和沙箱化新模型和智能體，并限制AI智能體的權限。

? 策略對齊：確保AI平臺和存儲庫受到現有軟件供應鏈安全政策的覆蓋，并更新以應對AI和vibe coding的獨特風險。