Slashdot Mirror
Which Programming Language Has The Most Security Vulnerabilities? (techrepublic.com)
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.
but the programmer that uses it.
Slashdot, fix the reply notifications... You won't get away with it...
Language design unquestionably makes certain programming errors more difficult or even impossible. This is not mere tilting at windmills: many of the classes of errors that are removed are extremely important and damaging ones. Other language features can force programmers to think through their designs more and/or make their code more clear and expressive. Some language designs can even limit and constrain the possible logic errors that a program can commit.
Obviously, naturally, a better programmer will write more secure programs, in any language. But that's not a very interesting question. The interesting question is whether two equally skilled, equally disciplined programmers will write equally secure programs when one of them is allowed by the language to do anything, and the other has many guardrails in place to prevent errors.
Around 99% of vulnerability happens in parsing (general speaking, including string handling). If you make decision to take Lua as the format and take Lua parser as parser, done. Almost zero vulnerability.
Very true. Also, a bad C coder will just create other vulnerabilities in Java, for example. The problem is with coders that a) have no clue how to do it and b) do not know their limits or are forced to not respect them by stupid management. It comes all down to the coder, not the language. A bad coder will produce insecure code in any language, there is _no_ way to avoid that even if many bad coders continue to believe in the existence of the One True Language (TM) that will finally make them good coders. This quasi-religious belief is built on a futile hope and hot air used by vendors and interest groups to keep it alive.
So, let me state again: There is no silver bullet. Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders. These coders are rare, expensive and expect to be treated well. Not having them and trying to do it on the cheap will always be a lot more expensive in the longer run and is a severe management failure. As in any engineering project, in coding, the architects, designers and coders are the most important people, the managers merely serve to deal with management obstacles. They have zero business making tech decisions and if they do that they sabotage the success chances and result quality of the overall project.
We, as the human race, generally have this figured out in engineering, with some notable exceptions, e.g. the current mass-murder committed by Boeing management, the Brazilian dam certified to be secure by TÜV Süd, Fuckupshima, etc. But in software engineering, management is not just incompetent (as usual), it is outright demented and completely disconnected from reality. That has to change.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
its not hard to write secure c
And yet 70 percent of all security bugs are memory safety issues.
If only there was some kind of language which was designed to reduce memory safety bugs.
The OP includes the disclaimer that the C++ programming language "tops the list" because it has been in use for the longest and therefore includes the most lines of sample code from which to draw a conclusion...
But a better measure would be defect density , or the number of vulnerabilities found per thousand executable lines of code. An even better measure would then take that data and factor it using an independent vulnerability severity assessment, such as CVSS2.0 (for example).
Even this approach will leave us with concerns. The results could be massively skewed, for example, if the C++ dataset comprised deeply complex code, whilst the PHP sample (for example) were largely comprised of trivial read-only presentation formatting statements. In order to attempt to make such analysis comparable, it would be necessary to compare equivalent functions written in different languages. In this context, by "function", I am referring to code objects that deliver either identical or similar functionality, such as input validation.
Unfortunately, the variables don't end there... The OP suggests that code was drawn from a variety of sources, including GitHub, public issues trackers and public development projects... Even the most cursory glance at GitHub projects will easily demonstrate the huge variance in ability of project contributors. This means that it is entirely conceivable for the test results to be distorted by nothing other than the relative ability of contributing programmers.
This is a really nice idea and we should encourage more and better attempts at helping us to understand what it takes to write defect-free code. However, I'm not entirely convinced that this analysis considers all pertinent factors and therefore am not likely to be completely persuaded by the results.
I would also like to better understand the impact of things like good project discipline on the outcome of this analysis. For example, what are the differences between a project which has really strict internal rules for things like variable, object and function naming? How about something as innocuous as code formatting - things like indentation, line wrapping and so on? What about the toolset and platform? The IDE used? The project discipline with regard to code re-use? All of these are "tells" - indicators as to the sort of defect density we should expect. They will not be uniform across randomly sampled software projects.
In my experience [maybe 10 years developing in a 30-year career] I would say that adherence to these sorts of "programming disciplines" is actually [much] more important than the language you use. Unless you pick a turkey of a language, you should be choosing it because it's philosophy and structure, it's approach to solving problems, most closely aligns to what you are trying to achieve.
And as a mentor once told me: "Just remember, the fastest, leanest, most efficient and compact piece of code can be replaced by something which is 5% slower, takes up 5% more memory and is 5% less efficient - but which is easy to understand, debug and maintain."
Quite possibly one of the most useful pieces of advice I've ever received...