Implementing a Secure Development Lifecycle: Lessons from the Trenches

New SecurityWeek Series from Vincent Liu – “Lessons from the Trenches on Implementing a Secure Development Lifecycle”

In the last 18 months, I’ve observed that companies are paying much more attention to the secure development lifecycle (SDL). In particular, I’ve found that more and more organizations are actively working to improve the security in their development programs by integrating best practices throughout the lifecycle – not just performing scanning before deployment.

There are many reasons for this shift. The primary reason for this increased attention is to meet rising regulatory and customer requirements that demand due diligence in the development of software. As the industry has matured, so have the standards—gone are the days when the performance of a vulnerability scan signifies secure software. In certain cases, I’ve seen companies’ focus increase as a result of a significant data breach. In many of these instances, the root cause has been traced back to some weakness in the development and deployment of applications within their environment. Naturally, the implementation of an SDL is one of the main controls put into place after a breach that is rooted in application vulnerability. In more mature organizations, I have seen evidence of a decrease in security defects that has resulted in a net savings for the organization. Overall, the message has been clear – the adoption of SDL best practices within the development process is quickly becoming the norm.

As a result of the need for stronger and more secure development programs, the industry has been busy producing several helpful resources. Perhaps the most well-established resource comes from Microsoft, who has been sharing information on their SDL program for years. They have resources that can help define what a mature organization does, and tools that supplement their style of SDL. Alternative maturity models have also been published and include the Building Security In Maturity Model 2 (BSIMM2) and OWASP’s most excellent Open Software Assurance Maturity Model (OpenSAMM). There are also a few books on the subject from Microsoft and Addison Wesley. Although, the Microsoft book is out of date, and the Addision Wesley book should be read more for its theory. Still, with all the resources available, there is a lack of information about the practical *how to* behind setting up a Secure Software Development Lifecycle. In many ways, the materials currently available project a vision of how things should be, but fail to tell you how to get there.

In this series of articles, of which this is the first, my goal is to shed some light on how to implement a real-world SDL. I’ve broken down the series into ten distinct articles, each covering one lesson that I’ve learned from my experience having established a number of successful secure development programs in the Fortune 500. These are the lessons learned from the trenches:

• The importance of executive support

• There is no silver bullet

• The boring work must be done

• Measure what you want to manage

• Even the best laid plans…

• Don’t over train

• One step forward, two steps back

• Get a second opinion

• Penny wise, pound foolish

• There are no absolutes

As the saying goes, “Blessed is he who learns from his mistakes. Thrice blessed is he who learns from those of others.” Stay tuned for the next article and our first lesson, “The importance of executive support”.