编程语言安全性排行榜：Ruby 最佳，C 语言漏洞最多？

IT 技术圈有一个永远无解且有争议性的问题，那就是“谁是最好的编程语言？”事实上，由于各种编程语言的特性、应用场景不同，它们是各有长处的，但是 Whitesource 另辟蹊径，从安全性方面来衡量一下谁才是最好的编程语言？

评判方法：

我们经常会听到这样的声音：“XX 语言比 XX 语言更安全。”其实，编程语言的安全性也取决于多种因素，为了避免引起歧义，我们先来阐述一下评判方法。

本文中关于安全性的评判标准是基于 Whitesource 的综合数据库，该数据库汇集了来自多个来源的开源漏洞信息，如国家漏洞数据库（NVD）、安全咨询、Github 问题跟踪程序和流行的开源项目问题跟踪程序。

Whitesource 综合数据库涵盖了 200 多种编程语言，在此次研究中，我们挑选了过去几年在开源项目中最流行的其中编程语言，C、Java、JavaScript、Python、Ruby、PHP 和 C++。

在评判时，我们将参考这些编程语言的已知的开源安全漏洞的数量、这些漏洞随时间的严重程度以及常见的 CWE。

谁是最安全的编程语言？

从上图中，我们可以看到在这些编程语言中，C 语言的漏洞数量是最多的，占到了过去 10 年报告中的所有漏洞的 47%。

这也使得很多人容易根据这个结果认为 C 语言最不安全，但其实事实并非如此。首先，C 语言是初学者最常使用的编程语言，产生漏洞的几率无疑就增加了。其次，C 语言的使用时间比大多数语言都长，理所应当的会更容易受到攻击。第三，C 语言还是 Open SSL 和 Linux 内核等主要基础架构背后的语言之一。

如果单从安全漏洞数量的维度来看，Ruby 是最安全的编程语言，而 C 语言是最不安全的编程语言。

随着时间的推移，每种编程语言安全漏洞的变化

从图中我们可以看到，每个编程语言都有自己的安全高点和低点，但是在过去的两年中，所有编程语言的安全漏洞都出现了大幅的增加，其背后的原因主要是开源的普及和大众对于开源组件安全漏洞的认知提高。另外，自动化工具和对 bug 奖励计划的大量投资也促进了安全漏洞数量的大幅增加。

高严重性漏洞的变化情况

接下来，我们来重点关注一下高严重性的漏洞（在通用安全漏洞评估系统 CVSS v2 中高于 7 的漏洞）。

从上图中我们可以看到，虽然 2017 年安全漏洞的数量激增，但是除了 JavaScript 和 PHP 之外，报告中涵盖的大多数语言中高严重性漏洞的百分比都在下降。

而这得益于发现安全漏洞的自动化工具。这些工具能够很好的发现漏洞，但是漏洞的严重程度并不高，这也是我们看到中等严重的漏洞数量增加的原因。

不同语言的不同安全漏洞（CWE）

为了更加严谨的研究各种编程语言的安全性，接下来我们要检查每种语言中出现的漏洞类型，同时为了方便理解它们的弱点和长处，我们分析了随着时间的推移在每种语言中发现的 CWE 类型。

从图中我们可以看到站点脚本（XSS）（也称为 CWE-79）和输入验证（也称为 CWE-20）是出现频率最高的 CWE。除此之外，其它出现频率较高的 CWE 包括 信息泄漏 / 泄露（CWE-200） 、 路径遍历（CWE-22） 、权限和访问控制（CWE-264）。

当漏洞变得越来越流行时，会有解决这个问题的框架出现，同时开发人员也会对该漏洞越来越熟悉了解，所以，可能在可预见的未来这个漏洞就会消失。

各编程语言的安全漏洞情况

C 语言

C 语言是目前为止漏洞最多的语言，虽然在这十年中漏洞数量会出现上升和下降的情况，但是 C 语言的漏洞数量一直是远超其它编程语言的。

C 语言安全漏洞：按严重程度

C 语言的漏洞数量实在逐年增加。2018 年，C 语言的低严重性漏洞发生率相对较低，只有 7%。另外，C 语言是唯一存在大量内存损坏问题的语言，而这些问题被认为是一种关键的脆弱性类型。

C 语言安全漏洞：CWE

缓冲区错误（CWE-119）是 C 语言中最常见的安全漏洞，类似于 C++ 的漏洞配置文件。大多数的编程语言的 CWE 都与 Web、Web 服务相关，缓冲区错误和其他相关的 CWE 是不可能在管理语言中出现的。

需要注意的是，这组漏洞（有时称为内存损坏）通常会产生严重后果。

C 语言中的每个项目的安全漏洞

构建在 C 语言之上的开源项目很容易被跟踪。从上图中，我们可以看到，Linux 漏洞几乎总是在 C 语言中占很大比例的漏洞。2016 年年中，我们发现了一个臭名昭著的名为 ImageCritical 的漏洞，为了确保安全，安全研究人员对其进行了大量的研究，因此我们可以看到 ImageCritical 在 2017 年呈现出了异常的增长。

Java

从上图中，我们可以看到 Java 的严重性安全漏洞一直维持在 75%z 左右，而高严重性安全漏洞在最近两年增加到了 20%。

