Microsoft has put its first-hand knowledge of dealing with buggy software to very good use by releasing the Trustworthy Computing Security Development Lifecycle (SDL) to the general public. The document is based on the same process used internally at Microsoft.

The Microsoft SDL documents a process for developing secure software that can withstand attacks. It works in conjunction with the usual software development cycle, so security is a consideration throughout the development process.


If you adhere to the following principles in the Microsoft SDL, you should be on your way to reducing and mitigating security holes.

  • Mandatory education: This involves the education on the many facets of building secure applications. In addition, you must continue to stay abreast of industry developments regarding security. The net effect is fewer security bugs up front since the code is developed with security in mind.
  • Design decisions based on threat models: The various ways an application may be attacked are considered during application design, thus thwarting such threats. The net effect is fewer security design bugs up front.
  • Do not use known insecure APIs: Only secure APIs are used in the building of an application, thus avoiding introducing bugs via the APIs. The net effect is fewer security bugs up front.
  • Static analysis tools: The use of static analysis code scanning tools allows you to discover issues that may be missed during design and development. The net effect is fewer security bugs in the code.
  • Avoid known weak crypto primitives and key lengths: You should only use robust crypto elements to avoid possible security breaches once an application is deployed.
  • Tool requirements: The Microsoft SDL includes an appendix that defines requirements for tools used in the development of applications. This includes compiler and linker requirements and provides extra defenses, in case you miss a bug.
  • Employ fuzz testing: Fuzz testing is a technique that provides random data to program inputs. If the program fails, the defects are noted. This allows you to discover bugs that may be introduced during development before a product ships.
  • Code review: Inter- and intra-team code review is used to ensure solid code is created that addresses all security issues.
  • Metrics: Metrics are used by every product team to measure security flaws. These measurements are used to manage the process.

The application of these principles is performed in the many phases that comprise the Microsoft SDL.


The Microsoft SDL is divided into phases that may be mapped onto the software development lifecycle. The Microsoft SDL phases include the following:

  • Requirements: Security considerations are a key component of the initial design of an application. Developer education ensures the necessary knowledge in this phase. Microsoft has a central security team, with members of this team assigned to projects to advise on security issues.
  • Design: The security architecture is created in this phase. Also, possible attacks and threats are documented to ensure they are considered during development.
  • Implementation: The application is coded and tested in this phase, while security flaws are discovered and removed.
  • Verification: The software is delivered to users as a beta version. Usage during this phase may yield more security flaws, which will be addressed before final shipment.
  • Release: The software is released to the user community. Before release, a final security review is performed to ensure it is ready for release.
  • Support and Servicing: After it is released, security vulnerabilities may still arise. Any bugs must be addressed and recognized in timely manner.

These phases offer a blueprint for developing secure applications, but you may choose to adapt one or all phases of the Microsoft SDL to fit your environment.


A key point with the Microsoft SDL is that it is a guide. That is, it spells out how security can be an integral aspect of software development, but it is language and platform agnostic, so you can take it and apply it to any software development environment and team. However, the appendices in the Microsoft SDL document do provide information on tools that may be used, and these tools focus on the Windows platform.

A proactive approach

The use of the Microsoft SDL during application development may seem like a no-brainer, but developers often avoid such considerations when they’re concentrating on meeting project requirements.

With the release of the Microsoft SDL, Microsoft provides a process that coincides with the software development life cycle. This makes it easy to apply to existing processes to deliver secure applications.

Download the Microsoft SDL document and make it a part of your development process today. For more in-depth information, read The Software Development Lifecycle by Michael Howard and Steve Lipner. I also recommend taking a look at the MSDN Security Development Lifecycle blog.

Do you plan to use the Microsoft SDL?

Is security a major component in your approach to software development? Will you utilize the Microsoft SDL? Share your thoughts with the Web Development community.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.


Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!