In two-plus years on the security consulting team at CA Veracode, and in my prior experience as a security researcher and software developer, I've heard this phrase countless times: "Developers are the biggest cause of security defects."
Sure, developers are the ones actively implementing the application – but they’re not the only ones involved in creating software. Lots of other people are involved in designing, coding, testing, and running software – and everyone needs to do their part to make sure it’s secure.
When an application has a security defect, we shouldn’t point fingers at the developers alone. Even developers with application security knowledge can create bugs. Have you ever written a script to solve a small problem ("no one will use this but me") that turned into a deployed product? It happens all the time. And because of incentives to prioritize business functionality, responsibility for security controls becomes an organizational hot potato.
The responsibility for application security extends beyond the developer. In many cases, I work with multiple teams to address the results of a CA Veracode analysis, not just developers. I sometimes find myself playing the role of mediator on consultation calls between developers, program managers, and IT groups.
Yes, developers do have a responsibility to prevent security defects, but so do the people around them. The best way we can ensure the security of applications is to think about how to build in security throughout the software development lifecycle (SDLC).
Here are some of the ways you can do your part at each stage of the SDLC.
Requirements: Application owners ensure security is a priority in order to avoid letting “business needs” trump logical security measures
Design: Software architects incorporate security features in the design from the beginning
Implementation: Developers leverage industry-agreed best practices, including techniques for input and output validation
Testing: QA groups get organizational buy-in to write security test cases
Maintenance: Operations engineers ensure secure production environments exist
Almost all application security issues can be solved before hands even reach a keyboard, through training and awareness. As a security consultant, I help the customers I interact with to build these security concepts into their programs. I also help by offering the perspective of an adversary. My career path has put me in situations where I've broken into applications and designed purposefully – though not detectably – insecure applications. Showing how adversaries might attack an application in production is an effective way, in my experience, to help others think with a defensive mindset.
You don't need an extensive background in penetration testing to start building secure practices into your SDLC. In fact, with the move towards DevOps, application security must become a shared responsibility, cross-cutting traditional roles. Everyone involved in the application building process is responsible for security and helping those around them build security concepts into their day-to-day work.
The best way to help: teach others why security is important, and, most importantly, have empathy for your colleagues and the challenges they face in securing the entire SDLC.