Real-World Developers Still Not Coding Securely

The extreme pressure on developers from line-of-business leaders to push out new web application feature sets as quickly as possible, combined with a lack of security development objectives or actionable security guidance, continues to negatively impact web application vulnerability levels. A new study out this week based on a survey conducted by Forrester Research on behalf of Coverity showed web application incidents still remain expensive as a result of these vulnerabilities and are costing some organizations hundreds of thousands to millions of dollars.

[Learn more about best practices for protecting your databases. See Strategies For Protecting Web-Facing Databases . ]

Advocates have long argued for the benefits of embedding secure development life cycle (SDLC) principles into coders' day-to-day workflow in order to save on costs.

"The industry has been championing over the last couple of years is, if you can find software defects whether they're quality issues or they're security issues earlier in the cycle, it's going to cost you a lot less and take a lot less time to fix them," says Jennifer Johnson, vice president of marketing for Coverity.

But unreasonable development time constraints, impractical security tools that don't work well within real-world development settings and inadequate training on secure coding principles have all conspired together the squash the SDLC ethos at most dev shops. According to survey results, only 51% of organizations currently have coders conduct security testing, and only 40% of organizations report they test during development. And just 42% have any kind of secure coding guidelines in place within their organizations.

These lackluster numbers are directly impacting organization's ability to fend off hackers wise to the good odds of finding Mack-truck-size holes in business web applications.

"Web-facing applications offer hackers today some of the most direct--and easy--routes to compromising sensitive databases when these applications aren't securely coded or configured," says Gyutae Park, head of technology at Money Crashers Personal Finance.

According to Forrester's report, approximately 51% of organizations have had at least one security incident attributable to the exploitation of web application vulnerabilities. Among those reporting these incidents, 42% suffered losses of at least $100,000, with 8% reporting losses of over $1 million as a result of web app vulnerability exploitation.

It would be easy to blame developers for slip-shod work, but security experts say the real truth is that businesses need to do a better job setting coders up for security success.

"While application developers are on the front lines of securing access to applications, I would argue that organizations should do whatever they can to place the responsibility for security where it needs to be – the business--not where it has traditionally been forced to be--the application developer," says Jonathan Sander, senior director of IAM product management for Quest Software. "Developers do the best they can with what they have, which typically isn't enough as far as security and compliance are concerned."

Some of the biggest problems revolve around developer success metrics. While most developers are carefully evaluated on their ability to deliver features and functionality on deadline, their job performance is rarely measured by how securely they deliver that code. According to the Forrester report, 70% of organizations do not assess developers with security-related metrics.

Similarly, many developers feel that they're given inadequate tools to realistically test code in a real-world development environment. Just under a third of developers said they still haven't found suitable application security tools that work well with their development processes. The survey showed that the top three problems developers have with these tools is poor integration with development processes, high false-positive rates and a level of complexity that requires overtaxed developers to become security experts to use them.

"Tools that were designed for security auditors are great for security auditors," Johnson says. "But what we're seeing is they're trying to force fit these technologies into development and just expect them to use them."

Not to say that training isn't critical. It is, says Dylan Evans, vice president of operations for Reveal Digital Forensics and Security.

"The vast majority of web programmers are familiar with SQL injection and its sibling, Cross-Site Scripting, on a conceptual level, and many realize that these vulnerabilities can lead to massive damage for websites," Evans says. "However, understanding why something is dangerous and actively preparing for that danger are two different issues."

But much of the lack of training comes down to a lack of time. Learning secure coding principles and implementing them takes time that the business is just not giving its developers.

"In many cases, convenience and speed wins. Developers can code to get things done and the application to work as fast as possible, as that is the business need," says Stu Sjouwerman, founder of KnowBe4. "But coding for security, with the discipline to test all components for secure programming takes time."

Until that luxury of time is more amply provided, the benefits of SDLC will likely never be fully maximized. Given time constraints and the fact that SDLC can never completely erase every vulnerability before sending an application live, the need for after-the-fact vulnerability management will persist. No matter how great an SDLC program is, penetration tests, vulnerability scanning and application firewalls still will play an important role in managing vulnerabilities on production applications.

"Bottom line," says Rob Rachwald, director of security strategy, Imperva, "SDLCs are nice but vulnerabilities are inevitable and enterprises shouldn't let secure coding practices lull them into a false sense of security."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.