Which Programming Language Has The Most Security Vulnerabilities? (techrepublic.com)

A new report from the open source security company WhiteSource asks the question, "Is one programming language more secure than the rest?"

An anonymous reader quotes TechRepublic: To answer this question, the report compiled information from WhiteSource's database, which aggregates information on open source vulnerabilities from sources including the National Vulnerability Database, security advisories, GitHub issue trackers, and popular open source projects issue trackers. Researchers focused in on open source security vulnerabilities in the seven most widely-used languages of the past 10 years to learn which are most secure, and which vulnerability types are most common in each...

The most common vulnerabilities across most of these languages are Cross-SiteScripting (XSS); Input Validation; Permissions, Privileges, and Access Control; and Information Leak / Disclosure, according to the report.
Across the seven most widely-used programming languages, here's how the vulnerabilities were distributed:

• C (47%)
• PHP (17%)
• Java (11%)
• JavaScript (10%)
• Python (5%)
• C++ (5%)
• Ruby (4%)

But the results are full of disclaimers -- for example, that C tops the list because it's the oldest language with "the highest volume of written code" and "is also one of the languages behind major infrastructure like Open SSL and the Linux kernel."

The report also notes a "substantial rise" across all languages for known open source security vulnerabilities over the last two years, attributing this to more awareness about vulnerable components -- thanks to more research, automated security tools, and "the growing investment in bug bounty programs" -- as well as the increasing popularity of open source software. And it also reports a drop in the percentage of critical vulnerabilities for most languages -- except JavaScript and PHP.

The report then concludes that "the Winner Of Most Secure Programming Language is...no one and everyone...! 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 software development lifecycle with the proper management approach, then you are far more likely to stay secure."

Coincidentally, WhiteSource sells software which monitors open source components throughout the software development lifecycle to provide alerts about security (and licensing) issues.

Comments

Re:Not the programming language

[hcs_$reboot]

Of course the programmer creates security holes by how they use the language. But in PHP (more the case in older versions) some "features" gives a sense of security while they actually don't. 'addslashes()' vs 'mysql_real_escape_...' for instance ; 'strpos' that returns 'false' if not found (instead of -1) so in a 'if' the programmer might misses a position at 0... Local functions are actually not local... etc... etc... All of that is Ok when you're used to the language, but they're just counter-intuitive traps that even a good programmer may fall into at the beginning.

Re:This is nonsense

[imidan]

If both an easily usable remote vulnerability with privilege escalation is counted the same as a very hard to exploit local vulnerability...

I knowingly created a vulnerability in a single sign-on system that I implemented. I did it for expediency. But when I did, I spoke with my boss about it first, and then we all talked about it at a staff meeting to try to determine ways that it could be exploited. The two we came up with involved a bad actor who already had unrestricted physical access to a logged-in user's machine, or a bad actor who had reality-defying luck at guessing a UUID within a 24-hour period. In either case, the attacker couldn't gain access beyond the user they impersonated. It was decided that even though a vulnerability existed, successful exploitation was unlikely.

The point being, as you say, not all vulnerabilities are made equal. If you can determine the risk of exploitation, the value of the system being protected, and the cost of recovery from a bad action, and accept all of that, then maybe the cost of eliminating the vulnerability is greater than the expected cost of dealing with an exploit.

Re:Not the programming language

[ShanghaiBill]

PHP has more than a dozen different ways to connect to a database. PHP has a long history of glomming on new APIs, but never deprecating the old, even when shockingly insecure. This is especially bad for PHP because most of PHP's user base are low IQ Wordpress extension hackers who are not qualified to be making security decisions on their own.

Re:Not the programming language

[AmiMoJo]

The same is true of C programmers though, far too many of them don't understand the language and just hack stuff together to fulfil the contractual obligations and then disappear.

Contract work is a particular problems. There was a study recently, sorry I lost the link, where they put out contracts for a basic login page. Most of the developers didn't bother storing the password securely at first, then when asked managed to botch doing it. Contract work encourages minimum effort and throwing unsuitable libraries at problems, and often the person checking for completion doesn't understand the security issues.

Re:Not the programming language

[swillden]

In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?

Everything *MUST* *BE* unit-tested for type-correctness

While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.

I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.

(The code I mention created a set of pure interfaces, then instantiated them and called their methods... and they worked! There was machinery that intercepted the instantiations and chose appropriate concrete types. Essentially it was a particularly opaque dependency injection framework. Think Guice, if you're familiar with that, but with absolutely nothing in the code to indicate that dependency injection was happening.)