What is the Security Development Lifecycle ?

The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost

Select a phase to view security requirements

  • 1. TRAINING
  • 2. REQUIREMENTS
  • 3. DESIGN
  • 4. IMPLEMENTATION
  • 5. VERIFICATION
  • 6. RELEASE
  • 7. RESPONSE

Training Phase

  • SDL Practice #1: Core Security TrainingThis practice is a prerequisite for implementing the SDL. Foundational concepts for building better software include secure design, threat modeling, secure coding, security testing, and best practices surrounding privacy.
  • Learn More >>

Requirements Phase

Design Phase

  • SDL Practice #5: Establish Design RequirementsConsidering security and privacy concerns early helps minimize the risk of schedule disruptions and reduce a project's expense.
  • SDL Practice #6: Attack Surface Analysis/ReductionReducing the opportunities for attackers to exploit a potential weak spot or vulnerability requires thoroughly analyzing overall attack surface and includes disabling or restricting access to system services, applying the principle of least privilege, and employing layered defenses wherever possible.
  • SDL Practice #7: Use Threat ModelingApplying a structured approach to threat scenarios during design helps a team more effectively and less expensively identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.
  • Learn More >>

Implementation Phase

  • SDL Practice #8: Use Approved ToolsPublishing a list of approved tools and associated security checks (such as compiler/linker options and warnings) helps automate and enforce security practices easily at a low cost. Keeping the list regularly updated means the latest tool versions are used and allows inclusion of new security analysis functionality and protections.
  • SDL Practice #9: Deprecate Unsafe FunctionsAnalyzing all project functions and APIs and banning those determined to be unsafe helps reduce potential security bugs with very little engineering cost. Specific actions include using header files, newer compilers, or code scanning tools to check code for functions on the banned list, and then replacing them with safer alternatives.
  • SDL Practice #10: Perform Static AnalysisAnalyzing the source code prior to compile provides a scalable method of security code review and helps ensure that secure coding policies are being followed.
  • Learn More >>

Verification Phase

  • SDL Practice #11: Perform Dynamic AnalysisPerforming run-time verification checks software functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.
  • SDL Practice #12: Fuzz TestingInducing program failure by deliberately introducing malformed or random data to an application helps reveal potential security issues prior to release while requiring modest resource investment.
  • SDL Practice #13: Attack Surface ReviewReviewing attack surface measurement upon code completion helps ensure that any design or implementation changes to an application or system have been taken into account, and that any new attack vectors created as a result of the changes have been reviewed and mitigated including threat models.
  • Learn More >>

Release Phase

  • SDL Practice #14: Create an Incident Response PlanPreparing an Incident Response Plan is crucial for helping to address new threats that can emerge over time. It includes identifying appropriate security emergency contacts and establishing security servicing plans for code inherited from other groups within the organization and for licensed third-party code.
  • SDL Practice #15: Conduct Final Security ReviewDeliberately reviewing all security activities that were performed helps ensure software release readiness. The Final Security Review (FSR) usually includes examining threat models, tools outputs, and performance against the quality gates and bug bars defined during the Requirements Phase.
  • SDL Practice #16: Certify Release and ArchiveCertifying software prior to a release helps ensure security and privacy requirements were met. Archiving all pertinent data is essential for performing post-release servicing tasks and helps lower the long-term costs associated with sustained software engineering.
  • Learn More >>

Response Phase

Operational Security Assurance

Learn about Microsoft's Operational Security Assurance Program for Online Services
Get started>>

Tools


View All>>

SDL Pro Network

Microsoft Services and The SDL Pro Network offer training, consulting, and tools services designed to help you adopt the SDL process and make security and privacy an integral part of your software development.
Learn More>>

Assess your security

Discover ways to improve your security practices
Get started>>