原标题：2019 开源安全报告：开发者安全技能短板明显，热门项目成漏洞重灾区！

  近年来，开源软件的应用限制范围正在逐步扩大，“拥抱开源”似乎也成了一种企业间的普遍趋势。尤其是在 2018 年，科技巨头纷纷加注——微软以 75 亿美元收购了 GitHub；IBM 以 340 亿美元拿下 RedHat，开源软件正在成为现代企业的基础。

  与此同时，暴露于安全漏洞的风险也在逐步增长，开源环境的安全问题开始受到慢慢的变多的关注。而漏洞数量的增幅与开发者自身技能与安全意识提升速度间的断层，也成了一大不容忽视的问题。

  近年来，开源软件的应用限制范围正在逐步扩大，“拥抱开源”似乎也成了一种企业间的普遍趋势。尤其是在 2018 年，科技巨头纷纷加注——微软以 75 亿美元收购了 GitHub；IBM 以 340 亿美元拿下 RedHat，开源软件正在成为现代企业的基础。

  与此同时，暴露于安全漏洞的风险也在逐步增长，开源环境的安全问题开始受到慢慢的变多的关注。而漏洞数量的增幅与开发者自身技能与安全意识提升速度间的断层，也成了一大不容忽视的问题。

  为了更好地了解开源的安全现状，以及相对应的改进手段，针对开源项目提供安全服务的公司 Snyk 对一系列数据来进行了统计分析，并于近日发布了《2019 年度开源安全现状调查报告》，其数据来源包括：

  回顾 2018，我们显而易见在各语言生态系统中，慢慢的变多的开源库被编入索引，且呈现出爆炸式增长。2017-2018 年，索引包增长情况如下：

  据报告显示，开源项目的采用率正在加速增长。仅 2018 年间，Java 包便翻了一番，npm 亦增加了大约 25 万个新包。

  开源软件的消费也在快速的提升。从 PyPI 下载的 Python 包是以前的两倍，从 npm 下载的 Java 包更是达到了惊人的 3170 亿个。

  开源软件的消费也在快速的提升。从 PyPI 下载的 Python 包是以前的两倍，从 npm 下载的 Java 包更是达到了惊人的 3170 亿个。

  注：如上图所示，年中下载数量的激增是由于 PyPI 统计数据收集服务 linehaul 的一个故障，因此漏掉了8 月之前了大约一半的下载记录。据推测，2018 年的下载量为 140 亿次，但实际数量可能要更多。

  注：如上图所示，年中下载数量的激增是由于 PyPI 统计数据收集服务 linehaul 的一个故障，因此漏掉了8 月之前了大约一半的下载记录。据推测，2018 年的下载量为 140 亿次，但实际数量可能要更多。

  npm 注册表是整个 Java ECO的核心。在过去的几年里，其下载数量和软件包数量一直在稳步增长。仅 2018 年 12 月一个月的下载量就超过了 300 亿次，而 2018 年全年的下载量更是惊破 3170 亿次。

  随着软件包数量的增长，它们的漏洞也在增加。Linux 基金会在去年报告称，开源贡献者已经提交了超过 310 亿行代码。然而，随着大量采用，随之而来的是巨大的压力和风险，任何拥有、维护或使用此代码的人都需要承担起降低风险的责任。2017 年，CVE 报告了超过 14000 个漏洞，打破了单年内的最高记录。而这一数据在去年再创新高，披露了超过 16000 个漏洞。

  漏洞就是漏洞，不管是否已知。两者之间的关键不同之处在于攻击者意识到这个漏洞并试图利用它的“可能性”。因此，对漏洞的认识越深入，对其处理的需求就越迫切。

  已知的漏洞可能具有与之关联的 CVE ID，也可能仅仅是在网上披露或存储在开放数据库中。这些都是应该优先消除的已知漏洞类型，因为它们受到攻击的几率更高。再之后就应思考在封闭的漏洞数据库中捕获的漏洞，甚至是在暗网享的漏洞。

  对比查看了过去三年在所有语言生态系统中公开的应用程序库的漏洞严重程度时发现，与前一年相比，2018 年的高危漏洞数量有所减少。

  此外，还有一个有趣的发现，那就是与 2016 年相比，2017 年和 2018 年的一个共同点是，高危漏洞多于中危漏洞或低危漏洞。

  Zip Slip是一个广泛存在的关键存档提取（critical archive extraction）漏洞，该漏洞允许攻击者在系统中任意写文件，尤其是会导致远程命令执行。Snyk安全团队的研究人员6月5日发现并公布了该漏洞的细节，该漏洞影响上千个工程建设项目，其中一些工程来自HP、亚马逊、Apache、Pivotal等。

  当新的漏洞通过国家漏洞数据库（National vulnerability Database, NVD)）或其他公共 CVE 存储库公开时，安全团队通常会跟踪并应对这些漏洞。然而，很多安全漏洞是在非官方渠道中发现和修复的，比如通过问题中维护人员和用户之间的非正式通信。

  开源维护者表示，他们的安全知识正在提高，但还不够高。据调查显示，大多数用户将他们的安全知识列为中等水平，平均 6.6 分（满分 10 分） 63%，而去年这一档的比例为 56%。

  此外，还有四分之一的开源维护者表示不会去审计他们的代码库。去年，44% 的收房的人说他们从未进行过安全审计，而今年，这一个数字倒是降了很多，26% 的用户表示他们没审计源代码的习惯。

  十大最流行的默认 Docker 镜像中，每一个都包含至少 30 个易受攻击的系统库

  20% 的镜像能够最终靠简单地重建 Docker 镜像来修复漏洞；44% 经过扫描的 Docker 镜像能够最终靠更新其基本镜像标记（image tag）来修复已知漏洞。如果你意识到这一点，修复起来会很容易。

  众所周知，Node.js 运行时有许多优点，但有一点必须要格外注意的就是“单线程事件循环”，假如没有正确使用，就极有可能成为其最薄弱的环节。这一情况出现的频率比大家想象的要高。

  ReDoS 攻击利用了一些正则表达式模式可能会引起的非线性最坏情况的复杂性漏洞。对于单线程 runtime 而言，这可能是毁灭性的，这就是为什么 Node.js 会受到这种漏洞的严重影响。

  调查发现，在过去三年里，ReDoS 漏洞暴露的数量慢慢的变多，仅 2018 年就激增了 143%：

  跨站点脚本攻击（XSS）慢慢的变成了 Web 应用程序日渐增长的痛点，2018 年，在 Snyk 一直监控的所有生态系统中，XSS 漏洞呈增长趋势。

  开源库中的 XSS 漏洞仍然在增加，尽管它慢慢的变成了 OWASP（一个组织，全称开放式 Web 应用程序安全项目）这 15 多年来关注的首要问题。

  很难想象在没有一点开源依赖的情况下编写软件的日子。管理项目的依赖关系是一项重要的任务，需要尽职调查来正确跟踪所依赖的库。毕竟，你正在部署的应用程序捆绑了你的代码和依赖项。

  npm、Maven 和 Ruby 中的大多数依赖项都是间接依赖项，间接依赖项中的漏洞占总体漏洞的 78%。

  在 GitHub 今年发布的 GitHub Octoverse 报告中，安全性是最受喜爱的项目集成应用程序类别。这里引用下 Gartner 在最近一份应用程序安全报告中的一段话，该报告讲到了组织在应用程序生命周期中尽早展开安全测试的必要性：

  企业应定期使用 SCA 工具对包含软件资产（例如版本控制和配置管理系统）的存储库进行审计，以确保企业开发和/或使用的软件符合安全和法律标准、规则和法规。应用程序研发人员应该能够访问 SCA 工具来检查他们计划使用的组件。——Mark Horvath, Hype Cycle For Application Security 2018, Gartner

  企业应定期使用 SCA 工具对包含软件资产（例如版本控制和配置管理系统）的存储库进行审计，以确保企业开发和/或使用的软件符合安全和法律标准、规则和法规。应用程序开发人员应能够访问 SCA 工具来检查他们计划使用的组件。——Mark Horvath, Hype Cycle For Application Security 2018, Gartner

  据此次报告显示，将近一半（43%）的受访者至少有 20 个直接依赖项，这增加了监视通过这些库引入的开源漏洞的必要性。

  我们使用开源软件的次数越多，就会积累越多的风险，因为我们包含了其他人的代码，这些代码现在或将来可能包含漏洞。此外，风险不仅和代码的安全性有关，还关乎所采用代码的许可遵从，以及该代码是否违反了开源许可本身。

  应用程序组合非常复杂。作为操作系统维护者和研发人员，可以采取一些行动来提高您所拥有和参与的项目的安全性。

  提供安全的代码版本，并向使用者提供一种通信策略，以便积极地影响其他项目和应用程序，最终使自己的项目也很可能受益；

  如果可能的话，与同行一起进行安全代码评审，并遵循安全代码最佳实践。将安全性考虑作为代码评审检查指标的一部分，并对评审人员进行培训，以便他们了解应该留意什么；

  为团队提供对开发、CI，甚至创建 pull 请求时的安全问题的洞察力，以消除所有进入项目漏洞代码的机会。

  作为开源组件的使用者，您有责任充分理解项目使用的直接和间接依赖项，包括依赖项树中有几率存在的任何安全缺陷：

  定期使用一种工具来审计代码库，该工具可以自动检验测试第三方依赖项中的漏洞，为团队提供修复建议，并监控项目的依赖项（即使在项目部署之后）；

  如果您正在报告安全漏洞，请遵循负责任的披露策略，以确保您不会将用户置于危险境地。如果你不确定怎么样才能做到这一点，可优先考虑向一家与你合作的安全公司披露；

  订阅开源依赖项的安全通信通道（如果有的话），这样就可以在报告时了解任何潜在的漏洞。