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...
The more flexible the language, the more ways you can screw up and allow a security hole.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
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.
The vast majority of security vulnerabilities in the wild are running AMD64 assembly. It's by far the least secure programming language.
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.
I'd list all of the public and semi-public repositories that publish modules for automatic installation and update. These include pip, ant, maven, gradle, CPAN, and gems. The Java repositories used by ant, maven, and gradle tend to have unknown binaries and unknown provenance, with no reliable way to evactly recreate the published jar files. Ruby gems have a similar issue. CPAN and pip rely on upstream source code for local deployment or compilation but are also very vulnerable to their default download of the most recent version of any module, which may or may not interact badly with other obsolete or updated modules. It's why many operating systems publish packaged binaries, and it's why the "compile as needed" operating systems cannot be stable and _cannot_ be thoroughly secured.
First, usage is not evenly distributed. Second, some things you can only do in one language. And third, there are different groups of coders for each language. Take C coders, for example. If you use established Linux kernel core coders, you get completely different numbers compared to using newbie kernel driver coders.
And then you have that vulnerability is not the same as vulnerability. Simple counting metrics are basically always fundamentally flawed and give you a completely unrealistic picture. If both an easily usable remote vulnerability with privilege escalation is counted the same as a very hard to exploit local vulnerability that just allows you read access to some not very critical data, then the result is utterly meaningless. You also get situations were what is one vulnerability in one language counts as several in another, for example because it is a combined vulnerability in a library in one and separate simpler components in another.
Hence statistics like this one do a lot of harm by confusing the issue and help not one bit to actually see a fragment of reality. They abstracted too much away. It is like, for example, they judge whether people are good or bad according to their beer brewing skills. You will find good beer brewers that were mass-murderers, and ones that were saints. The results of such an evaluation is completely meaningless.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
This shit is really depressingly stupid. You might actually accomplish your goal of getting me to stop coming to slashdot entirely.
...but neverthless have a very large volume of written code, from TFA we can conclude that COBOL and FORTRAN are the safest language to use.
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...
There is no silver bullet
Duh. You're the only one I see here claiming there is.
The claim is just that some bullets are a little safer that others, which is absolutely true.
Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders.
So you're saying there is a silver bullet: Good, experienced and talented coders. Except, you know what? That bullet is also silver-plated at best. Electroplated, even. Good, experienced and talented coders also write insecure code. They write less of it, certainly, but they're not perfect.
You know what works the best? A layered strategy:
1. Top-notch programmers
2. A security-focused development culture
3. A focus on architectural defense in depth, so one vulnerability by itself isn't enough.
4. A focus on security by design.
5. Good secure implementation choices -- which includes picking languages and tools that make insecure implementation harder.
6. Thorough design reviews, by other top-notch programmers
7. Thorough code reviews, by other top-notch programmers
8. Third-party security testing, however accomplished (contracting with security firms, open source + bug bounties, etc.)
9. Fast patching of identified vulnerabilities (because even after doing all of the above, you're still going to have vulnerabilities).
There is no silver bullet, true. Which is why all of the above are required -- and they still aren't really enough. Hiring rare, expensive programmers is not sufficient. And it's not actually necessary (though it's crucial to have access to at least some of them), and that's good because rare, expensive programmers are not scalable.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.