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.
Anything you register with an intel cpu is vulnerable - from the moment you install it. https://www.reuters.com/article/us-cyber-intel/intel-discloses-three-more-chip-flaws-idUSKBN1KZ280
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.
Ada
Pascal is the most secure.
.Net is only behind C and Java. VB.Net and C# individually are behind C++ in addition to the first two. Yet not mentioned in the post. Why?
It doesn't matter how good a programmer you are if the language interpreter/compiler has security bugs
so which language has the most bugs that the programmer cannot avoid?
and then try to give a bugs per 1000 lines of code metric (and then, thanks to git, look at the effect of code age on the bugs, how many bugs per 1000 lines were introduced in the last year vs a year a decade ago)
lots of numbers != valid statistics
choice of language is one of fit for purpose, though there is a problem of programmers without the ability to use a chosen language.
its not hard to write secure c its flaws are well studied and well known it is the useless engineers whos confidence exceed their abilities that are the problem. being able to write turds in javascript or java does not qualify you to write c. it is the continued failure to recognize this that results in failure.
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.
The world needs your help -
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.
Please help by giving us the types of language you describe above.
Other language features can force programmers to think through their designs more and/or make their code more clear and expressive.
What are those other languages" ?
Some language designs can even limit and constrain the possible logic errors that a program can commit.
How about giving us the names of those wonderful languages?
Many thanks in advance !!
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.
I wish people would stop perpetuating this myth. Programming in C is nothing like programming in assembler.
What access to the machine does C give you? Pointers, bitfields, and...that's about it. That's as low-level as you get. No interrupts, no traps, no stack operations, no BIOS calls, no MMU instructions. You need an actual assembler for that stuff.
This shit is really depressingly stupid. You might actually accomplish your goal of getting me to stop coming to slashdot entirely.
>> If only there was some kind of language which was designed to reduce memory safety bugs.
There is Rust. Rustâ(TM)s rich type system and ownership model guarantee memory-safety and thread-safety â" and enable you to eliminate many classes of bugs at compile-time. See https://www.rust-lang.org .
Did you just walk into the wrong room?
C++ is nearly as popular as C and yet it only has 5% vulnerability share compared to C at 47% ! Even Java, the so called secure lamguage, did worse.
This somewhat proves all the C++ haters wrong, C++ is a great language and doesn't lead to bugs! Yeah C++ lets you shoot yourself in the foot with a cannon if you want but it comes with a variety of tools so most people wont be using a cannon where a slingshot would do.
...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 any other language that is never used.
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.
It's ok, the mentally handicapped person is just figuring out copy and paste. It's the only thing worth anything in their life.
1) we all know it depends mostly on the skill of the developer.
2) you can do things in c you can't, or don't want to do, in other languages. These are hardly vulnerabilities.
Methodology and starting statement are both ignorant of reality.
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...
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...
Quite an interesting topic I must admit. But it's important not to forget about the fact that some software development tools are made to solve specific problems and they are perfect for only a narrow range of tasks. Architecture is another important issue I think. Just spend some time reading about microservices architecture in the article and you'll get my point.
How about asking, which programming languages allow any hacker/malware to exploit almost any bug anywhere in the code, to gain full access to any computer?
Answer: C/C++!!
The problem is that many reasonable and intelligent comments get stuck at -1 because they didn't sit well with one of the cliques, so you're left with either browsing the cesspool at -1 to extract useful comments that got intentionally buried, or a censored version of Slashdot at 0, which is functionally no different to "lesser" sites other than the real filth is retained.
There is no silver bullet.
There is no silver bullet. But you can still have better results when some class of errors is ruled out at compile time or sooner. E.g. double de-allocation ruled out in a garbage collected language.
Too bad your mother didn't correct the biggest mistake of her life.
The masculine prefix is were. We still use it for words like werewolf.
I doubt we'll ever go back to archiac gendered terms because that's not how the feminist movement works. It is about tearing down perceived obstacles rather than gaining perspective through studying history. Women's studies is anti-academic and a waste of time, it has nothing to do with women and everything to do with selling garbage books.
security vulnerabilities are in the libraries, the parser, the interpreditor, the compiler or even in the operating system or the microprocessor..
not in the language!
Any programming language making pretensions of efficiency and flexibility, such that it might be attractive to Real Programmers, has ways to bypass whatever error-checking it might otherwise do. The older the language, the more back doors are available (because it's closer to the hardware), and the more likely that it's still used when flexibility and efficiency are demanded - as in system programming and high performance computing. Which, of course, is one of the reasons why C and FORTRAN are still around. Does anybody still work in assembler?
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
A good developer is not just about how well they use the tools at their disposal, but also the selection of the tools they use.
For example, you are a carpenter, and you have a planer that you inherited that is a great planer, but only if you put the wood in just right. If not, the planer takes huge chunks out of the wood and spits it out at a high speed, often injuring the operator.
You have no problems putting the wood in at just the right angle because you've gotten used to the tool.
But your brother, who comes over to your workshop occasionally on Saturdays, is continually cussing the planer because it always ruins his wood, and on one or two occasions, its slammed the wood painfully into his hand and arm.
You can wax rhapsodic about how wonderful the planer is...your brother, on the other hand, thinks it's a piece of shit because of his first impressions...and because he doesn't have time to invest in making it work right...he's only there occasionally on Saturdays.
So taking this into account, if the choice of tool means that you have a higher potential of better outcomes, not just for you and other rockstar developers, but everyone on the team, then make that choice. Move away from the planer that gives great results if, and only if, you do it the way the tool expects. Move to the tools that give just as good result, but also have good safety guards so you can concentrate on getting the logic right and not worry about language errata.
... posting meaningless garbage.
at least for some.. so what the problem?
I come to Slashdot only to read sigs. One you are reading is mine.
Only Google loving testicle gobblers take the "python is more secure, not in the same class approach"
Yeah, Google is fucking gay, pushed python like crazy, and that is the only reason it's used. Because retards who work for Google LOVE the CIA asset Google. Sheep love anything FBI asset Google does. Google could sacrifice children in front of you and they'd still 'not be in the same class'.
Python is insecure as fuck and plenty of 0days exists for that piece of shit Google propped up language. It is owned on the regular. In fact, I'm going to own a bunch of more python boxes this week just to spite your dumbass, perhaps even try to poison git repositories and get some nice shit pushed up just for you cupcake
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.
Sir, this is an Arby's!!
Classic Bill
C was built to allow moving OS functions functions from machine to machine - as in a PDP-11.
PDP-11 has 7 modes of addressing, but just 2 are here.
p(i++) maps directly to machine instruction - yes just 2 machine instruction one is normal. One a specail case PUSH!
p(--i) again just 2.. one being POP of stack R7 I believe.
Really need to take time and laern the hisstory and actually write for the machines. PS: myfirst C program was for comm. Not hello world. It used Pointers of Pointers to handle multiple ring buffers. What yours?
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 ?
Where are all the non-toy projects using Rust except Firefox? I do agree though, a language that no one uses will have the greatest security track record.
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.
A programming language cant have security vulnerabilities.
It would be trivial to mitigate most of that spam by leaving comments at 20 or so rows of visibility. Takes a quarter second to flick past it then. Currently they can take twenty screens worth of scroll space...
Or a simple distance test from a new post to previously flagged spam posts. It's retarded simple, has been used for 30 years, and would instantly fix the problem.
But this is /. where we're lucky if the website loads on something later than Netscape Navigator.
indeed.
The problem is - wherever you go, you either have moderating policies that are going direction censorship or you get idiocy like this
Slashdot has a selective censorship policy.
If you type in a message condemning the colored minorities (usually with the N-word) or a message berating a certain religion (of peace) your message will be nuked.
But if you typed in swastika and all other anti-Jewish garbage your message will be kept.
Remember, Slashdot is now owned by some middle eastern oil dude.
> Remember, Slashdot is now owned by some middle eastern oil dude.
Some muslim nígger?
The programming language that allows the most vulnerabilities is the one that allows you to actually control the computer.
All of these "safe" languages get you further and further from actually controlling the computer... and help it to control you. Most of these "safe" languages attain safety by preventing you from doing things it considers undesirable. Soon enough this will include things like copying videos or visiting websites that the company doesn't want you to see. Because you do not control it at a fundamental level, you can only do what the computer sees fit to permit you to do.
There are unpleasant tradeoffs between freedom and security. If you want to control the computer, rather than the computer controlling you, then you're going to have to accept some vulnerabilities. But people don't think like that anymore, and it's going to fuck everyone over, even those aware of this fact (because they are outnumbered).
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