我们把过去的重大事件，聚焦到此刻对你自己运维真正有用的教训上来回顾。
发生了什么
出问题的这个库，维护的人手不足，长期靠一个人独自支撑。这时，另一名人物持续做出贡献、积累信任，最终取得了共同维护者的身份。然后，他以混入常规更新的方式，分阶段地带入了在特定条件下允许外部非法访问的机关。
被瞄准的不是代码里的漏洞，而是**『可信赖的人发出的正规更新』这一前提**本身。
被瞄准的是『人与信任』
这是靠防火墙或补丁都难以防住的攻击。OSS 的维护者靠善意和志愿者支撑，而其过载与孤立成了攻击的入口。这起事件表明：关乎安全的，不只是技术，还有生态系统本身的健康。
发现的契机 ——『怎么有点慢』没有被放过
发现它的契机，是某位技术人员在做一项无关工作时，产生了『登录处理明显比以前慢』『动作测试的测量值不太对劲』这样的小小违和感，并没有放任不管，而是把原因追查到底。结果，它在向稳定版大范围铺开之前，世界被拯救了。
『总觉得哪里不对』是最好的探测器。这一次，它真真切切地拯救了世界。
时间线
数年前～
攻击者持续做出贡献，作为维护者积累信任。2024 年初
混在正规更新里，分阶段地植入了后门。2024-03
一名技术人员追查『慢』这一违和感，在抵达稳定版的前一刻发现并公开。
此刻有用的教训
把依赖控制到最小
用的库越少，需要去信任的对象也越少。别因为『方便』就轻易增加。
固定版本，并查看改动
用锁文件察觉意外更新，并关注重要依赖的改动内容（谁、改了什么）。
提高构建的可复现性
同样的输入产出同样的产物（reproducible build）程度越高，越容易发现偷偷的混入。
不放任违和感
『怎么有点慢／不太对劲』是最好的探测器。这一次正是它拯救了世界。养成把小小的异常追查到底的文化。
对维护者的敬意与支援
你所依赖的 OSS 是否健康，兜兜转转，关乎的正是你自己的安全。过载与孤立会成为攻击的入口。
接下来阅读
- 术语：什么是 CVE / 什么是 RCE
- 事故：Codecov —— CI 中被信任的工具被劫持的故事
- 对策：用机器监控依赖的机制
FAQ
QXZ Utils 事件特殊在哪里？
在于被瞄准的不是代码的 bug，而是『人与信任』。攻击者花了好几年作为 OSS 维护者积累信任，再以正规更新的名义混入后门。这是仅靠技术手段难以防住的一类攻击。
Q它是怎么被发现的？
某位技术人员在做一项无关的工作时，产生了『登录处理明显比以前慢』『测量值不太对劲』这样的小小违和感，并没有放任不管而是追查到底。结果，它在即将向稳定版大范围铺开的前一刻被拦了下来。
Q个人开发者能做些什么？
把依赖控制到最小、关注更新的来源与改动内容、用锁文件固定版本以便察觉意外混入、提高构建的可复现性，以及不放任『总觉得哪里不对』这种违和感。