Slashdot Mirror
Over Half of Software Fails First Security Tests
An anonymous reader writes "Even with all of the emphasis on writing software with security in mind, most software applications remain riddled with security holes, according to a new report released today about the actual security quality of all types of software. Close to 60 percent of the applications tested by application security company Veracode in the past year-and-a-half failed to achieve a successful rating in their first round of testing. And this data is based on software developers who took the time and effort to have their code tested — who knows about the others."
Reader sgtrock pointed out another interesting snippet from the article: "'The conventional wisdom is that open source is risky. But open source was no worse than commercial software upon first submission. That's encouraging,' Oberg says. And it was the quickest to remediate any flaws: 'It took about 30 days to remediate open-source software, and much longer for commercial and internal projects,' he says."
Now they need to test the users.....
"City hall" in German is "Rathaus" Kinda explains a few things......
I thought the only measure of a project was whether it makes the deadline.
As Bruce Schneier has said, trying to bolt on security to an existing product or application can be very difficult and time consuming. Sometimes you even have to redesign things. Designing for security and using secure coding practices from the beginning, however, makes it much, much easier.
I know of at least one rather large and well-known company that doesn't use OSS because of "security", yet voluntarily continues to use IE6.
That sort of thing really pisses me off.
Living With a Nerd
And the other half isn't even tested.
Nerd rage is the funniest rage.
That's extrapolating a bit much, isn't it? And scanning through the article, they don't even name the sample size, just percentages.
And yes, they mention that its only the stuff that they test, "so imagine what the rest is like". Well - thats it though, if someone is professionally developing with security in mind, they probably know how to test it in office or know somebody who can. Thus - no need to pay this corporation to test something you can do yourself.
If you are developing with security in mind - but aren't sure exactly what you're looking to protect against - THATS when you go to companies like these.
This is a pretty much skewed data source (probably a slashvertisement for them, too), and is the only study of its type. Take it with a weeks worth of salt.
It just is not. Actually, quite the opposite: The better your security, the more your potential customer will be put off by it.
Users do not care about security until it is too late (i.e. until after they got infected), and only then they will bitch and rant and complain how insecure your piece of junk is. If you, otoh, take security serious and implement it sensibly, they will bitch and rant already at install because they hate the hoops to jump through and the obstacles to dodge to make your software "just work".
Security is the antagonist to comfort. By its very definition. No matter where you look, security always means "additional work". Either to the user, which means overhead to his work, or to the program, which means it will invariably be slower than its competing products.
Thus security is not only an "unnecessary evil" when selling your product. It is actually hurting you when you try to convince someone to buy your stuff. Your software will be slower due to its security "burden", and it will be less comfortable to the user. The user does not see the glaring security holes when he buys the product. Only after, when the product bites him in the ass because it opened him up to an attack. But by then, he will already have paid for your product. And he will have bought your product instead of the more secure product your competitor offered, because yours was faster and easier to use.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Hmmm . . . there's a word for that . . . XKCD, can you help me?
http://www.xkcd.com/703/
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
So lots of comparisons between open source and commercial software; however there is a lot of open source software that is sold, i.e. commercial. In addition it has been shown that most of the code for the Linux kernel was developed by people who were paid to do it by Red Hat, IBM, Intel and others. Does that mean that the Linux Kernel is commercial software.
May be the article should refer to closed source proprietary and open source software.
The article reads as if the author does not fully understand the how Open Source software is developed and is just a large advert (a.k.a. press release) for the auditing software.
Slashdot Beta should die a painful death.
Will a security firm ever certify that a solution is perfect on the first pass? Not if they want to be invited back for a second.
More than 90% of all software tested fails to compile the first time. Seriously, that's what security testing is for - finding holes so they can be filled.
Poor means hoping the toothache goes away.
Coming from the systems integration side of things, I don't view this as a surprise. Developers are great at writing software, but in my experience they have no idea about how the platform they're deploying it on actually works beyond the API function calls they make. This leads to internal applications that I have to throw back because part of the requirements are, "User must be a member of the Administrators or Power Users group." Most dev guys just don't get that it's very dangerous to give the end user full rights to an Internet-connected Windows box. There's just too many holes in Windows to safely allow it.
To be fair, there are a lot of reasons for stuff like this...not the least of which is deadlines for deploying "something that works." I've been there on the systems side too...scrambling at the last second to get hardware and operating systems deployed because of a deployment date. There are also a lot of apps coded in C++ and other unmanaged languages that open the system up for all sorts of buffer overrun attacks. Not much you can do there except vigilant code checking.
I think a little education on both sides of the fence would be useful. Developers should get some kind of training in "systems administration and internals for developers" and systems guys should definitely be educated in what holes are safe to open up on their systems. (That's a big cause of this too -- there's a lot of low-skilled systems admins out there who take the developer's instructions at face value without checking to see if full access is really needed.)
Try "remedy", or does that not sound pseudo-technical enough?
The conventional wisdom is that open source is risky.
Does anyone believe that anymore, other than journalists quoting other journalists and PR people?
I did some google searching, trying to find when that old FUD campaign started. It seems to not show up much until 1998.
The 12 year old advertising/FUD campaign is getting kind of tired.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
The reason users mess things up is that they have bad tools. There is no simple way to run something in a sandbox.
Comment removed based on user account deletion
I've worked with managers and developers that want to eliminate all the warnings in the source.
There’s a good reason for that, and it’s not as petty as you think.
Warnings exist to let the programmer know that the actual behaviour might not be what the programmer thought was most intuitive. If it’s implicitly casting a float into an int, you damn well better know what that means and what effect it’s going to have on your code... it means that 1/2 == 0, for starters. Similarly, there’s absolutely no reason why you can’t use (count = 5) as an expression, except that its value is always 5, not true or false as you may have incorrectly thought.
Lazy, sloppy, or inexperienced programmers are going to fall for these sort of pitfalls. Experienced, careful ones won’t nearly as often. But if you force a lazy, sloppy, and inexperienced programmer to learn why the compiler is giving a warning and eliminate it, he’s going to end up slightly less lazy, more careful, and with a little more experience than he started with, because he’ll hopefully understand the warnings by then and know what the code is actually doing.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
I know you meant it in jest, but there's a serious point there.
First, having written a number of small utilities, and some larger GUI-based tools, I have to say that web app design is fundamentally more difficult primarily because you have a number of specific challenges in this area that only apply to them.
Not only do you have to deal with all the usual problems, but you also have to deal with XSRF, XSS, and so forth. This is because you are you have a program which is generating HTML code as output, not merely a nice UI that is the product of the code, and this is happening in a stateless environment so information is somewhat limited in the interaction well beyond what it would be normally. Furthermore, authentication is more difficult in a stateless environment, especially where multi-tier systems are involved.
Most people don't appreciate how easy these are to mess up and how hard they are to fix when a developer creates a project without adequate thought to security in the first place.....
LedgerSMB: Open source Accounting/ERP