It can seem overwhelming for security people who are typically housed in a separate organization, to begin to engage with software developers and architects to implement secure coding practices in an enterprise. While the security team may know that there are security vulnerabilities in the systems, they have to be able to articulate the specific issues and communicate some ideas on resolutions. This can be a daunting task especially if the security team does not have a prior workign relationship with the development staff, and understand their environment.The start of what it will take.
The task seems daunting also because there are so many developers compared to security people. I am here to tell you though that you don’t have to win over every last developer to make some major improvements. In my experience a small percentage of developers write the majority of code that actually goes live. The lead developers (who may be buried deep in the org charts) are the ones you need to engage, in many cases they really don’t want to write insecure code, they just lack the knowledge of how to build better. Once you have a relationship (i.e. that you are not just there to audit and report on them, but are there to help *build* more secure code) it is surprisingly easy to get security improvements into a system, especially if the design is well thought and clearly articulated. You don’t have get the proverbial stardotstar, each and every developer on board to make positive improvements, it can be incremental. See some more specific ideas on phasing security in the SD! LC here. In meantime, with security budgets increasing 20% a year, use some of that money to take your top developers out to lunch.
— Secure Coding – Getting Buy In, Gunnar Peterson, 1Raindrop, 17 Sep 2007