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.


11:17 PM

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
Oldest First  |  Newest First  |  Threaded View
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.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
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
PUBLISHED: 2021-05-14
An HTTP Request Smuggling vulnerability in Pulse Secure Virtual Traffic Manager before 21.1 could allow an attacker to smuggle an HTTP request through an HTTP/2 Header. This vulnerability is resolved in 21.1, 20.3R1, 20.2R1, 20.1R2, 19.2R4, and 18.2R3.
PUBLISHED: 2021-05-14
Hexagon G!nius Auskunftsportal before allows SQL injection via the GiPWorkflow/Service/DownloadPublicFile id parameter.
PUBLISHED: 2021-05-13
Piwigo 11.4.0 allows admin/user_list_backend.php order[0][dir] SQL Injection.
PUBLISHED: 2021-05-13
The Flask-Caching extension through 1.10.1 for Flask relies on Pickle for serialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the ca...
PUBLISHED: 2021-05-13
Bitcoin Core 0.12.0 through 0.21.1 does not properly implement the replacement policy specified in BIP125, which makes it easier for attackers to trigger a loss of funds, or a denial of service attack against downstream projects such as Lightning network nodes. An unconfirmed child transaction with ...