2019年开源软件风险研究报告

0nise 1675天前

序言

本报告由 CNCERT 软件安全和苏州棱镜七彩科技有限公司联合发布。

开源软件已经渗透到信息技术领域的方方面面，无论是 CPU、DSP 等芯片，抑或驱动、固件等底层软件，抑或操作系统、浏览器、数据库等系统软件，抑或消息中间件、应用服务器等中间件软件，抑或各种各样的应用软件，都有开源软件的应用。我国信息技术领域各个行业也大量使用了开源软件。对于政府、军工、能源、金融等关键行业，也从以前的“谈开源软件色变”，到现在已经广泛接受和应用开源软件。开源软件已经成为当前软件供应链中十分重要的组成部分。

开源软件为IT行业带来了极大便利，提高了开发效率，降低了成本。然而，由于开源软件的依赖和引用关系较为复杂，其安全性也往往缺少审查和管理，因此，开源软件也增加了软件供应链的复杂性和安全风险。2019 年，Github 的报告指出，超过 360 万个开源项目依赖了 Top50 的开源项目之一。rails/rails、facebook/jest、axios/axios 等知名项目被其他上百万个开源项目使用。同时，开源项目平均有 180 个第三方依赖组件，具体的依赖组件数量从几个到上千个不等。另一方面，NVD、CNVD等漏洞库中的开源软件漏洞数量不断增加，还有大量开源软件漏洞未被收录到这些漏洞库中，例如，被广泛使用的 fastjson 组件，在 2019 年持续出现的严重漏洞中，多个漏洞尚未收录到国家漏洞库中。恶意软件包也不断出现在开源社区中，如 pip 包管理平台的 roels、req-tools 和 dark-magic 等恶意软件包、NPM 包管理器的 m-backdoor、rceat、path-to-regxep 等恶意软件包等。

除了信息安全风险，开源软件还可能引入知识产权风险。由于开源软件的依赖关系的复杂性，在使用开源软件时，不同开源软件的许可证可能存在合规性和兼容性风险，从而导致知识产权风险。2019年11月6日，数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司侵犯计算机软件著作权纠纷一案终审判决，判令柚子公司停止侵权并赔偿 71 万元。该案被称为中国第一个涉及GPL协议的诉讼案件。虽然该案在开源社区中有不同的讨论和解读，但进一步说明了开源软件的知识产权风险，是不可忽视的重要风险之一。

由此可见，开源软件复杂的供应链关系、不断增加的安全漏洞与恶意软件包，以及开源许可证的风险，已成为不可忽视、亟需重视和管控的领域。2020年 4 月 27 日，国家互联网信息办公室、国家发改委等 12 个部门联合发布了《网络安全审查办法》，《网络安全审查办法》中第一条明确指出：“为了确保关键信息基础设施供应链安全，维护国家安全，依据《中华人民共和国国家安全法》《中华人民共和国网络安全法》，制定本办法”。开源软件作为关键信息基础设施供应链中十分重要的组成部分，其安全性也需要重点关注。因此，为了更详细地进行分析，我们从 Github、码云社区中选取了一批开源项目进行分析，就其依赖组件、安全漏洞、开源许可证等方面进行分析。

开源软件的安全风险分析

本报告一共选取了 48,363 个项目进行分析，其中 GitHub 中选取星数为 500 星及以上的开源项目 38,530 个，Gitee 中选取星数为5星及以上的开源项目 9,833个。进一步，使用开源安全检测工具对48363个开源项目进行依赖检测，检测是否含有来自于 Maven、Nuget、Packagist、PyPI、NPM、RubyGems 六个包管理平台的依赖组件。在检测结果中，共有 31,553 个开源项目包含上述六个平台的依赖组件，占总数的比例为 65.24%。在含有依赖组件的开源项目中，来自于 Github 社区的项目数为 25,959个，占比 82.27%；来自于 Gitee 社区的项目数为 5,594个，占比 17.73%。本报告通过对 31,553个含依赖组件的开源项目（下称“样本项目”）进一步进行分析。

