6月17日，微软披露了一起针对Mastra AI开发生态的供应链攻击事件。

攻击者通过一个被控制的npm维护者账号，在短短81分钟内，向Mastra旗下的140多个软件包推送了恶意更新版本。

全球大量AI开发者和企业如果在那个时间段执行过常规的依赖更新，开发环境就可能已经暴露在风险之中了。

这起攻击的隐蔽性在于：攻击者没有直接污染Mastra的官方包，而是在其中嵌入了一个恶意依赖。

开发者从npm拉取的是正规包，但安装过程中会默认拉取这个恶意组件，进而使得电脑在无意间下载了信息窃取程序。

这个程序会翻找浏览器历史、保存密码、API密钥，还会检查设备上是否安装了加密货币钱包扩展。

后续报道显示，微软将这次攻击活动关联到了朝鲜相关的黑客组织Sapphire Sleet。

一、AI应用开发依赖复杂的开源供应链

过去谈到AI安全，很多企业首先想到的是模型是否可靠、数据是否泄露、生成内容是否合规。

但在真实的开发过程中，一个 AI应用背后往往依赖大量开源框架、第三方依赖包、模型接口等。

开发者借助这些工具，可以更快地搭建应用；企业也能够更快地把AI嵌入客服、运维、办公、数据分析等业务环节。

然而，在开发效率大幅提升的同时，安全边界也被同步拉长了。一个看似普通的依赖包、一个长期未更新的维护者账号，都可能成为攻击者进入开发环境的入口。

对于企业来说，AI应用开发越快，越不能忽视其背后的开源依赖和工具链安全。

二、攻击者正在从“攻击系统”转向“攻击供应链”

传统安全防护主要围绕企业自己的系统展开：服务器有没有暴露，应用有没有漏洞，终端有没有被植入木马等等。

但供应链攻击的危险之处在于，它不一定从企业系统正面突破，而是选择污染企业信任的上游组件。

开发者安装的是正常框架，调用的是正常依赖，进入的是日常构建流程。

从表面上看，这些操作和普通开发工作没有太大区别。但一旦上游组件被植入恶意代码，攻击就能顺着开发流程进入企业内部。

而且，这类攻击的扩散效率往往更高。污染一个被广泛使用的软件包，可能同时影响成百上千个开发团队、项目和构建系统。

攻击者利用的，不仅是代码漏洞，更是企业对开源组件、开发流程和自动化工具的信任。

三、安全边界需延伸至开发者终端

过去，开发环境常常被视为“内部工作区”，安全优先级往往低于生产系统。

但在今天，开发者终端和构建环境已经成为高价值攻击目标。

一台开发者电脑，可能同时连接代码仓库、云平台、测试环境；

一个构建系统，可能保存着自动部署所需的访问令牌；

一个项目配置文件，也可能包含模型接口、数据库或内部系统的调用凭证。

对攻击者来说，拿到这些凭证，比攻破一台单独服务器更有价值。因为它们不只意味着一次入侵，还可能带来后续的权限扩展、数据访问，甚至进一步的供应链污染。

所以，企业需要保护的，不再只是已经上线的业务系统，要还包括开发者终端、依赖管理平台、自动化构建环境等。

结语

总之， AI时代的安全风险已经进一步前移到开发框架、开源依赖、构建流水线和访问凭证之中。

对企业安全团队而言，真正需要关注的不只是 AI应用“上线后是否安全”，还应包括它是如何被开发、如何被构建、如何被连接，以及哪些凭证和权限正在支撑它运行。

只有把开发链条、访问路径、网络连接和持续监测纳入统一安全视角，企业才能在利用AI提效的同时，降低供应链风险带来的不确定性。