开源软件更安全吗？
结论
知名压缩软件 xz 被发现有后门，关于开源软件供应链的安全问题，再次引发讨论。显然大家长期以来关心的是两个问题：
开源软件更安全吗？
开源软件更不安全吗？
如果以上都不是，怎么判定一个开源软件的安全性？
我把结论放在开头：
开源没有让软件更安全，也没有让软件更不安全。是否“开源”，与“安全”之间不存在相关性
判断开源软件的安全性应该考察社区的成熟度和规范性。
漏洞的及时修复比预防漏洞披露更重要
Linus's Law
声称开源软件会更安全的一个论据在于 Linus's Law ——“只要有足够多的眼睛关注，任何漏洞都无处隐藏(given enough eyeballs, all bugs are shallow)”。
看上去无懈可击，但是这显然和事实不符。无论是早年的 OpenSSL 心脏出血，还是近期的 Log4j 的漏洞，开源软件的漏洞报告从未停止过，这其中还包括 Apache Struts2 这样”臭名昭著“的开源软件开发框架，如果有人对这几年给 Struts2 擦屁股的码农说 Apache Struts2 是开源软件，他更安全！这人肯定会被当成神经病的。
没有后门？
如果说漏洞主要来自于程序员的能力不足，那后退一步，是否可以认为至少在开源软件里，在足够多眼睛的关注下，后门应该无所隐藏呢？
很遗憾，这几年来至少 3 起事件把最后的这点信任也摧毁了。
Event-Stream 挖矿后门
Event-Stream 是一个 npm 生态中底层的应用库，right9ctrl 与 event-stream 的作者搞好了关系后拿到了项目的所有权，随即给项目植入了挖矿代码。于是一系列的下游项目纷纷躺枪，其中包含著名的 vue-cli 等。
而这个事情的被发现却是很偶然，一个开发者在使用 nodemon（一个 node 监控程序） 的过程中看到了一条 warning：
crypto.createDecipher is deprecated。
正常来说码农都是忽略 warning 的（此处应有狗头），更何论只是一条 api 即将废弃的 warning，但这位开发者较真了，他很好奇为什么一个 node 监控程序的 warning 里会报一个 crypto 的错误呢？由此这个事情才被挖了出来。
令人细思极恐的是，如果不是因为当时恰巧 crypto 变更了 api，说不定这个事情还要继续被隐瞒很久才会被发现。
Ant Design 圣诞彩蛋
Ant Design（Antd）是非常流行的开源 UI 框架。然而 2018 年的圣诞节它是把好多码农吓的不清。开发团队在没有任何特别的情况下，加进去了一个 feature，给它的按钮加了一个圣诞节积雪效果，显然吓坏了许多 2B 项目的客户（或许还有伊斯兰的）。
xz 远程控制后门
xz 是一个压缩程序包，特别底层的那种，被一系列的各种应用依赖，这里面包含了 systemd。而潜伏者 JiaT75 通过三年来持续为 xz 项目贡献补丁，成为了项目的主要维护者。然后他精心的构造了一个非常隐蔽方式，通过项目的构建脚本以二进制的形式将后门植入，甚至在代码里都看不出任何痕迹。最终的效果是后门绕过了 RSA 签名验证，从而允许任意的远程 sshd 控制访问。
这个事情的发现也非常偶然，一名测试老哥偶然的发现 sshd 占用的 cpu 时间很高，然后他追踪下去想找找哪部分代码比较慢时，发现居然没有对应的符号表——因为后门是通过二进制直接植入的嘛。所以老哥觉得不太对劲，这件事就此曝光。
比 event-stream 事件幸运的在于，植入后门的 xz utils 在 Debain testing 阶段就被发现了，可这样的幸运不知道还能有几次。
眼睛太少了
实际上 Linus's Law 本身是无懈可击的，确实只要有足够多的眼睛关注，任何漏洞和后门都不可能隐藏。问题在于根本不存在足够多的眼睛。引人注目的永远是那些新鲜的，热门的项目，而背后的底层项目往往无人问津。
Event-Stream 和 xz 项目都长期只有一个人维护，后门的潜伏者恰恰是极少数真正愿意贡献代码的”开发者“，OpenSSL 在心脏出血漏洞爆发之前，一直只有 1 名开发者，这都是这些悲剧产生的不可或缺的条件。
event-steam 项目的原作者在事后写了一封公开信给社区，里面打了个比喻说：
我曾经在一家餐厅当洗碗工，但我失策了，我因为工作的太出色被提拔为厨子。时薪只涨了 50 美分但要负责的事情一下做多了很多。我感觉不值得。写一个（像 event-stream 一样）的热门模块就是把这个事情放大一百倍
我之前看到一个帖子说: 每天无数人使用的 netfilter 现在只剩一个人在维护，调试神器 strace 只有一个人维护，每天无数人使用的 bash ，group 内只有 3 个 active member，tcpdump/libpcap 维护组中的一位自我介绍是：
sometimes l work jobs for living,sometimes l contribute pro bono to free and open source software projects, often l do both.
给人一种很孤独的感觉。
Alan Kay 说：
"互联网做得太出色了，以至于很多人把它看作某种像太平洋一样的自然资源，而非人造的。"
某种程度而言，开源软件，特别是那些底层的基础设施也做的太出色了，以至于开发者们也把它当成了一种自然资源，而忘记了他们背后也需要开发者的维护。在这种情况下， 这些几乎被遗忘的代码，又哪来的眼睛去关注，去审计代码的里的安全问题呢？
视线的方向
在另一些项目里，社区非常的火热，大家热火朝天的讨论着项目的功能，应用场景，以及影响使用的各种 bug。可是安全呢？issue 里有多少内容是关于项目的安全审查呢？恐怕是很少的，因为这一点都不 cool。
在 Antd 的事件里，圣诞节彩蛋的代码是在社区所有人的眼睛关注下，合入项目的，可当时又有谁提出质疑了呢？每一个 pr 的 code review，确实能做到每行代码的 review 吗？还是测试用例跑通了没有冲突就可以 merge 了呢？
如果视线的方向根本就不在安全的位置，那有再多的眼睛又有什么用呢？
没有相关性
所以开源软件更不安全吗？当然不是的，开源没有让软件更安全，也没有让软件更不安全。是否“开源”，与“安全”之间不存在相关性。
而如何去判断一个开源软件的安全性，只需要看下闭源的商业软件如何判断安全性就好了。商业软件我们会考察开发商的资质，历史项目的表现和行业内的口碑。那自然的判断开源软件的安全性应该考察社区的成熟度和规范性，草台班子在哪儿都不靠谱。
而如何让开源社区变得更成熟，更规范，有更多的开发者能参与到其中，避免 event-stream, xz 这样的悲剧再次发生，这是真正值得关注的地方。
此外，相较于的预防漏洞的披露（实际上也没啥可预防的，根本不在控制之内），及时的漏洞修复对安全的意义更为重要，开源软件至少在这个方面给予了开发者充分的“自主可控”能力。
信任，但验证
漏洞永远都会存在，有研究表明 96%的商业代码中都包含开源软件，我很惊讶——居然不是接近 100%。在这种情况下审计每一份代码确保它的绝对安全是不可能的。但我们至少应该保持有验证能力——即在漏洞披露时，验证自己是否受此影响，并快速修复避免进一步的损失。
log4j 是在 2022 年爆发的，2023 年时有一份安全研究说在其审计的 11%的代码中，依然发现了容易被攻击的 log4j 版本，而他们之所以存在很可能是因为企业的 IT 根本不知道他们使用的产品依赖了这个组件——特别是混杂在商业产品中时。
知己知彼，方能百战不殆。
以上
参考资料
版权声明: 本文为 InfoQ 作者【冯骐】的原创文章。
原文链接:【http://xie.infoq.cn/article/7b9fe9e64fa38d129c25cd4f2】。
本文遵守【CC BY-SA】协议，转载请保留原文出处及本版权声明。
教育行业码农 2020-06-19 加入
一个教育行业的码农
评论