样本项目中一共包含 701,724 个来自 Maven、Nuget、Packagist、PyPI、NPM、RubyGems 六个平台的依赖组件，其中 Github 的样本项目包含 535,326 个依赖组件，占比 76.29%，Gittee 的样本项目包含 166,398 个依赖组件，占比 23.71%。通过对样本项目的依赖组件安全性进行分析，共获得依赖组件漏洞警告信息 83,834 条。其中，总样本项目的 20.79% 存在依赖组件漏洞，按开源社区划分，18.03% 的 Github 样本项目包含依赖组件漏洞，33.63% 的 Gitee 样本项目包含依赖组件漏洞。基于以上数据，本报告从样本项目的依赖组件安全风险、漏洞等级分布、开源许可证等维度进行进一步分析。

组件安全风险分析

组件安全风险宏观分析

样本项目的组件漏洞数量持续增长

组件漏洞数量及其增长态势是宏观上衡量开源安全风险的重要指标，根据以上数据分析可知，开源项目依赖组件漏洞数量逐年增长，近 4 年中 2019 年增长最快，2019年组件漏洞数量相较 2018 年环比增长72.99%。2019年，Github 样本项目的依赖组件漏洞数量环比增长 71.05%，Gitee 样本项目的依赖组件漏洞数量环比增长 74.18%。以上表明，组件漏洞数量一直处于较高增长态势，成为开源项目不可忽视的重要漏洞来源之一。

（注：本报告组件漏洞数量是指开源项目中依赖组件中的漏洞数量。年度组件漏洞数量指截止当年末为止的历史累计组件漏洞总量。漏洞知识库以 CVE 漏洞为主，也含有部分开源社区漏洞来源，如Github、NPM等。）

多数组件漏洞集中于少数包管理器平台

在本次分析的 6 个主流包管理器 Maven、Nuget、Packagist、PyPI、NPM、RubyGems中，Maven组件漏洞数量最多，占比 73.54%，Maven 组件漏洞数在近 4 年中每年均远多于其它包管理器，并在近两年中大幅增长，2019年环比增长达到 76.53%。NPM 位居第二，占比 16.11%，但仍与 Maven 差值巨大。其它包管理器则一直维持在增长较为缓慢、漏洞数较少的水平。总体而言，大多数组件漏洞集中在少数包管理器平台。

直接依赖漏洞数量比间接依赖漏洞数量少约 10%

软件工程中所包含的开源组件按依赖层级分为直接依赖组件与间接依赖组件，软件工程所依赖的第一层级的开源组件被称为直接依赖组件，第一层级以及更深层级开源组件所依赖的开源组件被称为间接依赖组件，直接依赖组件漏洞和间接依赖组件漏洞都是不可忽视的安全风险。依据依赖组件漏洞数量的总体结果分析，直接依赖漏洞的数量为 37,865 个，占比为 45.17%，间接依赖的漏洞数量为 45,969 个，占比为 54.83%。直接依赖组件的漏洞数量比间接依赖组件的漏洞数量少约 10%。同时，由于间接依赖关系需要对组件的依赖关系进行多层次分析，间接依赖组件漏洞相比直接依赖组件漏洞更具隐蔽性。

样本项目组件漏洞危害性分析

超半数组件漏洞具有较高危害性

根据安全漏洞的危害程度不同，由美国国家基础设施咨询委员会 NIAC（TheNational Infrastructure Advisory Council）发布的通用漏洞评估方法 CVSS（CommonVulerability ScoringSystem）将安全漏洞分为超危、高危、中危、低危 4 个等级的漏洞。根据本报告统计结果，组件漏洞多集中于中危及以上等级，占比94.38%；其中，中危等级的组件漏洞数量最多，占比 35.26%，超危与高危组件漏洞数量分别为 31.44% 和 27.67%，低危漏洞较少，占比 5.62%。超危与高危组件漏洞数量之和占比达64.49%。总体而言，中危及以上漏洞即已具有一定危害性，而其占比达 94.38%，高危及以上漏洞则具有较高危害性，而其占比达 64.49%，显而易见，依赖组件的安全漏洞是不可忽视的重要安全风险之一。

高危及以上组件漏洞数量不断增长，安全风险持续升高

