From top to bottom, technology is riddled with security errors. At the lowest level, we have hardware errors such as Intel's Meltdown and Spectre bugs. Just above those, we have programming language security holes, and boy, do we have a lot of those!
WhiteSource, an open-source security company, recently did a study of open source security vulnerabilities in the seven most widely used languages over the past decade. To find the bugs, the company used its language security database. This contains data on open-source vulnerabilities from multiple sources such as the National Vulnerability Database (NVD), security advisories, GitHub issue trackers, and open-source projects issue trackers.
There's also no surprise as to which language had the most security bugs. That's C, by a wide margin. Nearly 50 percent of all reported vulnerabilities were in C.
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 OpenSSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open-source vulnerabilities in C.
They have a point. But having programmed and fought with C for decades now, I have found it really is way too easy to make terrible security blunders in C. For example, C contains a great deal of undefined behavior, which leaves all kinds of nasty possibilities open.
C++, however, has the "honor" of having the most high-severity vulnerabilities in the past five years. Buffer errors, which have long plagued C, are also now being discovered often in C++.
So, why are they -- and other language problems -- showing up? New automated programs, such as Source Code Analysis Tools, are spotting vulnerabilities, which otherwise would have been overlooked.
The one language which has been showing well on security holes, is -- drumroll, please -- Python. Yes, good old -- often made fun of -- Python.
But is C really the worst and Python the best? WhiteSource thinks that's much too simple a conclusion: "While the game of 'my programming language is safer than yours' is certainly a fun way to pass time … finding the answer will probably not help you create the most innovative or secure software out there."
No, instead you should spend your time "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."
In the end, security is not about the languages, but how you use them.