楼主提到的依赖嵌套问题,让我想起去年帮一个学生团队排查训练环境时的发现:他们的一个小型NLP项目,pip install 拉下来竟然是247个包,其中至少有6个是2019年之后就没更新过的。最令人不安的是,有个负责日志格式化的中间件,半年下载量不到500次,却在他们的requirements.txt里安静地躺了八个月。嗯
这不是个别现象,算是行业的结构性困境了。
补充几个数据点。2023年Sonatype的报告里提到,针对开源生态的恶意包数量同比增长了超过200%,其中AI/ML相关包的增长幅度尤其明显。其实攻击者的思路很清晰:AI开发者习惯用pip install / npm install解决问题,而且训练环境通常算力充足、网络带宽大,一旦被控,无论是挖矿还是数据外泄,回报都相当可观。
具体到楼主关心的依赖管理,我观察到的风险其实分三层。
第一层是直接依赖的漏洞,比如某个版本的transformers库存在反序列化缺陷,这个相对好防,有CVE编号,扫描工具基本能识别。第二层是间接依赖的恶意代码注入,就像楼主说的TanStack事件,攻击者通过污染上游仓库或篡改包元数据来渗透,传统的版本锁定基本防不住。第三层最隐蔽——利用AI框架的特性进行攻击。举个例子,PyTorch的torch.load默认使用pickle,这是设计如此而非漏洞,但攻击者完全可以构造恶意模型文件,在你加载预训练权重时执行任意代码。Hugging Face上已经有安全团队发现过这类案例,模型文件本身看起来完全正常,推理结果也正确,但pickle反序列化时会触发payload。
嗯
这就不单纯是依赖扫描能解决的问题了,需要从工作流设计层面做隔离。
顺带说一句,关于“大公司能及时发现”这个判断,可能需要商榷。OpenAI这次反应快,部分原因是TanStack事件在整个JavaScript生态里波及面太广,已经上了安全社区的头条。但如果攻击者瞄准的是某个特定版本的PyTorch nightly build,或者某个仅有几百星但恰好被某个团队内部使用的CUDA算子库,被发现的概率就会急剧下降。大公司的优势不在于“能发现”,而在于“发现后有资源做全量审计”。小团队如果真的被盯上,可能连排查的人力都抽不出来。
我自己的做法比较保守:所有实验环境跑在容器里,网络出方向默认deny,只开必要的镜像源和API端口;依赖清单不仅锁定版本,还要锁定hash;预训练模型加载前先做完整性校验。代价是搭建环境慢了一些,但至少睡得着觉。
不过老实说,这些措施在真正的供应链攻击面前也只是提高了门槛,称不上万全之策。开源生态的信任模型本身就建立在“大多数人都是善意的”这个前提上,而攻击者只需要找到少数几个漏洞就能造成破坏。这个不对称性,可能比具体的技术缺陷更难解决。