So imagine this: I am a developer sitting in my office/cube building great/new features for the next release of the product. Just as I am figuring out a complex algorithm and about to start coding, an information security person (I gotta be politically correct here and can’t say “guy”) walks in and says “Hey dude, are you checking your code for security vulnerabilities? You know we just bought a great set of tools that can “help” you find and fix them”. Now, the big dilemma… Would the developer totally and completely embrace this or would this be yet another step that (s)he has to perform, on top of the other 10 management mandated steps to be able to ship a product?
I spent a good chunk of my professional career running development and product management teams in small and big companies from Software Vendors to management consultants to IT professionals. I have found that there are only two ways that software people adopt a new technology or process. It’s either adopted virally, i.e. from the bottom-up or authoritatively from the top-down. The good news is that in both cases, assuming the technology and/or process they are adopting is good, they will eventually embrace it. Let me give you an example for each category. IDEs (Integrated Development Environments) are typically adopted from the bottom-up. Usually a small team of developers start using a certain one, whether it’s Eclipse, IntelliJ, Visual Studio, etc. and they start talking to their fellow developers about how great it is and before you know it, they are up at the VP level getting budget allocated for a purchase. These are technologies or processes and make life easier for the developers, i.e. assist them with shipping features on time. In the later category are products like Source Control systems. Early on in my career I remember trying to have developers understand the need and importance of having a single repository that could keep track of code integrity just to find myself face amazing resistance. This was because source control was not something that would help them build features better and faster. Nowadays, you can’t think of building a decent sized piece of software without a source control mechanism in place. So, although source control was initially mandated, it was eventually adopted. So with the right incentives and the right champions, as long as what you are trying to push makes sense, development organizations will listen.
I really think, we are at a phase now that developers are becoming rapidly aware of the threats insecure code could expose a company to. This has been partly due to market development by companies that from the very beginning believed in a Secure Development Lifecycle like ORCL, MSFT, etc. (we like to take some credit for it as well) combined with the bad guys being really busy hacking the living life out of mission critical systems and sometimes succeeding with dire consequences. The good news is that almost any company that builds software that their business depends on has come to the realization that having perimeter security, although important, is not enough.
There is no doubt that software security should ultimately be addressed where software is being produced, i.e. among developers, quality assurance professionals, build engineers AND where software is deployed, i.e. application ops centers. Having centralized information security groups is initially critical to spreading the need for a secure development lifecycle across the enterprise, but ultimately the process should be implemented across all groups that touch software.
Next up… My ideas on how to get developers to embrace a security process and the use of appropriate tools…
