当前时间： 2026-03-26 14:21:05
更新时间： 2026-03-26
分类：软件教程
评论(0)
开源软件大概真的要被AI搞死了
原本我们觉得没什么大不了的, 毕竟是个我们连听都没听过的项目. 但事情发酵起来之后表明这是一次供应链投毒, 会影响很多下游项目比如龙虾(OpenClaw), 就让我们不得不关注起来. 毕竟尽管这阵子我们都在极力劝说身边的技术小白们不要尝试龙虾, 但依旧拦不住一些头铁的
.
供应链投毒不是什么新鲜事, 隔壁Node.js用的npm就发生过好几次了. 所以原作者才会另起炉灶搞了Deno, 并且加入了沙盒机制. 我们之前手搓Agent的时候也介绍过了.
这次事件中比较传统的原因似乎还是因为Python项目的依赖没有锁定版本. 我们多年以前搞机器学习的时候就经常遇到这样的问题. 想复现一篇前两年的paper, 把作者的代码拉下来安装依赖的时候经常直接就装上了最新的版本, 跟作者当年用的版本不一致, 可能就跑不起来.
隔壁的npm虽然很早就有lock文件, 但很多人安装依赖的时候也仍旧不会用clean install, 甚至可能连lock文件都不加入版本控制. 似乎整个开源社区就一直在鼓励用上兼容的最新的依赖, 毕竟如果发现了什么漏洞或bug的话第一时间更新就好了. 但一方面兼容性只能靠semantic version来确保, 纯属作者的个人行为. 另一方面这次也看到了, 遇到供应链投毒的时候, 本来干净的版本就自动安装成带毒的版本了.
据说这次攻击的第一环发生在CI工具里, 也是因为引用了tag而非版本hash, 攻击者改变了tag指向的内容就完成了攻击. 可见这不是单独一门语言的问题, 而是整个生态中都存在的问题.
而这次事情中的新现象是疑似AI的参与. 据说攻击者升级攻击负载只花了很短的时间, 疑似vibe. 并且因为vibe出来的代码有bug才最终被发现. 被发现以后还操纵矩阵账号发布评论稀释相关讨论. 老实讲AI有没有写payload并不让我们担心, 让我们担心的还是开源社区受到的冲击.
AI对开源社区最明显的冲击就是自动化PR. 很多知名开源项目的贡献者都不堪其扰. 甚至已经有开源项目关掉了PR功能. 一个不接受PR的开源项目就只剩下审计和分发的功能了. 要是一开始所有的开源项目都不接受PR, 开源社区绝对发展不到今天的程度.
有人可能要说了, 那让AI来审核PR不就行了. 恭喜你, 卖token的也是这么想的. AI写代码再AI审核, token可以卖两次. 更何况AI审核就算出了问题也没法担责, 还是需要原作者背锅. 那对于原作者来说自然是关掉PR最省事了.
ESR当年在评价Linux与GNU内核时提出了著名的“大教堂与集市”的类比, 指出开源项目成功的原因在于: 只要有足够多的人在看, bug将无处遁形. 问题是今后还会有“人”看开源项目吗?
以前你可能发现Github上某个项目很多star和fork, 很多pr和issue, 看上去活跃度挺高, 就觉得应该不会有什么问题. 但曾几何时这些数据都是可以被矩阵账号刷出来的, 还要如何相信有足够多的人看过这个项目呢?
有人可能又要说了, AI也能“看”代码和修复bug. 那么问题来了, 为了提升AI的能力, 训练时都已经投喂了几乎是全网的数据. 那么用几乎相同规模的数据训练出来的不同AI, 在改bug时能提供多少多样性的意见?
更进一步, 虽然每个人都可以跑不同的Agent, 但Agent能够调用的云端的AI就集中在少数几家基模厂商. 也就是说看似是由不同Agent提出的PR, 其实最终可能是同一个模型生成的. 那么让不同的人跑的Agent提PR的意义何在? 让不同的人分担token的费用? 还是在玩什么左右脑互搏的软件开发过家家?
更致命的问题在于大模型提供了新的攻击面. 提示词注入问题在本质上无法解决. 因为大模型无法区分提示和数据, 对于大模型来说都是上下文. 用软件来类比的话就好比是脚本语言中的eval函数, 接受的数据也是可以被执行的代码, 因为会带来各种安全问题而不被推荐使用.
我们这个号经常会手搓一些东西, 按理说少了很多第三方依赖, 是不是就更安全了呢? 也不是的, 因为供应链投毒麻烦的地方就在于不知道是投在了供应链的哪一环. 只要有第三方依赖就都没法排除被投毒的可能性. 除非能从零搓出所有的依赖. 但从哪一层开始搓呢? 标准库? 编译器? 操作系统? 芯片?
所以一边是开源项目受到冲击, 另一边是开源供应链的信赖被击碎. 港真我们也不知道要怎么办了, 可能开源软件真的要死了吧.
夜雨聆风
