Do a quick search on secure development and you\u2019ll 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\u2019ts 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\u2019s 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 \u2013 and has been the key to the SDL\u2019s longevity in a rapidly evolving technology climate \u2013 it\u2019s 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\u2019s largest and most influential software organizations and there are no signs of its use or adoption slowing down.\u00a0 Of course, there have been modifications and changes to the original parameters set years ago at Microsoft.\u00a0 But this is the beauty of SDL: it was designed to evolve.Nothing remains the same \u2013 15 years of evolution and changeThe three most significant changes to SDL over the last decade and half can be summarized as follows:\u00a0DiversitySpeedSupply chainOriginally, SDL as we created it at Microsoft aimed at development in C, C++, and C#.\u00a0 Today, organizations may use 10-15 languages resulting in more work and complexity for SDL teams (but not for developers \u2013 they are using the language they\u2019re using, and they just need to write secure code in that language).\u00a0 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.\u00a0 Getting a secure product out the door in a timely way remains one of the main benefits SDL brings to the development process.\u00a0Supply chain is the third area experiencing significant change.\u00a0 It is probably where the most changes have happened as the use of \u201cthird party code\u201d is the rule today \u2013 especially open source software. The use of \u201cthird party code\u201d creates another layer to the SDL process.\u00a0 When using \u201cthird party code\u201d 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 SDLBelow are five lessons learned from implementing and managing SDL environments since its inception:1. Developers want to do the right thingThey 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 completeThe SDL culture of \u201cthe security is done when the product is done\u201d 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 teamProduct 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\u2019s successNew classes of vulnerabilities are nature\u2019s way of telling you to update your tools and\/or processes.5. Training is good, but tools are better because people forget \u2013 code doesn\u2019tThe SDL was created to work in tandem with security tools. Focusing on the developers doesn\u2019t mean keeping things manual \u2013 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 \u2013 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\u2019ve learned along the way, and make sure we always remember that it is all about the developers.Check out SAFCode\u2019s recent Security Champions paper to learn more about the "people" side of software security.