Java 安全漏洞：CWE

从上图中我们可以看到在 Java 的 CWE 中有一个很特别的漏洞类型——反序列化问题（CWE-502），这是在所有调查的编程语言中 Java 所独有的一个漏洞类型，PHP、Ruby 和 Python 中没有出现反序列化的问题，这到底是研究人员还没注意到这些编程语言的反序列化问题还是序列化在其它语言中更安全呢？

JavaScript

JavaScript 安全漏洞：按严重程度

JavaScript 是唯一一个在过去 10 年中安全漏洞不断增加的编程语言，其 2017 年的安全漏洞数量是 2016 年的 16 倍，而 2018 年安全漏洞数量又增加了 50% 以上。

为何 JavaScript 的安全漏洞会一直增长呢？研究人员表示：“主要原因可能是 JavaScript 作为后端语言变得越来越流行了。”

JavaScript 安全漏洞：CWE

JavaScript 有两种常见的 CWE——密码问题（CWE-310）和路径遍历（CWE-22）。研究人员表示，“我们在调查 NPM 包时发现，61% 的 JavaScript 安全漏洞都存在路径遍历和加密的问题，但是这其中 70% 的包都已经不再使用维护了，且 2018 年的下载量少于 2000 次。”

为什么这两种类型的 CWE 数量会这么多呢？研究人员表示，“原因之一可能是新的自动化工具在这些几乎没有维护下载的包中发现了这些 CWE。”

从调查结果来看，2016 年发现的 JavaScript 安全漏洞几乎都是密码问题（CWE-310），而 2017 年发现了绝大多数的安全漏洞都是路径遍历问题（WEE-22）。同时，这两种类型的安全漏洞也导致了 JavaScript 安全漏洞的整体上升。

由于开源社区的分散性，有关安全漏洞的信息被分散在数百个安全顾问、开源项目的问题跟踪者和论坛中。虽然关于这些安全漏洞的信息也可以通过各种渠道被开发者知晓，但是可信度却无法进行衡量。

PHP

PHP 安全漏洞：按严重程度

“PHP 是最好的编程语言”，这是一个在技术圈广为流传的段子，甚至非技术人也听过这个段子。但是最近几年来，PHP 的普及率一直在下降。2017 年，PHP 的安全漏洞打破了之前一直起起伏伏的趋势，数量急剧上升。

在此次调查中，PHP 的安全漏洞数量在所有被调查的编程语言中排第二。

PHP 安全漏洞：CWE

PHP 是唯一一种具有 SQL 注入（CWE-89）漏洞的语言。

很多安全专家认为 SQL 注入漏洞应该是很久远的事情了，但是在 PHP 中 SQL 注入漏洞仍是很常见的安全漏洞，尤其是在 2017 年和 2018 年，SQL 注入漏洞的数量特别高。

针对 PHP 安全漏洞，有人表示：“PHP 语言中内置的一些设计流程和糟糕的实践，使得开发者很难编写安全代码和维护高级别的安全编码。”

Python

Python 安全漏洞：按严重程度

近几年来，Python 获得了飞速的发展，而且其在安全配置文件方面做得也非常不错。大多数编程语言都是到 2018 年才出现了安全漏洞下降的情况，但是 Python 的安全漏洞自 2015 年达到峰值，之后就一直在下降。

且 Python 的高严重性安全漏洞的占比也非常小。

Python 中主要存在 4 种类型的安全漏洞，输入验证（cwe-20）、权限、特权和访问控制（cwe-264）、跨站点脚本（xss）（cwe-79）和信息泄漏 / 泄漏（cwe-200）。这些安全漏洞在其它编程语言中也是非常常见的。

C++

C++ 安全漏洞：按严重程度

C++ 和 C 语言的安全漏洞情况差不多，由于这两种编程语言不太适用于 Web 应用程序开发，因为它们的安全漏洞在其它语言中不太常见。

C++ 安全漏洞：CWE

从上图中我们可以看到，缓冲器错误（CWE-119）是 C++ 中最常见的安全漏洞，排在第二位的是输入验证问题（CWE-20）。

输入验证问题（CWE-20）是从 2016 年才开始增加的，而这一增长也侧面表明接下来安全研究人员可能会重点关注输入验证问题。

Ruby

Ruby 安全漏洞：按严重程度

在被调查的七种语言中，Ruby 的安全漏洞最少，在过去的 10 年中 Ruby 的安全漏洞数量一直在起起伏伏。

Ruby 安全漏洞：CWE

Ruby 中最常见的安全漏洞是 XSS 漏洞，同时也这是其它编程语言中比较常见的安全漏洞。另外，CWE-20（输入验证）和 CWE-200（信息泄漏 / 披露）在 Ruby 中自 2013 年达到顶峰之后，之后一直就没有什么变化，这说明大多数的 Ruby 开发人员已经学会了如何处理它们。

除了 PHP 之外，Ruby 也是唯一一种具有相对较高数量的 SQL 代码注入漏洞的语言。不过，自 2015 年之后，SQL 注入就在 Ruby 中消失了，很可能是开发人员也掌握了如何避免 SQL 注入的方法。