软件供应链已成为企业网络风险的关键点，千万别准备不足而措手不及

在短短几个月内，我们目睹了数起配得上“史无前例”这一被过度使用词汇的人工智能技术事件：TeamPCP发起的高度复杂的供应链攻击、Anthropic PBC公司的Claude Code源代码泄露，以及Anthropic的Claude Mythos工具的首次亮相——据说该工具功能极其强大，以至于其使用权限被立即限制在了特定企业范围内。

从安全的视角看，我们正面对这样一个未来：与AI相关的攻击将迅速从各个角度袭来，而AI防御手段却根本没有准备好。软件供应链，才是攻击者真正的“肥肉”。

危险的交汇

最近的TeamPCP攻击凸显了传统软件供应链威胁与快速扩张的AI生态系统之间危险的交汇。攻击者展现了极高的攻击复杂性，成功攻陷了广受信任的安全工具及CI/CD（持续集成/持续开发）工具，包括Trivy开源安全扫描器和Checkmarx应用安全平台。他们还瞄准了LiteLLM——这是一个开源的Python库和代理服务器，提供了调用超过100种大语言模型的统一接口。

恶意的LiteLLM版本（1.82.7和1.82.8）被植入了一个高度混淆、多阶段的凭证窃取程序和投放器（dropper），旨在造成最大程度的破坏和影响。由于常见开发工作流的特性（开发人员、云基础设施和CI/CD系统通常共享敏感凭证的访问权限），这次攻击的波及范围尤为巨大。攻陷像LiteLLM这样一个单一工具，就使得攻击者能够在Kubernetes集群中横向移动，并将数据窃取到攻击者控制的域名下。

软件供应链攻击并非新鲜事；SolarWinds事件发生在五年多以前。然而，TeamPCP的这次入侵彻底重塑了这一概念。这是我们首次目睹成功武器化的安全和开发人员基础设施，且这些设施需要极高的访问特权。这不仅让攻击者畅通无阻地获取了生产环境的机密信息，还赋予了他们对受害公司发起勒索和勒索软件攻击的能力。

作为关键基础设施的中间件

TeamPCP的入侵是一个完美的例子，展示了首席信息安全官（CISO）和安全领导者们在应对全新AI攻击面时所面临的挑战。组织在规划防御策略时，必须将AI“中间件”视为关键基础设施。抽象层直接位于数据流中，例行处理高度敏感的环境变量和API密钥。任何有影响力的AI治理框架都应将AI中间件归类为高风险组件，并对其使用的机密信息以及它们通常拥有无限制访问权限的敏感存储库实施严格监控。

AI治理政策应强制要求，对任何支持大语言模型（LLM）交互的基础设施进行持续监控，以发现未经授权的出站连接和数据窃取行为。此外，还应强制执行安全的开发工作流，以防止级联式的供应链入侵。

我们还必须使风险管理实践现代化，确保开发人员具备安全配置、审查和监控工具输出及变更的专业知识。例如，我们应该修正诸如“依赖项锁定”之类的流程，以防止恶意的自动化更新执行；使机密信息管理现代化；并对访问密钥应用最低权限原则，将流水线执行限制在组织批准的操作列表内。

这次攻击还凸显了对模型上下文协议（MCP）代理进行可见性控制和权限控制是多么至关重要。这次攻击的破坏性之所以特别巨大，很大一部分原因在于使用了未记录的MCP插件，而这些插件可能被出于恶意目的所攻陷。在实施拥有如此自主能力和内部连接性的技术时，我们绝不能如此松懈。

AI的风险管理

这次攻击的速度（短短几小时内就出现了数千起潜在入侵）证明，被动式的安全防御已不再可行。通过锁定依赖项流水线并严格管控驱动AI应用的机密信息，我们可以缩小这些复杂供应链威胁的波及范围。

可以通过以下方式赋能开发人员，让他们共同承担AI安全的责任：

1.持续学习最新AI安全问题的技能与培训。 传统的软件开发正迅速成为过去式，但要成为一名真正优秀的开发人员，所需的现实世界技能将保持不变。企业安全领导者必须确保他们的培训是持续不断的，为安全和开发的最佳实践打下坚实基础。这些实用技能，加上对业务目标的不可替代的洞察力和批判性思维，是成功进行代码审查的主要要素。

2.使用AI治理工具。 你如何知道哪些开发人员提交了什么代码，包括他们使用了什么工具来做到这一点？AI编码的新时代需要一个全面的控制平面，来管理AI工具、它们参与的代码提交，以及构建和增强功能的人员的安全技能。

3.遵守组织的规则集和指南。 你们组织的安全计划是否足够与时俱进，能够提供关于AI使用的指导方针？针对正在使用的工具，是否有专门的AI规则集？这些都是能快速见效的措施，至少可以强制执行最低限度的安全编码标准。