开源软件安全性分析

一. 引言

开源软件（Open source software, OSS）是指一种可查看、可修改的公开计算机程序，它对我们今天的软件开发产生了巨大的影响。从宏观分析，几乎所有的应用程序都会应用第三方开源软件，复杂的软件间调用和不同软件版本上下游依赖形成了一条多个软件和多层依赖关系的供应链。然而，在开源软件带来高效开发的同时，也带来了快速增长的软件漏洞的安全问题。对于那些有意破坏网络安全环境的人或组织而言，针对软件供应链的攻击是一个极具吸引力的切入点。本文将从两方面出发，先对本年度的开源安全现状进行分析和说明，然后针对软件生态系统中存在的安全问题，总结了多种开源软件的安全研究动态。

二. 从一份报告看开源现状

本节引用synk.io公司发布的开源安全调查报告，针对2021年4月至2022年3月收集的130多万个项目，从OSS的开发组织、软件依赖关系、关联漏洞等维度了解开源世界的安全现状，并总结了不同组织在维护OSS安全性上的做法。

2.1

安全现状

从OSS开发者（或组织）视角看，只有49%的组织拥有OSS开发的安全策略，34%的组织表示他们没有使用安全策略。OSS的安全策略是一套安全行动计划，表明开发者已对软件的安全性进行评估，并具备应对突发安全事件的能力。而调查结果表明，各组织未将软件安全作为优先考虑的事项。

对比不同规模的企业的执行安全策略的情况上看，发现大、中、小型企业对安全策略的应用情况具有明显差异。由于预算、时间和资源等局限性，中小型组织的IT人员更重视软件的功能性而不是安全性。

从漏洞角度上看，使用者很难对OSS复杂依赖关系及漏洞进行管理，如下图所示，只有24%的使用者对其在直接依赖关系上的安全性有信心。由于软件供应链中存在大量的直接和间接依赖，故使用漏洞扫描工具对其进行信息识别会产生许多误报，例如：如果依赖路径上的漏洞从未被执行，那么这种漏扫结果将是无效的。

企业的安全团队越来越意识到，企业的安全不完全取决于他们的组织，相反，他们必须越看越远，弄清楚“这段代码是哪里来的？”，因此，清楚每个项目的依赖数量是理解代码安全性的起点。如python的平均依赖数为25，而JavaScript的依赖数为173，从数量上看JS的依赖关系更复杂。但深入到依赖项内部，多用途的库会比单一用途的库更为复杂，在这个角度上JS反而更加“单纯”。

我的项目中有多少漏洞？下图直观的说明了不同生态下的感染风险——.Net项目平均每个项目有23个漏洞，Go为34个，Java为90个，JavaScript为47个，Python为36个。其中，如何识别出可传递依赖的漏洞是DevOps最困难的挑战之一，考虑一个项目依赖50个开源软件，如果平均一个开源软件公开5个关键漏洞，那么仅第一级（直接）依赖就可能导致200+个关键漏洞。

2.2

如何提升OSS安全性

漏洞发现的方法。调查中39%的开发者使用SAST，该工具在开发过程中非常有用，因为它们可以作为CI（持续集成）过程的一部分自动运行，并且通常可以识别导致漏洞的特定代码行。33%的组织采用的是使用SCA（软件组成分析）工具，该工具通过清单扫描和二进制扫描来识别已知的安全漏洞、许可问题或质量问题。最后，可以在IDE中使用SAST工具，为开发人员提供一种更直接、更实际、更可配置的手动安全测试方法。

保障OSS安全性的方法。最常见的方法是让开发人员自己检查源代码，这种评审可以充分说明代码的质量并保障代码的安全性。40%的组织依赖项目社区来评估项目安全性，此时他们会通过社区提供的贡献者信息和维护方式来作为项目安全性的评价标志。36%的组织采用第三方工具帮助开发人员评审软件安全性。剩余组织还考虑了其他评价因素，如开源项目发布或提交的频率（35%）、注册及包管理器信息（33%）以及存储库评级（30%）等。

三. 开源组件的安全研究

