• United States




Lessons learned through 15 years of SDL at work

Sep 20, 20195 mins
Application SecurityDeveloperMicrosoft

In short? Security Development Lifecycle is all about the developers...

Do a quick search on secure development and you’ll find pages and pages of advice and best practices. You could relatively quickly create a long checklist of best practices and how-tos covering everything from how to create a threat model to the dos and don’ts of avoiding cross site-scripting mistakes. Newer articles and papers might focus in on applying secure development to mobile applications or making it work in a DevOps environment as the way we have built code has changed over the years.

And yet, despite all we know about creating secure code, many organizations still struggle with making secure development work in practice.

In fact, it’s been a little more than 15 years since Microsoft mandated its Security Development Lifecycle (SDL) in summer 2004. This was two years after the now-famous Trustworthy Computing memo went out and Microsoft began its unprecedented investment of resources into secure software development. But 2004 is a milestone that retains special significance for me and one that holds a lesson often lost in the pages and pages of how-tos and best practices – and has been the key to the SDL’s longevity in a rapidly evolving technology climate – it’s all about the developers. We discovered quickly that focusing on the practices without consideration for how software development is actually done or what developers need to be successful was an effort destined to fail.

Rather, we had to start with an understanding of the development process and then define how security would work within that framework. SDL was created to support the developer in the creation of more secure software resulting in more secure products and more satisfied end-users.

We found that this approach worked. After 15 years, and despite the massive changes in both how technology is used and how software is created, SDL still provides the foundation for the software security programs at many of the world’s largest and most influential software organizations and there are no signs of its use or adoption slowing down.  Of course, there have been modifications and changes to the original parameters set years ago at Microsoft.  But this is the beauty of SDL: it was designed to evolve.

Nothing remains the same – 15 years of evolution and change

The three most significant changes to SDL over the last decade and half can be summarized as follows: 

  • Diversity
  • Speed
  • Supply chain

Originally, SDL as we created it at Microsoft aimed at development in C, C++, and C#.  Today, organizations may use 10-15 languages resulting in more work and complexity for SDL teams (but not for developers – they are using the language they’re using, and they just need to write secure code in that language).  So, diversity of languages has evolved over time.

Speed is another area of significant change for SDL. SDL adapted well to Agile or DevOps but not without some initial pushback from developers. It was this feedback that helped improve the functionality of SDL by focusing on integration of secure development tools; automating verification wherever possible; and, determining that some requirements could be met post-release.  Getting a secure product out the door in a timely way remains one of the main benefits SDL brings to the development process. 

Supply chain is the third area experiencing significant change.  It is probably where the most changes have happened as the use of “third party code” is the rule today – especially open source software. The use of “third party code” creates another layer to the SDL process.  When using “third party code” someone in the organization had better be responsible, have an inventory, have a standard for acceptance and use, and have a system for detecting security problems in code created outside the organization. And most importantly, be prepared to respond when needed.

The security is done when the product is done: Lessons learned from 15 years of SDL

Below are five lessons learned from implementing and managing SDL environments since its inception:

1. Developers want to do the right thing

They have pride in their company, products and work and know that security matters. Implemented correctly, and with their needs as its focus, SDL helps them achieve their goals.

2. The security must be built into the software development process, not merely tested after the product is complete

The SDL culture of “the security is done when the product is done” is the only way to ship secure code and helps avoid conflicts between business goals and security.

3. SDL is a product group activity advised by the SDL team

Product teams must buy into the credibility of the SDL team and importance of security for the benefits of SDL to take root and flourish in an organization. Culture matters.

4. Continuous improvement is central to SDL’s success

New classes of vulnerabilities are nature’s way of telling you to update your tools and/or processes.

5. Training is good, but tools are better because people forget – code doesn’t

The SDL was created to work in tandem with security tools. Focusing on the developers doesn’t mean keeping things manual – rather organizations should constantly consider how technology and automation can support their developers in achieving their security goals.

For those who have been working on software security for a while now – none of this is earth shattering. We know that at the end of the day, it is all about empowering the developers. But perhaps it is because many of us are engineers or technologists at heart, we sometimes lose focus and get caught up in the practices and tools and start to treat SDL as a checklist rather than a process. So every once in a while, it is important to take a step back and remember where we came from and what we’ve learned along the way, and make sure we always remember that it is all about the developers.

Check out SAFCode’s recent Security Champions paper to learn more about the “people” side of software security.


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.