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.
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.]
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.