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
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3594
Published: 2014-08-22
Cross-site scripting (XSS) vulnerability in the Host Aggregates interface in OpenStack Dashboard (Horizon) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-3 allows remote administrators to inject arbitrary web script or HTML via a new host aggregate name.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.