Creating a secure development culture

One of the toughest technical challenges in software security isn’t even technical.

It’s cultural.

Developers are responsible for making the code secure but, in many cases, have not lived up to their responsibility. I believe creating effective software security programs has a great deal to do with cultures and priorities. It’s easy – well at least sort of easy – for a security team to decide that the organization needs to “do something” about the security of the software it builds and start to roll out a secure development process. There are lots of resources that help an organization create such a process but most are focused on the process and technical security aspects of the program. Certainly valuable, but not the whole picture.

The challenge is that the software doesn’t come from the security team but from the developers. This is where culture becomes so important. It is through culture that we can get developers onboard with the secure development process.

Developers come in all flavors and work on a wide variety of products and services. Some work for software vendors and others for organizations that may not even think of themselves as being in the software business. We’ve all seen news stories about hacks, installed patches, or been affected by incidents that make it clear that real software security problems can affect the products of all kinds of developers.

And it’s the developers that make the products secure.

A software security program must mandate actions that the developers will take to eliminate or mitigate vulnerabilities while they’re creating code. The process can’t just test after-the-fact; and dump a batch of vulnerabilities on the developers after they think they’re done because the response will be “too late – we need to ship.” And besides, after-the-fact testing isn’t especially effective. If the developers and the tools they use find and fix security problems as they go, then when the code is done it’s likely to be secure code. Of course, this assumes that the developers are trained to know what to do with the tool output and that the tools work right.

So let’s talk about how we change the culture and get developers on-board with secure development.

How do we ensure that the developers and their managers, who are primarily tasked to ship on schedule, buy into putting time and effort into creating secure code? The answer to that question varies from organization, but here are some approaches I’ve seen work:

Response to your own flaming disaster

Many organizations have created their software security programs after suffering a public and embarrassing incident that resulted from a failure to do secure development. That’s a lot of what happened to us when I was at Microsoft, and it had a powerful effect. All the developers and development executives were aware of the bad publicity and customer complaints, and they all thought “we can do better than this.”

Response to someone else’s disaster

Almost as effective as suffering your own software security crisis is watching another developer – a partner, peer, or competitor – go through one. I’ve seen companies look at the press and then look inward and ask if that could happen to them. If it could, that can be a motivation to create a software security program proactively.

An executive call to action

If a corporate leader decides that the risk of a software security problem is a threat to corporate reputation or success, or that building secure software is just the right thing to do, and issues a serious call for a software security program, that’s likely to get the developers’ attention and change the culture – especially if they report to him/her, and if he/she has a positive reputation with the developers. The Bill Gates email that launched Trustworthy Computing at Microsoft is an example of an executive call to action that profoundly changed the culture of the entire organization.

A technical leadership call to action

A technical leader’s message that “we have to do better” can get developers’ attention, especially if the leader is widely respected within the organization. When Bill committed Microsoft to Trustworthy Computing, he was the company’s technical leader at least as much as the top manager.

These approaches are often combined but the key consideration is to get the message to the developers and managers so that they’ll embrace the intent as well as the details of the secure development process.

Fundamentally, what we’re seeking is a change in the development organization’s culture to embrace software security. Without that, rolling out a software security program will be difficult and maybe unsuccessful. With a change in culture, the organization is on the program’s side and while success isn’t certain, it’s very likely.