注意！AI供应链威胁迫近，安全防护却没跟上

AI软件供应链正在迅速扩展 ，注意不仅包括开源开发工具，链威还涵盖了开发者共享定制模型、胁迫智能体、近安提示词及其他资源的全防协作平台
。随着第三方AI组件和服务使用的没跟增加，安全威胁也随之扩大——这种威胁在许多方面可能比传统软件供应链问题更为复杂 、注意隐蔽且有害。链威

当公司急于尝试AI技术时
，胁迫往往缺乏对传统软件开发那样严格的近安监督，而攻击者则迅速意识到，全防这些超出典型安全监控范围的没跟新平台和可共享资产可被利用来入侵系统和数据。

“这种模式并不新鲜 ，服务器租用注意它与我们反复在软件开发中看到的链威如出一辙 ，”软件供应链管理公司Sonatype的胁迫首席技术官Brian Fox告诉记者，“每当有新鲜且令人兴奋的事物出现，无论是容器化、无服务器，还是现在的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模型或提示词中的恶意代码，而攻击者已经在利用这一差距，”Sonatype的Fox说，“虽然一些早期解决方案正在出现 ，但企业不应等待。他们需要立即扩展现有的安全政策，以覆盖这些新组件——因为风险是真实存在且不断增长的 。”

DistributedApps.ai的首席AI官兼云安全联盟(CSA)AI安全工作组联合主席Ken Huang也表示赞同：“团队常常优先考虑速度和创新，而非严格的审查，特别是随着vibe coding(借助LLM驱动的代码助手开发整个应用程序，人类通过自然语言提示作为监督者给出输入)的兴起
，使得快速生成和分享代码变得更加容易。这种环境促进了捷径和对AI输出的过度自信，导致集成了不安全或未经验证的组件，增加了供应链被入侵的可能性 。”

CSA是一个促进云计算安全保障实践的非营利性行业协会，最近发布了一份由Huang与50多位行业贡献者和审阅者共同编写的《智能体AI红队指南》 ，其中一章探讨了测试AI智能体供应链和依赖项攻击的方法，这些攻击可能导致未经授权的访问、数据泄露或系统故障。

“依赖项扫描器、锁文件和哈希验证有助于将包固定到受信任的版本，并识别不安全或虚假的依赖项，”Huang告诉记者 ，“然而 ，并非所有威胁——如微妙的数据投毒或基于提示词的攻击——都能通过自动扫描检测到，因此分层防御和人工审查仍然至关重要
。”

Huang的建议包括 ：

• Vibe coding风险缓解：认识到vibe coding可能引入不安全或不必要的依赖项 ，并强制对AI生成的代码和库进行人工审查 。鼓励对所有AI生成的建议(特别是包名和框架推荐)持怀疑态度并进行验证。

• MLBOM和AIBOM：建立机器学习或AI物料清单将为企业提供所有数据集  、模型和代码依赖项的详细清单 ，为AI特定资产提供透明度和可追溯性 。模型卡和系统卡有助于记录预期用途 、局限性和伦理考虑，但不解决技术供应链风险，MLBOM/AIBOM通过关注来源和完整性来补充这些 。

• 持续扫描和监控 ：将模型和依赖项扫描器集成到CI/CD管道中，并监控部署后的异常行为。

• 零信任和最小权限：默认将所有第三方AI资产视为不受信任，隔离和沙箱化新模型和智能体，并限制AI智能体的权限
。

• 策略对齐
：确保AI平台和存储库受到现有软件供应链安全政策的覆盖 ，并更新以应对AI和vibe coding的独特风险 。

最新评论