Which Programming Language Has The Most Security Vulnerabilities? (techrepublic.com) 330
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.
Not the programming language (Score:4, Insightful)
Re:Not the programming language (Score:5, Insightful)
Re: (Score:2, Interesting)
It is only really the default configuration of older PHP versions that make it so much more practically insecure. In reality, JavaScript should be higher up on this list, because some of it's innate behaviors are so badly designed they cause vulnerabilities that can't be mitigated in any way other than simply not using it.
Re:Not the programming language (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Insightful)
I would say that everyone is right here. C, it is easy to make mistakes which cannot happen in Java or Python, like not watching where pointers are going, array out of bounds issues, and other stuff.
However, part of it is modern coding in general. The last several "Agile" places I worked at were in permanent sprints, and the job of the developers is to get a feature that marketing already sold to the customer into the product. It doesn't matter if it doesn't work, or is horrifically insecure. It is about making those deliverables in time. When one was made, marketing had two more waiting to be done, so it never ceased.
In most places, one can easily wind up having their job outsourced/offshored if they don't make deliverables. On the other hand, something horrifically insecure that causes every customer to have a backdoor to the world, the developer is insulated from that, through many layers of corporate bureaucracy, so even if there are lawsuits, the developer would likely feel no consequences.
tl;dr, blame the programmer, not the tools. However, some languages require more thought to program safely/securely than others.
Re: (Score:3)
Then we got to procfs which is a bleeding disaster.
No
Re: Not the programming language (Score:3, Insightful)
Its like the what dogs bite the most people scenario, yes Labradors are way up on the list, but only because theres so many of them compared to other breeds.
Re: (Score:2)
It is only really the default configuration of older PHP versions that make it so much more practically insecure.
So the fact that PHP can introduce weird bugs due to surprising behavior of even basic operations is irrelevant for security now?
In reality, JavaScript should be higher up on this list, because some of it's innate behaviors are so badly designed they cause vulnerabilities that can't be mitigated in any way other than simply not using it.
And an example of that would be...what exactly?
Re: Hebrew (Score:2)
This shit is really depressingly stupid. You might actually accomplish your goal of getting me to stop coming to slashdot entirely.
Re: (Score:3)
But to be fair. some languages are more prone to security holes (like PHP, especially the older versions).
No. The only thing PHP does is to make it easier for bad coders to create really simple to exploit vulnerabilities. Anybody competent will write code just as secure. It may take them longer because PHP is a really, really bad design that no good coders would use given a choice. (If you think different, then you are not a good coder. Sorry. It is completely clear and you are deluding yourself. PHP ignore fundamental principles of good engineering in many places.)
Re:Not the programming language (Score:5, Interesting)
Re:Not the programming language (Score:5, Insightful)
I agree. PHP has traps by surprising behavior. One of the corner-stones of secure coding is the Principle of Least Surprise and PHP violates it repeatedly. Still a good coder will find these and just not trust the language anymore and be extra careful. This makes coding slow and not fun and expensive, but it can be done. An average or worse coder (the majority of them) will just fall in the traps and create insecure code. However, an average or worse coder will still screw up more than acceptable in a well-designed language.
Re: (Score:2)
I agree. PHP has traps by surprising behavior. One of the corner-stones of secure coding is the Principle of Least Surprise and PHP violates it repeatedly.
So does Python; hasn't hurt either of them popularity-wise.
Re: (Score:3, Insightful)
Python is not nearly in the same class here.
Re:Not the programming language (Score:5, Informative)
I have done stuff in both and I do not agree in the least. PHP is a dangerous mess. You need to understand its specific defects to code safely in it. Python is pretty well-designed but _not_ a language for beginners in OO concepts, functional coding, etc. It requires experience with the general concepts used, but not with the specific implementation in Python. As such, it does not violate the principle of least surprise.
Re: (Score:3)
I really hope you are joking that an assignment operation can cause a loss of data because if you are, please close your editor, walk away from your computer and look for a new profession because you should NOT be writing code.
Re:Not the programming language (Score:5, Informative)
Scope in Python is complex. However, it is absolutely nothing that will surprise anybody competent. Because if you have a variable twice, with different scope, anybody competent will read up how scope works before. Also, "accidentally" reversing an assignment is a code bug and nobody with the least bit of understanding would ever blame the language for the effects.
Re: (Score:3)
This is the general problem with these 'unexpected behavior' type discussions, they make sense or not depending on what other languages
Re:Not the programming language (Score:4, Interesting)
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.)
Re: Not the programming language (Score:2)
Examples?
Re: (Score:2)
I agree that this is a strong component in this mess.
Re:Not the programming language (Score:4)
[,,,] the determined Real Programmer can write FORTRAN programs in any language.
Ironically, this is an article why Real Programmers avoid Pascal.
Re: (Score:2)
What is the relation between your statement and what I wrote? Can you explain?
Re: (Score:3)
I'll code in any language you throw at me if necessary. Sometimes, you have to do with the things at hand. Life is not a picnic.
Re: (Score:2)
No true Scotsman would write insecure PHP code, right?
Re: (Score:2)
You need to read up on how that fallacy works. Here is a hint: It requires a disconnect between the group-characteristic and the excluded examples. That disconnect is missing in my statement and hence the fallacy does not apply.
Re: (Score:2)
Nah, that fallacy doesn't work that way. Besides, your statement, is, in fact, even worse, because it is also an example of circular logic.
Re: (Score:2)
Most script languages are written in C.
C is a good language for focused functionality where performance or detailed control is important like hardware drivers, but when you look at bread&butter code then there are actually better languages. The problem is that not all those languages are as portable as C to other environments or even between versions due to breaking backward compatibility.
A C program written in K&R style can still be compiled even if the compiler may moan quite a bit about obsolete
Re: (Score:2)
C used to be a good language for focused functionality where performance or detailed control is important, but that was long ago. Modern computers are very different to a PDP11, yet C more or less forces them into these constraints.
Re: (Score:3)
https://queue.acm.org/detail.c... [acm.org]
This explains it better than I ever could.
Re: (Score:3)
I wonder then, if you took a random group of programmers, and gave them all a fixed amount of time to produce some sort of output in different languages, how many of them would (a) finish in time and (b) produce a secure output.
My point is, much like yours, that some languages make it easy to be reasonably secure, others make it quite hard. Any language can produce secure code, but given it's somewhere on the easy/hard spectrum, which one is the quickest to produce a secure output? Additionally, which one p
Re: (Score:2)
but the programmer that uses it.
And that is the only aspect that matters. Anything else is a red herring or a minor issue. But too many people that think they are competent to voice their opinion on the matter cannot see that and hence the mess continues. Will probably take a few really large disasters to change anything here.
Re: (Score:2)
but the programmer that uses it.
Exactly. C is the hard parts. Lots of mistakes are made.
It opens whole markets.
Re: (Score:2)
Most likely the libraries they use.
E.g. below one is nitpicking about PHP and he obviously does not know that PHP got greatly improved during the last ten years.
OTOH there plenty of mistakes you can make by simply configuring your server wrong, then the language does not really matter ...
Re: (Score:2)
We can fix that: Simply replace humanity with a different humanity that is capable of writing secure C code.
Or we can use memory-safe languages where possible.
I vote for the latter.
Re: (Score:3)
Also to note what the programming language is used for.
If I am tasked to program an "Enterprise" Class application I will be using C,Java,C++ (And Javascript if there is a web front end) because these are the languages the big Execs expect to be codded in, There is still a wide hiring base for expansion, Other "Enterprise" Applications are codded in these languages, and these languages have support from many big players. Despite the fact that I normally shutter when I hear "Enterprise" class, because it i
Re: Not the programming language (Score:5, Insightful)
Re: Not the programming language (Score:3)
Re: Not the programming language (Score:5, Insightful)
Good programmers write good code in every language. A bad programmer writes bad code in all of them.
Good programmers may not write good code in a language they don't understand yet. A great C# programmer could easily end up writing code with major memory holes in C because they don't understand the differences in memory management. A great Java programmer could end up making utter trash with sql because of the different ways of thinking about the languages.
Re: (Score:3)
I agree with your point, but I don't think you could even get any real work done in C without understanding part of the memory management. In the case of your SQL example, that's more likely to have massive performance problems than a security vulnerability.
I don't think you need experts, but you do need people who are willing to look at best practices documents when working in a new language. That are books on writing secure C and Java code as well as various papers and sites with content. There's also p
Re: (Score:3)
I agree with your point, but I don't think you could even get any real work done in C without understanding part of the memory management.
As somebody who specifically works with undergraduate students with a Java background, the first few C++ programs I get from (almost) every new intern while training them is full of "Foo* bar = new Foo();", without the accompanying deletes. The way that happens is pretty clear: they're used to instantiating instances with new, they get a compiler error that indicates they should have an asterix next to they type when they do that, so they add an asterix.
Granted, the process with C would be a bit different b
Re: (Score:3)
No they don't. This is a myth programmers tell themselves.
There are safe languages and there are unsafe languages.
Given same time, the performance of similar programmers (good or bad) will vary widely across them.
This is the entire point of programming language research.
A good programmer writing Haskell, Ada or Rust (languages that prioritize safety) code will invariably make fewer errors than he will in C (minimal safety features) - given same programming goals and time.
Re: (Score:3)
Why on earth would you compare an expert vs. beginner when comparing tools?
That's like saying, our car is just as safe as the rest, but only when driven by Grand Prix winners.
Do you understand comparison studies? You control for every other variable.
I specifically wrote: "the performance of *similar* programmers".
You compare Bill Atkinson like programmer performance using both safe and unsafe tools. *Separately*, you then compare mediocre programmers.
Also note that I also wrote "Given same time".
Re: (Score:2)
C is an assembly macro language.
Re: (Score:2)
But it is though.
Anyone proficient in assembly and C can "see" the assembly that the C code will make, as they write the C code. This is not true in C++ or FORTRAN or the others.
Re: (Score:3)
This is not true in C++ or FORTRAN or the others.
Yes, it is.
On the other hand, modern compilers make so much behind the scene that you *on modern hardware* hardly can say what is going on without actually looking at the assembly code. (Register renaming, operation reordering, parallel speculative execution etc.)
Re: (Score:3)
Re: (Score:3)
Anyone proficient in assembly and C can "see" the assembly that the C code will make, as they write the C code.
What a load of bullshit. Between multiple targets, compilers, and the dozens and dozens of flags and options which affect compiler output, anybody who knows what they're talking about will say never assume anything unless you look at the assembly yourself. This is why sites like https://godbolt.org/ [godbolt.org] exist. You have to be in an incredibly small, tightly controlled, limited scope environment to reall
Re: (Score:3)
Anyone proficient in assembly and C can "see" the assembly that the C code will make, as they write the C code. This is not true in C++ or FORTRAN or the others.
That hasn't been true for optimized C code for over a decade now. The compiler will surprise you in amazing ways in order to eek a cycle out of out-of-order instruction processing. And C++ isn't particularly mysterious once you get the hang of it.
Re: (Score:2)
Easy way to rank (Score:3)
Re: (Score:2)
Re: (Score:2)
The more flexible the language, the more ways you can screw up and allow a security hole.
Case in point: PERL.
Re: (Score:2)
Re: (Score:2)
That's a good way of putting it.
Secure languages are definitely not nice languages for the programmers ... they want freedom (pointers) and convenience (type inference) but giving it to them runs counter to security.
Re: (Score:2, Funny)
Re: (Score:2)
Females don't need to sign it; nothing they do is wrong.
Kinda silly conclusion. (Score:4, Insightful)
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.
Re: (Score:2)
No. You cannot force people to think. The avoidance of thinking is one of the most refined skills in the human race. No tools can help here. This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect. Of course, the motivation behind this is to avoid addressing the continued management failure in both hiring cheap, incompetent coders and in making tech decisions.
Re: (Score:2)
Show me an actual, scientifically sound study first that backs your claim. Because your reference does not do that. Instead if regurgitates the ages-old fallacy that because specific vulnerabilities are removed from the possible things you can code, the same coders will write better code. That is not the case and nobody has ever been able to prove otherwise.
Re: (Score:2)
Re: (Score:2)
Indeed. Nice to see that there are people that can think here. Even if you are an AC.
Re: (Score:2)
Re: (Score:2)
Bottom line you learn coding by coding a lot. Making mistakes realizing it, reflecting about it and improving yourself.
You can not simply "teach" how not to make mistakes. Sure, you can teach concepts, problem cases, defensive strategies, tests etc. But bottom line the only way to learn is to make mistakes and learn from them.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
AMD64 assembly (Score:3)
The vast majority of security vulnerabilities in the wild are running AMD64 assembly. It's by far the least secure programming language.
Re: (Score:3)
The vast majority of security vulnerabilities in the wild are running AMD64 assembly. It's by far the least secure programming language.
Especially if run on the inferior "Intel" implementation.
Approach, rather than language (Score:4, Insightful)
Modules (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Wouldn't that merely break new deployments of those modules? I'd not expect it to break already deployed systems.
Re: (Score:2)
Re: (Score:2)
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.
That is nonsense.
First of all the source code comes from a source code control system, secondly if you use maven/gradle then the jar repository usually always contains a code.jar and a source.jar (and the 'make file' to make one from the other).
This is nonsense (Score:3)
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.
Re:This is nonsense (Score:4, Interesting)
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: (Score:2)
As soon as you documented this very carefully and very hard to miss in the code and in the written documentation, I have absolutely no problem with this approach. Competent risk management is not about perfection, it is about balancing cost and risk-costs and avoiding catastrophe-level events.
Re: (Score:2)
If you use established Linux kernel core coders, you get completely different numbers compared to using newbie kernel driver coders.
Do you? Is that why the top 6 products [cvedetails.com] with the most vulnerabilities in 2018 were all Linux products? Is that why the Linux kernel had the second highest number of vulnerabilities [cvedetails.com] in 2017?
C coders don't seem to be that great at security.
Re: (Score:2)
You seem to be functionally illiterate. Because what you criticize is very clearly not what I said. I did, in fact, not make any claim as to Linux security vs. other products. But that seems to have completely escaped you. Which is hilarious, because you even quote the line that you were unable to comprehend.
Re: (Score:2)
Re: (Score:2)
You continue to be clueless. I did not claim C was a good or bad language either. I just used it to explain a deep flaw in the comparison made.
Re: (Score:2)
It's time to put up or shut up, kid.
Re: (Score:3)
Do you? Is that why the top 6 products [cvedetails.com] with the most vulnerabilities in 2018 were all Linux products? Is that why the Linux kernel had the second highest number of vulnerabilities [cvedetails.com] in 2017?
You're conflating two different concepts. We have no way of knowing what piece of code has the highest number of vulnerabilities. To find that out, we would have to freeze all development and then scour all existing code using some standardized methodology.
What you're talking about here is that the Linux kernel had the second highest number of vulnerabilities that were discovered. BIG difference.
The Linux kernel is open source and is by far the most widely used operating system in the world. Vulnerabili
Re: (Score:2)
Read my .sig
Assembler (Score:2)
You forgot assembler.
Re: (Score:2)
proper statistics (Score:2)
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?).
Re: (Score:2)
Re: (Score:2)
There are a couple LOC counters that ignore comments and don't count lines with only opening or closing paranthesis etc. etc. - it's not like this is the first time the issue appears.
Since they are not listed... (Score:3)
Look at Defect Density (Score:5, Insightful)
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...
Re: (Score:3)
Correct. In simpler terms: we need to measure the frequency of vulnerabilities per volume of code written by similarly-experienced programmers; the difficulty in teaching people to avoid those vulnerabilities; the ease in which lazy programming can create vulnerabilities; the scope of an exploit; and the stability of executing an exploit.
C#, for example, seems to be less vulnerable than Java for...some reason. I don't know why. Java seems to have failures that it shouldn't have, and C# should only be b
Re: (Score:3)
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...
You've confused C and C++. C was 47%. C++ was 5%. It's almost as if they aren't the same language.
*Face palm* (Score:2)
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
Re:the problem is engineering competency relative (Score:5, Insightful)
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.
Re: (Score:3)
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-notc
Re:the problem is engineering competency relative (Score:4, Informative)
its not hard to write secure c
And yet 70 percent of all security bugs [zdnet.com] are memory safety issues.
If only there was some kind of language [rust-lang.org] which was designed to reduce memory safety bugs.
Re: (Score:2)