• United States




Creating a secure development culture

Oct 16, 20175 mins
Application SecurityEnterprise Applications

Focusing on culture might be the most important thing an organization can do when developing secure software.

Define your organization's culture
Credit: Thinkstock

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.


Steven B. Lipner is the executive director of SAFECode, a non-profit organization dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. As executive director, Lipner serves as an ex officio member of the SAFECode board. In addition to providing strategic and technical leadership, his responsibilities include representing SAFECode to IT user and development organizations, to policymakers, and to the media.

Lipner is a pioneer in cybersecurity with over forty years’ experience as a general manager, engineering manager, and researcher. He retired in 2015 from Microsoft where he was the creator and long-time leader of Microsoft’s Security Development Lifecycle (SDL) team. While at Microsoft, Lipner also created initiatives to encourage industry adoption of secure development practices and the SDL, and served as a member and chair of the SAFECode board.

Lipner joined Microsoft in 1999 and was initially responsible for the Microsoft Security Response Center. In the aftermath of the major computer “worm” incidents of 2001, Lipner and his team formulated the strategy of “security pushes” that enabled Microsoft to make rapid improvements in the security of its software and to change the corporate culture to emphasize product security. The SDL is the product of these improvements.

At Mitretek Systems, Lipner served as the executive agent for the U.S. Government’s Infosec Research Council (IRC). At Trusted Information Systems (TIS), he led the Gauntlet Firewall business unit whose success was the basis for TIS’ 1996 Initial Public Offering. During his eleven years at Digital Equipment Corporation, Lipner led and made technical contributions to the development of numerous security products and to the operational security of Digital’s networks.

Throughout his career, Lipner has been a contributor to government and industry efforts to improve cybersecurity. Lipner was one of the founding members of the U.S. Government Information Security and Privacy Advisory Board and served a total of over ten years in two terms on the board. He has been a member of nine National Research Council committees and is named as coinventor on twelve U.S. patents. He was elected in 2010 to the Information Systems Security Association Hall of Fame, in 2015 to the National Cybersecurity Hall of Fame and in 2017 to the National Academy of Engineering.

The opinions expressed in this blog are those of Steve Lipner and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.