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.
Ada.
Domestic spying is now "Benign Information Gathering"
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.
You forgot assembler.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Complete failure to even attempt to normalize bug counts so they can be evaluated on common terms makes TFA not worth reading.
tops the list because it's the oldest language with "the highest volume of written code"
It would've been easy to break numbers down by lines of code, wouldn't it?
Likewise by the year the code was written and whether or not it is currently being maintained (say, did the repository get an update within the past 3 months?).
Assorted stuff I do sometimes: Lemuria.org
The issue is the what level does a language allow you to write at?
C is Assembler - hence the whole machin eis open to you, period GET IT??? It is way real programmers do not allow beginners and children to writing C.
On the other end - Business Languages Cobol and RPG. Heavy typed and run on procesors that are data aware. Just try to stick any non-numberic in numeric field. They is not stack. Oh you can create security issues by bad designs by using SQL enhenced query, Cobol not at fault, but SQL is, not to meantion studpid coder, cause SQL injection issues.
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.
Did you just walk into the wrong room?
Nor the report. I'm curious as well.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
...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.
So, I am reading that you haven't done any embedded programming since they invented C. You can do most of than in C, and use the inline assembler where necessary.
C lets you write assembler more easily.
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...
Yes, much easier to fuck up in C.
But sometimes you need the no-training-wheels approach from C. The last time I've used it was for a simulation which would have taken at least 4 times the memory using Java or C++. When you're using 80% of your available memory, 4x isn't possible.
Assorted stuff I do sometimes: Lemuria.org
So...we're measuring a language's security by the applications that were written in it?
Anyone else have an issue with this?
I call BS. You can NOT measure the language's security via the applications written it in. You MIGHT be able to gauge a languages popularity given the number of applications written for it (I do). You MIGHT be able to determine the effectiveness of a language *IF* you take the number of applications with vulnerabilities and divide that by the total number of applications written in that language.
indeed. The problem is - wherever you go, you either have moderating policies that are going direction censorship or you get idiocy like this or if unlucky you get both. Slash has a relatively well done moderating system. the idiocy I have not seen until your post made me unravel it to me - it has a proper score of -1. I go there only if I am moderating.
i like the conclusion, all languages are good security wise, it just depends on how you use them.
the questions actually should have been: which programmers use the most secure coding practises.
On a long enough timeline, the survival rate for everyone drops to zero.
So basically you say the numbers you're quoting are meaningless... So why quote them? Or build them in the first place?
To compare a more vulnerable language from another I'd look for vulnerabilities per lines of live code. Not perfect, but it feels closer to useful.
And perhaps number and severity of vulnerabilities per project for the same types of purpose. Web framework for web framework, etc. To highlight purpose differences and good preventative design practices.
Even better would be hours to find and fix too. But probably hard to measure, and assign time like that for open source projects.
+1
Slashdot, fix the reply notifications... You won't get away with it...
For some years now, an ISO/IEC working group, WG23, has been compiling lists of programming language vulnerabilities, both for specific languages and generically. The documents list for the WG is a bit of a mess, with the main link to the current draft getting a 404, but you can find links to sections on individual languages there. Some language committees are actively participating in WG23, but the C++ committee, I am told by another member, refuses to do so.
...and loser. Sounds about right
at least for some.. so what the problem?
I come to Slashdot only to read sigs. One you are reading is mine.
PHP4 was the only programming language I can remember that was so insecure there was an industrywide push (GoPHP5) to get everyone off it and onto PHP5. Even if you were a good programmer the thing was full of holes, because it was just Rasmus's little hypertext preprocessor that had gotten totally out of control.
Though *technically* it wasn't the language itself, just the interpreter - like ActionScript isn't the problem, it's the Flash player.
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.
Also, since you can compile C with a C++ compiler, you should have MORE potential security holes in C++ than in C...
Non-Linux Penguins ?
Consider this: PHP relies on an interpreter, written in C. Does that mean every PHP vulnerability is in fact a C one? This is just another post that seems to mix the apples and oranges of differing languages, assuming them to be equal.
No. With a good compiler, C has minimal memory overhead and doing a complex simulation in assembler isn't high on my wish list.
Assorted stuff I do sometimes: Lemuria.org
I browse continuously at -1. I rarely find reasonable and intelligent posts there which go against cliches. And I see plenty of both cliche and non-cliche posts at higher levels. I do not doubt that some anti-cliche posts do get buried, but I also would need more evidence to believe that it happens on a wide scale.
Of course, I generally read stories a day or two late, when people are no longer moderating or commenting. Maybe comments that go against the cliches are buried quickly and then unburied by the time I make it to them.
"Nothing shocks me. I'm a scientist." -Indiana Jones