Is One Programming Language More Secure Than The Rest?

Want to liven up an open space full of software developers? Ask them what the best programming language is, and why. I think we all know that there is a high chance that lively debate will end with tears, rage, and broken friendships. Coders tend to take their programming languages very personally and in their battle to prove the dominance of their favorite language, the security card is often brought up.

Feeling the right mixture of brave and curious, we decided to address the debate over which programming language is the most secure head-on, and being as we’re in the business of open source security, we decided to write our latest Mend report about how some of the top programming languages measure up when it comes to their security.

We dug through our open source vulnerabilities database, which aggregates information on open source vulnerabilities from multiple sources like the National Vulnerability Database (NVD), security advisories, GitHub and other popular open source projects issue trackers, to see if we could clearly crown one of the seven popular programming languages as the most secure.

Searching for the most secure programming language

First, we needed to decide which languages to take a closer look at. We managed to get through that potentially explosive debate by choosing to focus our attention on some of the most popular languages in use in the open source community over the past few years: C, Java, JavaScript, Python, Ruby, PHP, and C++.

We scoured our database to see the number of known open source security vulnerabilities in each language over the past ten years, as well as the breakdown of these vulnerabilities’ severity over time. In addition, we checked to see which CWEs are most common for each language.

Who has the most vulnerabilities of them all?

When looking at the total of reported open source vulnerabilities for each of the seven languages over the past 10 years, C took the top spot with nearly 50% of all of the reported vulnerabilities.

This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.

Open source security vulnerabilities per language over time

We then looked at the number of open source vulnerabilities over time. The data showed that every programming language had its own security highs and lows over the past ten years. However, there was one trend that stood out across all of the languages, and that’s the substantial rise in the number of known open source security vulnerabilities across all languages over the past two years. This rise can be explained by the rise in awareness of known security vulnerabilities in open source components, along with the continuously growing popularity of open source. As more resources have been invested in open source security research, the number of issues discovered has increased. The use of automated tools and the growing investment in bug bounty programs have further contributed to the sharp rise in the amount of disclosed open source security vulnerabilities.

Open Source Vulnerabilities Over Time, per Language​

Let’s get critical: High severity open source vulnerabilities over time

When we took a closer look and focused on high severity open source security vulnerabilities (scores above 7 according to CVSS v2), we saw that the percentage of critical vulnerabilities is declining in most of the languages covered in the report, except for JavaScript and PHP.

The decrease in the percentage of critical vulnerabilities could be a result of the concerted effort from security researchers to use automated tools to discover vulnerabilities in open source components. These tools are usually less capable of finding more complex and critical issues. While many of these tools are doing a good job of discovering vulnerabilities, many of the issues are not critical, and so we see a rise in the number of mostly medium vulnerabilities over the past few years in most of the programming languages that we studied.

High Severity Open Source Security Vulnerabilities Over Time, per Language Over Time​

What’s the CWE?: Most common CWEs per programming language

In order to learn as much as possible about each of the programming language’s strong and weak points security-wise, we also looked at the most common CWEs per language. Two CWEs reigned supreme and featured among the three most common 70% of the languages: Cross-Site-Scripting (XSS) also known as CWE-79 and Input Validation, otherwise known as CWE-20.

Nearly all languages also have quite a few top ten CWEs in common. In addition to XSS and Input Validation, other CWEs that are prominent across most languages are Information Leak/ Disclosure (CWE-200), Path Traversal (CWE-22), CWE-264 Permissions, Privileges, and Access Control, which is replaced in more recent years with its more specific close relative — Improper Access Control (CWE-284).

And the winner of most secure programming language is…no one and everyone!

While the game of “my programming language is safer than yours” is certainly a fun way to pass time, and the debate over the most secure programming language will often include some interesting points, finding the answer will probably not help you create the most innovative or secure software out there. Nor will it help you enjoy a secure and agile delivery of said innovation.

Most software development organizations today rely on more than one programming language to make their magic happen. Staying on top of known open source vulnerabilities and understanding the strong and weak points in the programming languages you and your team are using are great ways to make sure that your software projects have security baked into them from the start.

Our bottom line conclusion from the research is that it is not about the language itself that makes it any more or less secure, but how you use it. If you are mitigating your vulnerabilities throughout the SDLC with the proper management approach, then you are far more likely to stay secure.

Want to read more about each of the programming languages’ security status? Read the full report!