Following Best Coding Practices Doesn't Always Mean Better Security 61
wiredmikey writes "While some best practices such as software security training are effective in getting developers to write secure code, following best practices does not necessarily lead to better security, WhiteHat Security has found. Software security controls and best practices had some impact on the actual security of organizations, but not as much as one would expect, WhiteHat Security said in its Website Security Statistics Report. The report correlated vulnerability data from tens of thousands of Websites with the software development lifecycle (SDLC) activity data obtained via a survey. But there is good news — as organizations introduced best practices in secure software development, the average number of serious vulnerabilities found per Website declined dramatically over the past two years. 'Organizations need to understand how different parts of the SDLC affects how vulnerabilities are introduced during software development,' Jeremiah Grossman, co-founder and CTO of WhiteHat said. Interestingly, all the Websites tested under the study, 86 percent had at least one serious vulnerability exposed to attack every single day in 2012, and on average, resolving vulnerabilities took 193 days from the time an organization was first notified of the issue."
"best practice" and surveys (Score:5, Insightful)
Asking software companies if the require their developers to adhere to "best practice" won't lead to any usefull number at all.
Or does anyone think anyone would admit to use only second-best programming standards?
Let alone the question what programming techniques count as "best practice".
Rules should be treated like guidelines (Score:5, Insightful)
If secure coding could be described by a few simple rules, coders would have already been replaced by programs.
Best practices (Score:5, Insightful)
"Best practices" is such a wonderful term; its sheer flexibility permits the person invoking it to assure his audience that he meant exactly what he said, even when he didn't say much of substance.
Now if you'll excuse me, I'm late for a game of bullshit bingo [bullshitbingo.net].
No surprise (Score:4, Insightful)
Secure code needs a holistic view. The usual component architecture that works pretty well for reliability and correctness, but not so well for performance, fails utterly for security. What is needed is a really competent secure software expert, that can do everything from architecture down to coding and is part of the team right from the beginning. This person must also have means to enforce security. Unfortunately, people that can do this job are very rare, and most projects do not have that role anyways.
Re:Following best architectural design practices (Score:5, Insightful)
Following best practices in code will most definitely make your code more secure. But more secure is very relative. You can still have plenty of vulnerabilities, just fewer than before.
Best practices or no, we all make mistakes, and plenty of them. It only takes one mistake to leave a hole. Whether it is a simple bug, or a design flaw. And the bad guys only need to find one flaw. So yes Best Practices help. But it doesn't mean your code is going to be Fort Knox.
Re: No surprise (Score:5, Insightful)
Been there, done that, made redundant.
This was at a software house selling payment processing middleware that had to be PA-DSS compliant. Achieved compliance, role made redundant.
They clearly made a risk reward calculation and decided the benefit of securing the product was outweighed by the cost of slowing development. Particularly as everyone else's security also sucked and there was no particular liability for them if a breach occurred. It's a classic externality.
I'm also on the steering committee for an initiative trying to improve software security and resilience. They also figured out that the market was failing here, and only legislation for software liability or some other mechanism to correct the externality had any chance of improving the situation. But the cure might be worse than the disease. ..
Having good engineers (Score:2, Insightful)
is more important than having managers that insist that engineers follow every guideline from the MS Press book, or whatever.
For example, one of the guidelines is always "do not use sprintf". But sprintf is perfectly safe in cases like this:
std::string myfunc( int i ) {
char buffer[80];
sprintf( buffer, "Your number=%d", i );
return buffer;
}
So what we sometimes see is a lot of mindless replacements of perfectly good function calls with slower, more difficult-to-read counterparts, where the process of substitution may have produced bugs. Ordered by management during scrum so he can rattle off metrics to his boss on how much more "secure" the code base is now than three weeks ago.