Lessons learned through 15 years of SDL at work

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.