本节总结了6篇与开源安全相关的论文，研究方向包括供应链生态分析、开源软件漏洞风险分析、开源软件应用风险分析和软件识别。

（1）供应链生态分析

在《On the impact of security vulnerabilities in the npm package dependency network》一文中，作者对610k个npm包的安全报告进行分析，通过5个分析维度来及时发现包中存在的漏洞，并确定漏洞在依赖上的传播路径。分析维度包括：被感染数量，感染修复时间，漏洞被发现时间，是否修复，下游依赖是否及时更新等。

（2）开源软件漏洞风险分析

在《PDGraph: A Large-Scale Empirical Study on Project Dependency of Security Vulnerabilities》一文中，研究者对maven软件漏洞数据构建软件依赖图，再基于依赖图和软件数据来分析软件的感染情况。这种软件依赖图可以较为直观的评估、分析各个生态下软件漏洞的感染情况。

在《Open or Sneaky? Fast or Slow? Light or Heavy?:Investigating Security Releases of Open Source Packages》中，作者对软件漏洞修复commit和实际修复版本的时间差别进行分析。具体而言，文章针对maven，pip等7中主流生态，量化了security fix和release的时间差，分析了release note中记录的安全fix信息，最后通过这些差异分析判断软件漏洞修复是否及时，文档是否健全，来给用户选择软件提供参考并对软件维护者提出漏洞修复建议。

在《Facilitating Vulnerability Assessment through PoC Migration》中，作者通过Poc测试确定软件是否存在漏洞，同时精确漏洞公告中的受感染版本范围，如1.2.1—1.2.9 受到影响，则需要确定受到影响的软件的所有版本。

（3）开源软件应用风险分析（投毒）

在《LastPyMile: Identifying the Discrepancy between Sources and Packages》中，研究了开源包管理（仓库）中的开源软件与真实软件包的差异识别方法，从而防止恶意软件注入。具体而言，方法收集pypi包的github链接，元数据，主页，包内容，历史commit以计算所有文件的哈希值和代码行数，最后与pypi包做对比发布差异报告和检测方法论。

（4）软件识别

在《OSLDetector: Identifying Open-Source Libraries through Binary Analysis》中，利用二进制分析检测多平台软件第三方库重用，并且能够识别许可证冲突和漏洞风险。OSLDetector分为四个部分：OSCCollector该部分从pkgs.org中检索第三方库信息并下载开源库并收集许可证和漏洞信息，OSCExtractor从二进制文件中获取常量字符串特征，并且删除过短特征做预处理，使用tf-idf确定每个特征的权重，OSCMatcher使用一种特征集的匹配率指标规则确定包是否重用，OSCManager开源包展示平台，显示各种包的许可证冲突，漏洞报告。最终在数据集上的效果达到92.3%的召回率和96%的准确率。

四. 总结和展望

使用开源软件的组织和公司需要更加了解他们正在使用的依赖关系，主动并定期监控所有软件的可用性、可靠性和漏洞。最终，开源软件是一条双向的道路：开源软件的消费者必须对OSS社区做出贡献，以确保他们所依赖的依赖关系的健康和可行性。仅仅使用开源软件而不做出贡献是不够的。所需要的是：1）将开放源码软件依赖的性质纳入标准网络安全和开发实践，2）为组织所依赖的开放源码软件社区做出贡献。

内容编辑：创新研究院 卜天

责任编辑：创新研究院 陈佛忠

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们

绿盟科技研究通讯由绿盟科技创新研究院负责运营，绿盟科技创新研究院是绿盟科技的前沿技术研究部门，包括星云实验室、天枢实验室和孵化中心。团队成员由来自清华、北大、哈工大、中科院、北邮等多所重点院校的博士和硕士组成。

绿盟科技创新研究院作为“中关村科技园区海淀园博士后工作站分站”的重要培养单位之一，与清华大学进行博士后联合培养，科研成果已涵盖各类国家课题项目、国家专利、国家标准、高水平学术论文、出版专业书籍等。

我们持续探索信息安全领域的前沿学术方向，从实践出发，结合公司资源和先进技术，实现概念级的原型系统，进而交付产品线孵化产品并创造巨大的经济价值。