安全行业的支柱
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实践也很难搞定赛博空间的信任关系，谷歌最终采取的做法是各种沙盒隔离，软件安全任重道远，怎做得更好值得我们重新思考。
在现在如今开源组件、供应链安全越来越火的时代，正是一个安全最动荡的时代。
声明：本文来自安全乐观主义，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
