Application Security

5/11/2017
02:00 PM
Peter Chestna
Peter Chestna
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

What Developers Don't Know About Security Can Hurt You

Developers won't start writing secure code just because you tell them it's part of their job. You need to give them the right training, support, and tools to instill a security mindset.

The idea that developers don't care about security hasn't gone away. Honestly, I wasn't even aware of it in my early career as a developer. That was probably the case with many of my peers as well. But times are changing and developers' awareness and attitudes are changing, too. A Veracode survey asking developers about their top concerns found that 37% identified cyberattacks and data breaches as their top concern.

Yet there's still a long way to go to in developing more-secure software. Application-layer attacks are the top source of data breaches, and that's a huge problem for all of us.

The disconnect here — developers care about security, but software is still insecure — comes down to developers lacking the appropriate training. For most developers, training in application security concepts and practices hasn't been part of their career development and, until now, hasn't been a priority for development teams or operations. Security and IT departments bear some of the blame, for not giving developers resources to build in security early in the development life cycle.  

This is changing with the rise of DevOps. It's hard to overstate how much of a paradigm shift DevOps is, as development moves from a specialty to a multidisciplinary skill set. Developers have to assume responsibility for the quality of the entire software development life cycle, from coding through production.

Before I became an application security evangelist, I managed a team of developers at Veracode, leading the engineering team for the Web platform. Managing developers can be like herding cats, and it only gets worse if you don't clearly communicate requirements and accountability. Without the right mindset — that security is just another nonfunctional requirement — developers can suffer from culture shock when you subject their code to rigorous security testing.

You need to coach developers — by holding out carrots, not by whacking them with sticks — to move them along the way to better security skills. Getting security right is hard! You can start by giving them the right training, support, and tools to make security a seamless part of their workflow. You definitely won't get anywhere by blaming developers for security failures that, in reality, are everyone's responsibility.

Empathy and Acceptance
Because security isn't ingrained in traditional developer training and education, developers don't always respond well to security assessments that highlight flaws in their code. Developers invest time, attention, and emotional energy into the code they produce. Pointing out errors in their code can cause developers to react with frustration, annoyance, or even hostility. As a security manager, you must have empathy. DevOps requires a culture of feedback and continuous improvement, and security needs to be a part of this. But acceptance comes with time, and it comes more quickly and easily when you respond to developer concerns.

Training and Enablement
Any great AppSec program will have some sort of training available to developers that respects developers' time and their other requirements. Make it easy for developers to access security knowledge that meshes with their daily workflow, such as on-demand, bite-sized security courses. According to our research, development teams using e-learning saw a 55% reduction in flaw density (number of flaws per megabyte of code) between the first scan and most recent scan. That rate of reduction was six times better than teams without e-learning.

However, you can and should build on e-learning with code reviews and remediation guidance from security experts. Regular security testing and remediation cycles, and working toward achievably higher standards over time, instill confidence as developers synthesize new skills. You can help your cause by encouraging developers to embrace skills growth as a career enhancement — for example, through instructional courses and certifications, such as the Certified Secure Software Lifecycle Professional certification.

Security Champions
Developers respond to other developers. Recruit developers who are more interested in security to become security "champions" within their teams. These internal champions can amplify the security message on a peer-to-peer level, provide you feedback into how the security strategy is received, and make suggestions for improvements to your process.

[Check out the two-day Dark Reading Cybersecurity Crash Course at Interop ITX, May 15 & 16, where Dark Reading editors and some of the industry's top cybersecurity experts will share the latest data security trends and best practices.]

Automate Testing
To get developers on board with an application security testing regime, you have to remove as many obstacles as possible that would slow down the developer. Going back to our survey of developers, we found out that 52% of developers believe security testing causes delays in development and threatens deadlines.

With the shift to DevOps and continuous integration/continuous deployment, integrations are increasingly important. Developers are creating and testing code in smaller pieces more frequently and releasing updates more regularly. That means testing applications more frequently, so it's important that testing technologies can be automated from the tools that developers are already accustomed to using.

Do No Harm
So, what's the bottom line? Identifying and fixing flaws in the coding stage of the software development life cycle is the most efficient tactic and also the most cost-effective. According to the National Institute of Standards and Technology, fixing flaws in production is six times more costly than doing so in the coding stage, and 30 times more costly than fixing defects in the planning/architecture stage.

CISOs and boards of directors are starting to recognize this. Although secure coding skills were once a nice-to-have, security is now a need-to-have. As the responsibility for securing applications increasingly depends on developers, organizations must invest more in developer training and security testing tools that empower developers to find and fix coding defects without disrupting their workflow. What developers don't know about security can hurt them and hinder security efforts. And that hurts everyone.

Related Content:

As Director of Developer Engagement, Peter Chestna provides customers with practical advice on how to successfully roll out developer-centric application security programs. Relying on more than 10 years of direct AppSec experience as both a developer and development leader, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
Oracle Product Rollout Underscores Need for Trust in the Cloud
Kelly Sheridan, Associate Editor, Dark Reading,  12/11/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Gee, these virtual reality goggles work great!!! 
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.