Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

9/18/2012
11:17 PM
50%
50%

Real-World Developers Still Not Coding Securely

Though secure development lifecycle advocates have shown the cost benefits of catching vulnerabilities before apps go live, organizations still don't embed security into development

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mmulhern76101
50%
50%
mmulhern76101,
User Rank: Apprentice
9/19/2012 | 3:35:12 PM
re: Real-World Developers Still Not Coding Securely
regarding "It would be easy to blame developers for slip-shod work":- you are being too gentle.- As long as managers have ready-made scapegoats available, they have absolutely zero motivation to allocate more resources, that is, time.
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3460
PUBLISHED: 2021-04-13
The Motorola MH702x devices, prior to version 2.0.0.301, do not properly verify the server certificate during communication with the support server which could lead to the communication channel being accessible by an attacker.
CVE-2021-3462
PUBLISHED: 2021-04-13
A privilege escalation vulnerability in Lenovo Power Management Driver for Windows 10, prior to version 1.67.17.54, that could allow unauthorized access to the driver's device object.
CVE-2021-3463
PUBLISHED: 2021-04-13
A null pointer dereference vulnerability in Lenovo Power Management Driver for Windows 10, prior to version 1.67.17.54, that could cause systems to experience a blue screen error.
CVE-2021-3471
PUBLISHED: 2021-04-13
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
CVE-2021-3473
PUBLISHED: 2021-04-13
An internal product security audit of Lenovo XClarity Controller (XCC) discovered that the XCC configuration backup/restore password may be written to an internal XCC log buffer if Lenovo XClarity Administrator (LXCA) is used to perform the backup/restore. The backup/restore password typically exist...