When it comes to an organization's software security, there's been a chronic disconnect between the developers who write and build the code and the security teams who audit and enforce the code's security. This divide historically arose from common misunderstandings: programmers believe that security hinders their productivity, while security folks are frustrated that security is not at their top-of-mind.
The relationship between development and security doesn't need to be hostile, and there are ways to engage developers more with security. As Bruce Schneier says, “Security is a process,” and your development team is an integral part of that process. And, while change is hard to come by, it is possible.
How can you get developers on board with you? There are a number of simple areas to focus on to ensure your developers start loving (or at least don't hate) security.
Start with the understanding that it is essential to get top management involved to ensure that security is perceived as important. By aligning security with business objectives and with the vocal support from your organization's CEO or CIO to make it clear that security is just as high a priority as great features and non-buggy interfaces, the rest of the company is much more likely to fall in line. The key to getting the support of management is to approach them with the business value: Secure coding practices prevents underlying causes of the majority of security incidents, ensures compliancy with common standards and is part of the business-customer trust relationship.
With that high-level organizational shift you will be better armed to get your developers to care more about security and you can start to put in place internal structures that will encourage them to do so. Give your development team leaders an opportunity to share their challenges and successes with your security team by hosting discussion roundtables. That way, you can build camaraderie among the two groups as well as allowing team leaders to align their expectations for security implementations with each other. Allow them to cross-examine coding bugs and security flaws, mapping them back to the source in the way your developers are already comfortable with.
Once you've established a relationship with the developers and their managers, they will begin to see you in a less oppositional light. Create an online cross-team collaboration platform where developers and the security team are free to ask security-related questions, with dedicated members of the security team answering.
Developers are going to be wary of the security team butting in on code, no matter the security issues, so it's important to come at them in the correct way. Starting conversations around the latest vulnerabilities, security issues and secure development tips will give you an "in" to the developer's world. Arming them with knowledge of the latest attack vectors will go a long way in convincing them that secure coding does matter. So make sure to build and maintain credibility with the development team by offering information on recent security incidents and real-world attack walk-throughs. Learning how major breaches stemmed from vulnerable code will help them understand insecure code's impact and work toward remediating the issue.
Another essential part of the process is performing security assessments at each design milestone to greatly reduce the number of last-minute bugs. By making security a part of the Software Development Lifecycle (SDLC), you will create secure coding habits. After the initial architecture build and development, perform source code analysis and fix the issues. At the next milestone, do the same and analyze the number and type of security issues squashed earlier versus at this milestone. Rinse and repeat. Then, identify the common issues and integrate those lessons into your next security training. Not only will this practice allow you to eliminate issues earlier in the development process, it will also give your team a deeper understanding of what information the developers may need additional help with.
One of your most important jobs to make this all happen is to teach your developers to detect and treat security flaws with the same diligence they give to functionality bugs. If they're able to look at security vulnerabilities similarly to feature and usability bugs, that's an enormous step towards a more thorough approach to application security, because in the end, security flaws are bugs, just with a security consequence – as witnessed with the recent Heartbleed Bug.
Remember that developers, like most of us, appreciate being acknowledged for a job well done so make sure to recognize developers who routinely turn in secure code. Work with the QA team and development team leaders to pinpoint programmers who continually write secure code, or quickly fix their mistakes – and acknowledge their successes.
Those developers could eventually become your security champions, helping you relay your message of secure coding back to their team as well as offering you valuable developer feedback. These relationships will help bridge the gap between development and security, so it's essential to create positive experiences for your most secure coders and to get them to encourage others to start loving security.
