Over Half of Software Fails First Security Tests 145
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."
That's great. (Score:4, Insightful)
Now they need to test the users.....
What emphasis on security? (Score:5, Insightful)
I thought the only measure of a project was whether it makes the deadline.
Bolting On (Score:4, Insightful)
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.
Open source doesn't necessarily mean dangerous (Score:3, Insightful)
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.
Security firm says security is an issue (Score:5, Insightful)
Hmmm . . . there's a word for that . . . XKCD, can you help me?
http://www.xkcd.com/703/ [xkcd.com]
Re:Security is no selling point (Score:4, Insightful)
Protecting against SQL injection attacks, XSS, buffer overflows, and validating user input does not put off users.
Re:Bolting On (Score:3, Insightful)
Designing for security and using secure coding practices from the beginning, however, makes it much, much easier.
Sure it does... but that sort of design takes money and expertise. More often software is dreamed up and planned in ad hoc meetings. For example, a person in marketing decides it would be a great idea if their customers can get updates on their phones and Nitwitter accounts. In a 4PM meeting the marketer proposes it to his boss as a necessary value-add function without which the competition would eat us alive (1).
The next day, a "planning" meeting is called. The marketing manager tells (note, I say "tells" not "asks for input") the programming manager that the company needs mobile updates. The company needs (note, it's changed from the "Marketer wants" to "company needs") it before the next peak retail opportunity. This opportunity is either Valentine's Day or Easter or Summer Break or Thanksgiving or some other arbitrary retail holiday.
The programming manager tells his programmer, "We need it by end of week."
The programmer begins to think about the problem. He raises objections to the timeline and lack of design. The marketing manager cries to the CEO. The CEO screams at the CTO. The CTO screams at the programming manager. The manager tells the programmer that he's wasted a day and we still need it by end of week.
The programmer thinks about coding and how to grab the data he needs. He browses a database and finds a table that he needs. To make it accessible to the web frontend, he opens up some permissions. Maybe he creates a new view that combines multiple tables to make his code easier or faster. This new view now violates PCI and SOX regulations, but he doesn't care.. this is just for testing until he can figure out how to do it properly. He stays up all night and gets a proof of concept working. The next day he shows it to his manager.
His manager says, "OK, tell them it's done."
The test software becomes production.
In other news... (Score:4, Insightful)
"remediate"? (Score:3, Insightful)
Re:That's great. (Score:3, Insightful)
Your viewpoint is a little close-minded. Most software written is never even sold. It is mainly in-house custom apps in companies where it would be pointless to try to exploit it because there are easier ways to get the data. And how about the software that runs completely closed on microcontrollers that are in every single product sold today?? Think before you post. :)
Re:Code has bugs... so don't trust it. (Score:3, Insightful)
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 (Score:2, Insightful)
Re:As misleading as 'Show all warnings' (Score:4, Insightful)
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.
Secure web app design is HARD (Score:4, Insightful)
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.....