SDL Practice #3: Create Quality Gates/Bug BarsDefining minimum acceptable levels of security and privacy
quality at the start helps a team understand risks associated with
security issues, identify and fix security bugs during development,
and apply the standards throughout the entire project.

SDL Practice #4: Perform Security and Privacy Risk AssessmentsExamining software design based on costs and
regulatory requirements helps a team identify which portions
of a project will require threat modeling and security design
reviews before release and determine the Privacy Impact Rating
of a feature, product, or service.

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.

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 #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.

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 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.