Microsoft® Security Development Lifecycle

Locations

United States Change All Microsoft Sites

Search


Was this information useful?
 |
yes
 |
no

SDL Process: Requirements

Seven phases of the traditional software development lifecycle define Security Development Lifecycle (SDL) process. Click on a phase to view the security practice details preformed during each phase or download the whitepaper Simplified Implementation of the SDL.

Simplified Implementation of the SDL

View video:

Implementation
of the SDL
SDL Practice #2:

Security and Privacy Requirements

SDL Practice #3:

Create Quality Gates/Bug Bars

SDL Practice #4:

Security and Privacy Risk Assessment

Security and privacy analysis includes assigning security experts, defining minimum security and privacy criteria for the application, and deploying a security vulnerability/work item tracking system allowing for creation, triage, assignment, tracking, remediation, and reporting of software vulnerabilities.

A bug bar is a quality gate that applies to the entire software development project and defines the severity thresholds of security vulnerabilities—for example, no known vulnerabilities in the application with a “critical” or “important” rating at time of release. The bug bar, once set, should never be relaxed.

Security risk assessments (SRAs) and privacy risk assessments (PRAs) identify functional aspects of the software that require closer review.

Why should I follow this practice?

Defining security and privacy requirements early permits the integration of security and privacy into the development process and minimizes any disruption to plans and schedules.

Quality gates and bug bars are used to establish minimum acceptable levels of security and privacy quality. Defining these criteria at the start of a project improves the understanding of risks associated with security issues and enables teams to identify and fix security bugs during development.

Risk assessments help you understand costs and requirements involved in handling data governed by security and privacy considerations and allow you to examine software design based on regulatory requirements.

When should I employ this practice?

Traditional software development: Requirements Phase
Agile development: One Time

Traditional software development: Requirements Phase
Agile development: One Time

Traditional software development: Requirements Phase
Agile development: One Time

Resources specific to this practice
Tools specific to this practice