2018 年开源状况：代码贡献超 310 亿行，而漏洞超 16000 个

几年前，“开源”还是点点星火，如今已成燎原之势。在过去的 2018 年，企业都在积极加强自己在开源方面的实力，IBM 大手笔 340 亿美元收购了 RedHat，微软 75 亿美元收购了 GitHub。

开源软件蓬勃发展的同时，安全漏洞风险也在增加。SNYK 不仅向 500 多名开源用户和维护人员分发了调查报告，同时也监控了 SNYK 内部监控和保护的数十万个项目的漏洞数据，并结合外部研究，发布了 2019 年开源安全状况报告。

首先，我们先来看几个关键性结论：

• 2017 年到 2018 年，包管理 工具 索引的开源包数量呈爆炸式增长，其中 Maven Central 增长了 102%，PyPI 增长了 40%，NPM 增长了 37%，NuGet 增长了 26%，RubyGems 增长了 5.6%。

• 应用程序的漏洞在短短两年的时间内增加了 88%，其中 SNYK 跟踪的 Rhel、Debian 和 Ubuntu 的漏洞数量，2018 年是 2017 年的四倍多。

• 最受欢迎的默认 Docker 映像 Top 10 中的每一个都至少包含 30 个易受攻击的系统库，其中 44% 可以通过更新 Docker 映像来修复已知漏洞。

• 调查显示，37% 的开源开发人员在 CI 期间不会进行任何的安全测试，54% 的开发人员不会进行 Docker 映像的安全测试，而从漏洞出现在开源包中到漏洞修复的时间可能会超过两年。

* 调查显示，81% 的调查者认为开发人员应该负责开源安全，68% 的调查者认为开发人员应承担 Docker 容器镜像的安全；但只有十分之三的开源维护人员认为自己应该具备较高的安全知识。

开源应用

开源软件对现代软件开发产生了深远的影响，并且这种影响力还在每年递增。据 GitHub 报告称，2018 年新用户的注册量超过了之前六年的总和，且平台上创建的新组织和新存储库增加了 40%。另外，开源软件同时也推动了语言和平台的发展，影响了行业增长，Forrester 报告称，开源软件是业务技术战略的重要组成部分。

前文我们曾提到，科技公司都在大量使用开源，每个编程语言生态系统中都有越来越多的开源库被索引，且有的增长率实现了两位数，甚至是三位数的增长（Maven Central 实现了 102% 的三位数增长。）

开源的使用正走在高速路上，2018 年 Java 包增加了一倍，NPM 增加了大约 250000 个新包。

据 Linux 基金会报告称，2018 年开源贡献者提交了超过 310 亿行的代码，这些代码一旦要在实际的生产环境中使用，那么拥有、维护和使用此代码的人就必须承担一定的责任，规避风险。

据 CVE 列表报告显示，2017 年总共有 14000+ 个漏洞，打破了 CVE 一年内报告的漏洞记录，而 2018 年，漏洞数量继续上升，超过了 16000 个。

我们在调查中关注了不同生态中不同软件包的下载数量，同时也关注了这些开源软件包如何转化为用户采用。

根据 Python 注册表显示，PYPI 在 2018 年的下载量超过 140 亿，相比于 2017 年报告中的 63 亿，下载量增加了一倍。从下表中我们可以看到在 8 月份的时候，下载量出现了激增的情况，这是由于 LineHaul（PYPI 的统计收集服务）出现故障造成的，该故障导致在 8 月之前大半的下载量丢失。

另外，开源软件消费也取得了巨大的飞跃，从 PYPI 中下载 python 包的数量是原来的两倍，从 NPM 下载 javascript 包的数量更是惊人，达到 3170 亿个。

NPM 注册表是整个 JavaScript 生态系统的核心。在过去的几年中，无论是添加还是下载的软件包数量都稳步增，仅 2018 年 12 月的一个月时间就有 300 多亿次。

而 Docker 的采用也促进了开源软件的增长，据悉，Docker 公司在 2018 年每两周就有超过 10 亿个容器下载，截止到目前，数量约有 500 亿个。仅 2018 年一年就有超过 100 万个新的应用程序添加到 Docker Hub 中。

风险和影响

而伴随着软件包数量的增加，是漏洞的增加，前文我们提到了 2018 年新漏洞数量再创新高，超过 16000 个。

在 GitHub 发布的 Octoverse 报告中，Security 成为了最受欢迎的项目集成应用程序。而 Gartner 的行业分析师在最近的一份应用程序安全报告中也表示企业应该在应用程序生命周期中尽早测试安全性。

开源软件使用的越多，代码中自然就包含了更多其他人的代码，累积的风险就会越大，因为这些代码目前或者是将来可能会包含漏洞。当然，这里的风险并不单单是指代码的安全性，同时也包括了所采用代码的许可以及该代码是否违反了许可证本身。

在接受调查的受访者中，43% 至少有 20 个直接依赖关系，这无疑就需要增强对这些引入库的源码的监控。而事实上，只有三分之一的开发人员可以在一天或更少的时间内解决严重性漏洞。

“企业应定期使用 SCA 工具来审计包含软件资产（如版本控制和配置管理系统）的存储库，以确保企业开发和使用的软件符合安全和法律标准、规则和法规。另外，应用程序开发人员也可以使用 SCA 工具来检查他们计划使用的组件。

如今，没有开源依赖的情况下写代码几乎是不可能完成的任务，所以正确跟踪所依赖的库就成为了一个难题。采取何种措施才能既消除漏洞，同时还能保持依赖项之间的兼容性？

NPM、Maven 和 Ruby 中的大多数依赖项都是间接依赖项，由少数明确定义的库请求。在调查中，Snyk 扫描了 100 多万个快照项目，发现间接依赖项中的漏洞占整个漏洞的 78%，这说明我们需要进一步增强对依赖树的洞察，并突出脆弱路径的细微差别。

开源维护者的安全状况

虽然在大多数开发人员和维护人员都认同在构建产品和编写代码时，安全性是非常重要的，但是对他们而言，在构建开源项目时没有“教科书式”的规则可供他们参考，因此安全标准可能有很大的不同。

在今年的调查中，大部分用户（平均每 10 个用户中就有 6.6 个）都将他们的安全技术选择在中等水平，7% 的受访者认为目前的安全技术水平较低。

相应的专业知识排名，2019 年的排名发生了一些变化，尤其是 High 和 Low，其中 High 占据了 30%，Medium 占据了 63%，而 low 占据了 7%，而在 2017 年，High 只占了 17%，low 占了 26%。

在调查过程中，我们还发现了维护人员通常都会将时间和经历放在项目的功能性方面，而往往忽视了安全性。

安全审计

安全审计作为代码审查的一部分，其中需要双方确保遵循安全代码最佳实践，或者采取另一种方式，即通过运行不同的安全审计变体，如静态或动态应用程序安全测试。

无论是手动审计还是自动审计，它们都是检测和减少应用程序中漏洞的重要组成部分，并且应该在开发阶段尽可能早地定期执行，以降低后期暴露和数据泄露的风险。

去年，有 44% 的受访者表示他们从未进行过安全审计，而今年，这一数字要低得多，只有 26% 的用户表示他们没有审计源码。与去年的报告相比，今年重复审计也呈现出了积极的趋势，以季度和年度为单位，有 10% 的用户会经常的审计代码。