超危、高危组件漏洞数量近年来一直保持着较高的增长率，2017 年相较 2016 年环比增长 172.91%，2018 年环比增长 108.37%，2019 年环比增长 103.96%，超危、高危组件漏洞数量历年均保持着大于100%的较高的增长率。Github 样本项目和 Gitee 样本项目的超危与高危漏洞数量也基本符合这一规律。而在实际开发中，组件漏洞被发现后，大量开源组件的漏洞修复周期也较长，不能做到对组件漏洞的及时响应。据英国安全厂商 Snyk 调研，37% 的开源开发者在持续集成（CI）期间没有实施任何类型的安全测试，25% 的开发者在发现漏洞后未通知用户有漏洞，从漏洞添加至组件到修复漏洞的时间中位数也超过 2 年，而超危、高危漏洞的危害性较高且占比较高，若大量开发者未能做到对漏洞的及时响应，将对组件使用者带来较高的安全风险。

约80%的高危及以上的组件漏洞来自Maven组件

各包管理器每年的超危、高危组件漏洞数量均在不断变化，上表反映了各包管理器每年的超危、高危组件漏洞占超危、高危漏洞总数量的比例的变化情况。尽管Maven平台高危及以上的组件漏洞在2016-2018年期间占比略微下降，但仍旧在每年中均保持最高占比，平均每年占比超80%，并超出位于第二名的NPM至少65%。而除了Maven和NPM外的其它包管理器则一直处于占比较低的状态。总体而言，历年大部分的高危及以上的组件漏洞来自于Maven组件，也侧面说明了Maven组件使用范围较广，Maven组件漏洞的影响范围也相应较广。

被引用次数最多的含高危及以上漏洞的组件 Top10

开源组件被引用的次数越多，软件开发者直接或间接依赖到该组件的可能性越大，如果该组件包含高危及以上漏洞，安全风险越高，安全风险影响范围也越广。了解各包管理器中被引用最多的高危组件信息，对于开源安全风险防范至关重要。本报告从样本项目依赖组件中按包管理器分别选取了被样本项目引用次数最多的且包含高危及以上漏洞的组件 Top10，其中，图中横坐标表示该组件被样本项目引用的次数：

1. Maven

2. Nuget

3. Packagist

4. PyPI

5. NPM

6. RubyGems

开源许可证分析

本报告对样本开源项目与依赖组件（来自于 Maven、Nuget、Packagist、PyPI、NPM、RubyGems 这 6 个包管理平台的依赖组件）的许可证使用情况进行了统计，无论是开源项目还是依赖组件，MIT 和 Apache-2.0 许可证占比最多。依赖组件许可证中，MIT 占比 55.58%，Apache-2.0 占比 14.94%；开源项目许可证中，MIT 占比32.93%，Apache-2.0 占比 14.84%；AGPL-3.0、LGPL-2.1、LGPL-3.0、GPL-2.0、GPL-3.0 占比最少，5 个许可证占比之和不足 10%。依赖组件中，未在社区网页申明许可证的占比仅为 2.88%，而在开源项目中，未在社区网页直接申明许可证的占比为 39.44%。当然，开源项目许可证存在一种情况，即未在社区网页直接申明，而将许可证声明放到源代码项目中。因此，实际未申明许可证的开源项目比例会略低于 39.44%，但侧面反映了开源项目中，未申明许可证的开源项目数量较多。对于未申明许可证的开源项目或开源依赖组件的使用，可能存在侵权风险。

许可证兼容是指不同许可证的开源项目，能在同时不违反所有开源项目许可证的前提下进行合并或者融合，反之则成为许可证不兼容。许可证兼容性风险是使用开源软件时面临的常见风险。开源许可证可以简单划分为宽松型许可证和著佐权型许可证。例如 MIT、Apache-2.0、BSD-2-Clause、BSD-3-Clause属于宽松型许可证，AGPL-3.0、LGPL-2.1、LGPL-3.0、GPL-2.0、GPL-3.0 属于著佐权型许可证。开源软件或依赖组件在混合使用时，由于不同的开源软件或依赖组件具有不同的开源许可证，因此可能存在许可证兼容性风险。

本次分析中，2,372 个样本项目存在许可证兼容性问题，占比 7.52%。这些项目中，有的使用了许可证不兼容的依赖组件，有的是依赖组件许可证与项目自身的许可证不兼容。例如 Mycat-Server 项目，其项目许可证为 GPL-2.0，项目中使用的依赖组件的许可证有 Apache-2.0、GPL-2.0 等。但由于 Apache-2.0 存在某些专利条款和赔偿条款，而 GPL-2.0 未做相关要求，导致 Apache-2.0 与 GPL-2.0 不兼容。因此，当整个项目在 GPL-2.0 许可证下，整个项目就存在兼容性问题。