Fastjson究竟犯了哪些错？

安全行业的支柱fastjson究竟犯了哪些错？没有cve编号著作权法规问题漏洞奖励的难处开源项目的生意经结语

安全行业的支柱

Fastjson罪大滔天，搞到百姓怨声载道，但其实是安全行业的基石，是安全从业人员的重要保障。

脉脉的网友评论

答案一定是fastjson

调侃归调侃，升级fastjson是典型的正确的做事，但没做正确的事。一件事安全和开发人员反复犯错误，说明这件事本身的逻辑和认知出现了问题。

笔者就以fastjson为例深入聊一下开源软件容易犯的错误，以及开源软件在维护安全方面的难点。

fastjson究竟犯了哪些错？

没有cve编号

Fastjson最为人诟病的一点是漏洞公开不规范。威胁情报和SCA（软件成分分析）的基础工作经常从跟踪CVE(CommonVulnerabilities&Exposures)漏洞编号开始，现在除了MITRE Corporation、CERT可以向研究人员和信息技术厂商分发CVE-ID编号，对有大量的用户基础而且且公司具备安全能力的软件厂商，如苹果、Adobe、Red Hat、、Github、VIVO等公司也是CANs成员，可以根据CVE-ID编号池分发漏洞编号。

阿里巴巴在2017年就作为CNA成员，承诺关注Github（https://github.com/alibaba）上的项目安全问题，详情参见 https://cve.mitre.org/data/board/archives/2017-08/msg00001.html，但是实际查询显示阿里系的产品自从17年后就不存在任何cve漏洞编号。

没有cve编号

根据fastjson关键字也搜索不到任何cve编号，而相比jackson居然有26个CVE漏洞，充分说明fastjson软件相比于其他JSON解析工具是具备相对的安全性的：）。

诚然检测这类的底层解析组件并不像sql、xss那么好检测，STA也解决不了问题，所以用户可以接受软件有漏洞，但是不能接受安全响应不规范。

著作权法规问题

众所周知使用开源软件并非是为所欲为。相比如GPL协议，fastjson使用了较为宽松的Apache 2.0协议，说明fastjson是作为一款开放的软件，出现任何安全问题都需要全球社区共同维护。 笔者注意到fastjson部分核心代码使用来自法国电信员工Eric Bruneton博士发布的asm项目源码。

复杂的代码来源 而根据ASM的官方协议https://asm.ow2.io/license.html，明确使用的是一个特殊的3-Clause BSD协议，版权要求以该协议代码为基础做二次开发时这份源代码必须：

一、源代码中必须带有原来代码中的BSD协议。显然fastjson没有这么尊重代码作者的著作权，直接去掉copyright，复制修改到源码的com.alibaba.fastjson.asm目录下。

二、再者要求不能将ASM用于广告推广，但是fastjson的软文显然也没有这么做。

阿里云的软文

fastjson事实上由多个开发人员分别上传的，不能保证代码是否包含其他更严重的违法代码。

代码贡献者众多

比较下另一款阿里巴巴出品BeeHive和“开源JDK“dragonwell8使用的是GPL协议，https://github.com/alibaba/dragonwell8/blob/master/LICENSE，GPL 许可证规定，只要你的项目包含了 GPL 代码，整个项目就都变成了 GPL（像不像病毒？）。也就说如果软件是非开源的，那么是不可以把GPL 下的软件源代码使用到该的程序中的。倘若你非得使用该开源代码，那么你只有把你原先的非开源的代码免费并贡献给社区。

吐槽开源协议

京东有个TigLab项目使用了开源代码SeaweedFS，引入的版权不规范的情况被称为抄袭，引起了严重的PR事件，阿里巴巴也应该引以为戒。

所以企业引入开源软件除了要审查漏洞外，更重要的是要彻底地进行外部第三方软件安全审查和法律规避。

漏洞奖励的难处

作为开源出去的产品，处置漏洞的价值观会很纠结。阿里巴巴SRC最早不接受对开源项目的漏洞奖励的，今年才有了官方的奖励计划，这么做对于其他甲方是值得鼓励的。但是阿里云尴尬在于自家也是提供安全服务的，如果fastjson认为出现安全问题”先内部升级再对外公布是正常流程“，那么这个逻辑是值得思考的。

因为在漏洞反馈-内部升级之间有时间差。现在fastjson通过SRC提供了漏洞收集渠道，难免会让一般客户有心理落差：fastjson使用者是完全暴露在风险中的，而阿里云团队掌握0day却不告知其他人，信息的不对等让用户只能迟滞升级。

大多数用户都能接受存量系统fastjson要升级的事实，但是不能接受阿里扔出来一个饵，在大用户量的情况下在”挟天子以令诸侯“，自己掌握漏洞却不主动公开。

开源项目的生意经

项目开源并不是程序员为爱发电，除了为了晋升程序员会开源来扩散影响力，各公司总免不了通过开源来尝试探索商业模式，开源项目的商业模式基本上分为三类：

订阅模式。开源许可证免除了厂商对软件质量与软件缺陷修复的责任，厂家可以对订购了客户提供及时的bug修复和安全问题跟进，成功的有Redis、Kafka 、Redhat和MongoDB 。这个订阅费价格不菲，以阿里系频繁出现的安全漏洞来说，估计拉不上客户：）。

云服务。阿里系尝试过想项目中加入推广的引流广告链接，链接到阿里云的Data Lake Analytics等系统上，后来被喷的太惨。

广告是不符合程序员认知的

生态收益。最为典型的是谷歌的安卓开源生意经，通过建立软件生态绑架用户和开发者，尝试用社区的力量和闭源商业公司建立竞争优势，这条路不太好走，比如百度开源自动驾驶，旷视开源深度学习框架，都是想找到更多能在产业落地的算法和部署的方案。fastjson最早是startagent下的一个简单功能，发展为有这么多用户但是后续难以维护变现，startagent倒是和edas结合，收益效果不错。

我们总以为是白嫖开源软件，其实是厂家白嫖了程序员，所以得自己为安全负责，免费的是最贵的。

结语

但是读者们请知道漏洞并不仅仅是攻和防、修复和升级那么简单，背后的原因是复杂的，开源项目各有各的难处。笔者并不是为了fastjson辩诬，实际上任何一款软件如何保证各个生命周期的安全性都是很复杂的，商业投入的SCA软件组成分析工具只是做了一小部分信息收集和匹配的工作，人力投入的linux源代码让Linus Torvalds每个commit代码审计也有漏洞。

世界上最好的SDLC实践也很难搞定赛博空间的信任关系，谷歌最终采取的做法是各种沙盒隔离，软件安全任重道远，怎做得更好值得我们重新思考。

在现在如今开源组件、供应链安全越来越火的时代，正是一个安全最动荡的时代。