编程语言安全性排行榜：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安全漏洞：按严重程度

自2016年起，Java的安全漏洞就一直在不断上升。2018年，其它编程语言的安全漏洞数量都在下降，Java是唯一一个安全漏洞在这一年增加了的编程语言，更夸张的是，2018年的Java安全漏洞相比2017年翻了一番。

从上图中，我们可以看到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安全漏洞的整体上升。

JavaScript社区

在研究JavaScript的安全漏洞时，研究人员还发现了一个有趣的现象：超过30%的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安全漏洞：CWE

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注入的方法。