Vulnerabilities / Threats
11/21/2013
05:57 AM
Tim Wilson
Tim Wilson
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%

Study: Most Application Developers Don't Know Security, But Can Learn

Solid training of app developers can reduce vulnerabilities, Denim Group study says

NEW YORK, N.Y -- AppSec USA 2013 -- Most application developers still aren't security-savvy, but training can make a difference, according to study results outlined here Wednesday.

The study, conducted by professional services firm Denim Group, tested some 600 application developers -- most of whom had fewer than three days of security training -- on their knowledge of secure coding practices.

Quizzed on 15 questions, less than a third of the respondents (27 percent) accurately answered more than 70 percent of the test. The average score on the quiz was 59 percent. Developers with more than seven years of experience fared no better than those with fewer than three years of experience.

"Most of them understood high-level concepts, such as how to recognize a cross-site scripting vulnerability, but when we asked them how to remediate it, most of them couldn't answer correctly," said John Dickson, CEO of Denim Group, in a presentation of the study results.

The Denim Group then gave the respondents a secure application development course and tested them again. After training, the average score on the test rose to 74 percent, and about two-thirds of respondents scored 70 percent or higher. The students reported that their security-related application vulnerabilities were reduced by 70 percent after training.

"What this shows is that security training makes a difference," Dickson said. "If you do training right, you can expect to reduce vulnerabilities."

The study also pointed out some flaws in the secure development process. For example, while most application development teams rely on quality assurance staff to catch security problems in developing code, QA staff turned in the lowest scores on the initial test, scoring lower than those who described themselves as developers or architects.

"A lot of companies put their least experienced people on the QA team, and they are actually the least knowledgeable in security," Dickson observed. "But without any training, how are those people supposed to catch the security issues?"

Interestingly, respondents who worked in the largest companies -- companies with 10,000 employees or more -- scored lowest on the initial test, with a passing rate of just 19 percent.

"The category that does the most in-house development had the lowest scores," Dickson said.

Experts at the AppSec 2013 conference said that until developers become more security-savvy, the incidence of vulnerabilities will continue to remain high.

"Security is still not built into the preproduction process," said Bala Venkat, chief marketing officer at Cenzic, an application security tool vendor. "It's not built into the application development process; it's not part of the education process at most universities. Until security training becomes a requirement, we will continue to have problems."

Although software development tools are rapidly evolving and attacks are becoming more sophisticated, most companies are still wrestling with application vulnerabilities that are years old, noted Chris Eng, vice president of research at Veracode, an application security tool vendor.

"We're still seeing SQL injection flaws that we've been seeing for a decade," Eng said. "The core vulnerabilities are still the same, and that speaks to the need for better training. You can't just give a classroom course and forget it. You have to retest and reinforce the concepts, and let your developers see them in practice."

Most organizations still don't offer incentives for developers to write secure code, noted Jeremiah Grossman, founder and CTO of application security vendor WhiteHat Security.

"Do software developers get rewarded for writing code without vulnerabilities? No, they are usually rewarded for speed and functionality. But if you hold developers accountable for vulnerabilities and incent them to write more secure code, then it matters to them. Then you begin to see an impact."

New requirements for training may change the way software developers approach security," Dickson said. The new Payment Card Industry Data Security Standard 3.0, for example, requires that developers are trained and tested in secure coding practices, he noted.

"As security becomes more important to industries and organizations, I believe we will see a real change in the way developers are trained," said Cenzic's Venkat. "It has to be a mandate. I'm positive it will happen."

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
marktroester
50%
50%
marktroester,
User Rank: Apprentice
11/22/2013 | 7:44:15 PM
re: Study: Most Application Developers Don't Know Security, But Can Learn
I just returned from the AppSec conference as well and there were many interesting topics, including the new OWASP top 10 requirement relating to application components (A9). This relates to the conversation about training and developer incentives because it makes the problem even more difficult. Even if developers are great about writing secure code in their custom code, they still need protection for all of the components that are being used to assemble the apps. Recent research shows that up to 80% or more of an application now consists of components. The addition of A9 to the Top 10 accounts for component usage and states that vulnerable components should not be used. Sounds pretty basic right? Well it does until you realize how hard it is too avoid or vet every component - this isn't easy given the volume, variety, complexity and release cadence of components. And one primary complexity factor is the wide number of dependencies that are pulled in when you utilize a component - the component that you pull into your app depends on other components, which depend on other components, etc.

For a white paper on the OWASP A9 and PCI component considerations, check here:

http://www.sonatype.com/resour...

Thanks,
Mark Troester
Sonatype
@mtroester
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0619
Published: 2014-10-23
Untrusted search path vulnerability in Hamster Free ZIP Archiver 2.0.1.7 allows local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse dwmapi.dll that is located in the current working directory.

CVE-2014-2230
Published: 2014-10-23
Open redirect vulnerability in the header function in adclick.php in OpenX 2.8.10 and earlier allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the (1) dest parameter to adclick.php or (2) _maxdest parameter to ck.php.

CVE-2014-7281
Published: 2014-10-23
Cross-site request forgery (CSRF) vulnerability in Shenzhen Tenda Technology Tenda A32 Router with firmware 5.07.53_CN allows remote attackers to hijack the authentication of administrators for requests that reboot the device via a request to goform/SysToolReboot.

CVE-2014-7292
Published: 2014-10-23
Open redirect vulnerability in the Click-Through feature in Newtelligence dasBlog 2.1 (2.1.8102.813), 2.2 (2.2.8279.16125), and 2.3 (2.3.9074.18820) allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the url parameter to ct.ashx.

CVE-2014-8071
Published: 2014-10-23
Multiple cross-site scripting (XSS) vulnerabilities in OpenMRS 2.1 Standalone Edition allow remote attackers to inject arbitrary web script or HTML via the (1) givenName, (2) familyName, (3) address1, or (4) address2 parameter to registrationapp/registerPatient.page; the (5) comment parameter to all...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.