npm/Docker/PyPI的供应链安全模式正在MCP上重演,我们正处于2015年的时刻
摘要
文章警告称,MCP生态正在重演npm、Docker和PyPI中出现的供应链安全模式——审核极少,风险日益增长。文章指出,对500个Smithery服务器的扫描发现18.8%存在安全问题,现有安全工具无法处理恶意智能体指令,并介绍了一个名为bawbel的新型静态扫描器。
套路总是一模一样:注册表快速启动并增长,由于增长优先而审查极少,第一波事件爆发,社区愤怒,工具跟上,安全成为基础预期。npm大约花了三年时间从event-stream事件走到`npm audit`成为标配。Docker Hub也差不多。MCP目前处于第二步,即将迈入第三步。本月对500个Smithery服务器的扫描数据显示:18.8%存在安全问题,6个含有硬编码的实时凭证,没有一个被发布前扫描发现——因为根本不存在发布前扫描。Check Point在2月份披露的一项研究显示,针对Claude Code存在一条CVSS 8.7的攻击链,其整个载荷就是配置文件中的自然语言。与npm的不同之处在于恶意内容所做的事情。npm包执行未经授权的代码。而一个恶意的MCP技能文件则向已经拥有你工具、文件系统和API访问权限的智能体发出未经授权的指令。LLM无法区分来自用户的指令和来自技能文件的指令。两者都会进入上下文窗口,并被执行。现有的安全工具对此没有模式。解决办法始终是同样的三个层面:发布前注册表扫描、面向消费者的CI集成,以及公开的漏洞数据库。对于MCP,这三个方面目前都还没有成熟的形式。时间线是一年还是三年,取决于注册表运营商是主动行动,还是等待一个足够公开的事件发生。根据npm和Docker的过往经历,我打赌事件会先发生。我们为此构建了一个静态扫描器:`pip install bawbel` - 扫描技能文件和MCP服务器配置,无需执行任何内容。其漏洞数据库对标AVE。
相似文章
无法预防这种情况,唯一频繁发生此类事件的包管理器如此表示
讽刺文章指出npm注册表中反复出现的供应链攻击,与Go和Rust等更安全的生态系统形成对比,并嘲笑JavaScript社区对这种漏洞的接受态度。
@altryne: 公开提醒:如果你尚未了解最新的供应链攻击,或者知道但无动于衷且未采取任何措施,尤其是……
一则关于通过 npm 和 PyPI 针对 AI 开发者工具(Hermes、OpenClaw)的供应链攻击的公开提醒,特别是名为“Mini-Shai Hulud”的蠕虫病毒,它能自我复制并窃取凭据、API 密钥和浏览器会话。文章建议使用沙盒执行并限制软件包年龄以降低风险。
Deadbugz:当前活跃的MCP供应链攻击活动
Pillar Security研究人员详细描述了Deadbugz,这是一个活跃的供应链攻击活动,通过GitHub拉取请求分发恶意MCP服务器,将窃取凭据的指令隐藏在三项良性工具调用之后。
@Docker:该恶意软件并未自带凭据扫描器,而是借用了你的。在本期AI编码代理恐怖故事中:@…
一个恶意npm包(s1ngularity)利用安装后钩子,将已安装的AI编码代理重新用作凭据扫描器,窃取开发者的机密信息。Docker的博客讨论了Docker沙箱如何通过隔离凭据与代理的接触来缓解此类攻击。
软件包管理器存在完整性问题
Trail of Bits 测试了 25 个流行软件包管理器检测被入侵仓库注入恶意代码的能力,发现不到一半的管理器默认通过锁文件验证完整性,且只有 Go 默认验证软件包签名,凸显了供应链中广泛存在的风险。