黑客正在对开源软件生态系统发起一场系统性的投毒攻击。这次攻击的代号叫做Mini Shai-Hulud，已经成功污染了数十个被广泛使用的开源软件包，受到影响的下游开发者和企业数量目前还在持续统计当中。
供应链攻击这个概念并不新鲜，但这次攻击的规模和手法值得特别关注。攻击者并没有去寻找某个具体漏洞然后利用它，而是直接渗透进了开源项目维护者的账号或者持续集成部署流程，把恶意代码注入到了正常发布的版本里面。当下游开发者按照惯例更新依赖库的时候，根本察觉不到自己安装了被篡改的东西。
开源软件的供应链安全问题一直是行业里的老大难。在主流的包管理平台上，几百万个软件包之间存在着复杂的互相依赖关系，任何一个环节遭到污染，影响范围都会呈几何级数放大。此前那次让整个行业紧张了好一阵子的漏洞事件，本质上是代码本身存在缺陷，而这次是有人故意往里面投放恶意代码，性质完全不同，也更加危险。
为什么开源生态特别容易受到这种攻击？原因在于大多数开源项目的维护者都是志愿者，既没有专职的安全团队，也没有严格的身份验证和审核流程。一个维护者的账号被盗，整个项目的发布流程就可能被劫持。而且开源社区的信任模型本身就建立在参与者都是善意的假设之上，这在互联网早期没什么问题，但现在整个数字基础设施都大量依赖开源组件，这个假设就越来越脆弱了。
这次攻击对企业的直接影响很现实：如果你的持续集成管道配置了自动拉取依赖，那你可能已经在不知情的情况下使用了被污染的软件包。安全团队现在最紧迫的任务是检查项目的完整依赖树、逐一比对哈希值、锁定已知安全的版本号。但这些只是临时措施，根本性的解决方案还看不到明确的路径。开源基金会和平台运营商需要投入更多资源来建设自动化审计和发布签名机制，但这需要大量的资金和时间。
这次事件给所有依赖开源组件构建产品的公司提了个醒：供应链安全不是一个可以搁置的问题，而是需要立刻投入资源去管理的现实风险。开源软件的安全问题从来不是会不会出事的悬念，而是什么时候出事的倒计时。
这次事件给所有依赖开源组件构建产品的公司提了个醒：供应链安全不是一个可以搁置的问题，而是需要立刻投入资源去管理的现实风险。开源软件的安全问题从来不是会不会出事的悬念，而是什么时候出事的倒计时。每一个把开源组件作为产品基础的开发团队，都应该把依赖审计纳入日常流程，而不是等到出了安全事故才亡羊补牢。这次攻击的规模虽然已经很大，但和未来可能出现的更大规模协调攻击相比，可能只是前菜而已。