Microsoft Security Development Lifecycle (SDL)
Optimization Model
Self-Assessment Guide
Published: November 2008
Abstract
The Microsoft® Security Development Lifecycle (SDL) Optimization Model is designed to facilitate gradual, consistent, and
cost-effective implementation of the SDL by development organizations outside of Microsoft. The model helps those
responsible for integrating security and privacy in their organization’s software development lifecycle to assess their
current state and to gradually move their organization towards the adoption of the proven Microsoft program for
producing more secure software. The SDL Optimization Model enables development managers and IT policy makers to
assess the state of the security currently in development. They can then create a vision and road map for reducing
customer risk by creating more secure and reliable software in a cost-effective, consistent, and gradual manner. Although
achieving security assurance requires long-term commitment, this guide outlines a plan for attaining measureable
process improvements, quickly, with realistic budgets and resources.
This Self-Assessment Guide will help those responsible for implementing the SDL to assess the current level of maturity in
their organizations and to identify the necessary activities and capabilities needed to move to the next, higher level of
maturity. The guide was designed to be used in conjunction with the detailed Implementer Resource Guides for advancing
in the maturity levels of the SDL optimization model.
For the latest information, more detailed descriptions, and the business benefits of the Microsoft Security Development
Lifecycle, go to http://www.microsoft.com/SDL.
Microsoft makes no warranties, express, implied, or statutory as to the information in this document or information
referenced or linked to by this document.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE
INFORMATION IN THIS DOCUMENT OR INFORMATION REFERENCED OR LINKED TO BY THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give
you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved. This work is licensed under the Creative Commons Attribution-Non-Commercial License.
To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons, 543 Howard
Street, 5th Floor, San Francisco, California, 94105, USA.
Microsoft, Visual C++, Visual Studio, SQL Server, and Win32 are either trademarks or registered trademarks of Microsoft Corporation in the
United States and/or other countries.
All other trademarks are property of their respective owners.
Contents
Resource Guide Overview........................................................................................................................................................ 1
Audience .............................................................................................................................................................................. 1
Maturity Levels Overview .................................................................................................................................................... 1
Self Assessment ....................................................................................................................................................................... 3
Capability Area: Training, Policy, and Organizational Capabilities ....................................................................................... 3
Requirements for the Standardized maturity level ......................................................................................................... 3
Requirements for the Advanced maturity level............................................................................................................... 4
Requirements for the Dynamic maturity level ................................................................................................................ 5
Capability Area: Requirements and Design ......................................................................................................................... 7
Requirements for the Standardized maturity level ......................................................................................................... 7
Requirements for the Advanced maturity level............................................................................................................... 8
Requirements for the Dynamic maturity level .............................................................................................................. 10
Capability Area: Implementation ....................................................................................................................................... 10
Requirements for the Standardized maturity level ....................................................................................................... 10
Requirements for the Advanced maturity level............................................................................................................. 12
Requirements for the Dynamic maturity level .............................................................................................................. 12
Capability Area: Verification .............................................................................................................................................. 13
Requirements for the Standardized maturity level ....................................................................................................... 13
Requirements for the Advanced maturity level............................................................................................................. 14
Requirements for the Dynamic maturity level .............................................................................................................. 15
Capability Area: Release and Response ............................................................................................................................. 16
Requirements for the Standardized maturity level ....................................................................................................... 16
Requirements for the Advanced maturity level............................................................................................................. 17
Requirements for the Dynamic maturity level .............................................................................................................. 18
Resource Guide Overview
Audience
This document is designed for development managers and IT decision makers who are responsible for planning,
deploying, and governing security and privacy measures in software development and who want to implement
the practices and concepts of the Microsoft Security Development Lifecycle (SDL).
Maturity Levels Overview
This guide describes a checklist of requirements to meet each maturity level for the five capability areas in the
SDL Optimization Model. The following table offers a general overview of the various capability areas and
maturity levels. To make the table more readable, the activities specified for each maturity level should be read
to include the activities from the lower level.
1
2
Self Assessment
The following section presents questions for each of the core capabilities to help you assess your maturity level in
a given capability area. Many of the requirements in the following section have minimum attributes associated
with them. If your organization meets every requirement and attribute outlined in a certain maturity level, you
have already achieved that level and can proceed to the next maturity level in the SDL Optimization Model. You
can print this section as a scorecard for determining which requirements and attributes you need to implement in
your organization.
Capability Area: Training, Policy, and Organizational Capabilities
Requirements for the Standardized maturity level
Capability: Training
The Standardized level of optimization requires that the security practices, skills, and sophistication of the
developer and tester roles in the software engineering process be assessed to determine the need and the specific
content for security training materials. A “Basics of Secure Design, Development, and Test” or equivalent
curriculum should be developed internally, or a training partner can be engaged from the SDL Pro Network, and
the course should be completed by architects, developers, and quality assurance testers for the SDL pilot projects.
Requirement: Assess training needs for developer and tester roles.
Yes
No
Yes
No
Training needs have been determined and content and an
appropriate curriculum for developers and testers in the
organization has been created or acquired.
Requirement: Successful completion of “Basics of Secure Design,
Development, and Test” or equivalent course by development and
test staff
Architects, developers, and testers for Basic to Standardized pilot
projects have completed introductory training.
For more information, see the Training capability section in the SDL Optimization Model Implementer Resource
Guide: Basic to Standardized.
Capability: Bug Tracking
The Standardized level of optimization requires that bug-tracking systems be updated to include fields to classify
vulnerabilities by their security cause (for example, buffer overflow), effect (for example, elevation of privilege),
and method of discovery (for example, code review).
3
Requirement: Ability to record security cause, effect, and method
of discovery for vulnerabilities
Yes
No
Bug databases and tracking software can record and classify
vulnerabilities by security cause, effect, and method of discovery.
For more information, see the Bug Tracking capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Requirements for the Advanced maturity level
Capability: Training
At the Standardized level, the training requirement encompasses only the completion of a “Basics of Secure
Design, Development, and Test” or equivalent course for developers and testers involved in pilot projects.
Broadening and extending staff training is a key component of reaching the Advanced maturity level.
Requirement: Expanded security curriculum
Yes
No
Yes
No
The organization has acquired or developed a training curriculum
for the following subject areas:
• Basics of Secure Design, Development, and Test or equivalent
• Privacy in Development
• Introduction to the Microsoft Security Development Lifecycle
• Introduction to Threat Modeling
Requirement: Successful completion of relevant course material by
80 percent of all development staff in business areas with
significant security risk
Personnel have completed both the “Introduction to the Microsoft
SDL” and “Introduction to Threat Modeling” classes, and the “Basics”
or “Privacy in Development” course as appropriate to their role.
For more information, see the Training capability section in the SDL Optimization Model Implementer Resource
Guide: Standardized to Advanced.
Capability: SDL Policy
At the Advanced level, policy becomes a larger part of governing the SDL process. Policy standardizes the types of
projects that fall under the SDL mandate and the activities and processes that must happen at each phase of the
development lifecycle for a project to be considered in compliance. It also sets the quality gates that need to be
met before release.
4
Requirement: Privacy risks enumerated and executive
commitment formalized
Yes
No
The SDL policy formally defines which projects qualify for SDL mandates
and what the requirements are for compliance. A process exists to track
SDL compliance and issue the necessary exceptions for high-risk projects.
For more information, see the SDL Policy capability section in the SDL Optimization Model Implementer Resource
Guide: Standardized to Advanced.
Capability: Central Ownership of Security and Privacy Advisement
At the Standardized level, advisement by the involved expert is on a per-project basis. To reach the Advanced level,
this should become an official organizational capability that is owned by a centralized security team.
Requirement: Central security team advises all projects and
product groups on security and privacy.
Yes
No
Security and privacy advisement is an official organizational capability
that is owned by a central security team.
For more information, see the Security and Privacy Advisement capability section in the SDL Optimization Model
Implementer Resource Guide: Standardized to Advanced.
Requirements for the Dynamic maturity level
Capability: SDL Policy
At the Dynamic level, SDL policy places every project with meaningful security or privacy risk under the mandate of
the SDL. At this level, the policy provides specific requirements based on different development criteria, such as
product type (for example, client, server, or online services), code type (for example, native or managed) and
platform (for example, target operating system [OS] or device). In addition, activities and standards in the policy
are periodically refreshed, incorporating lessons learned from root-cause analysis of security incidents, adaptations
to the changing threat environment, and improvements in tools and techniques.
Requirement: Periodic refresh of policy
Yes
No
The SDL policy covers all projects that have a meaningful security and
privacy risk and is periodically updated to cover new threats and practices.
For more information, see the SDL Policy capability section in the SDL Optimization Model Implementer Resource
Guide: Advanced to Dynamic.
5
Capability: Training
At the Advanced level, organizations are offering specialized training to address the security needs and emerging
threats to particular modules and product groups. This training may be developed in-house or sourced from
reputable conferences or third parties, such as Microsoft SDL Pro Network members.
Requirement: Custom security training
Yes
No
Engineers and testers have access to advanced training topics
targeted to the specific security and privacy requirements of
individual product groups.
For more information, see the Training capability section in the SDL Optimization Model Implementer Resource
Guide: Advanced to Dynamic.
Capability: Security “Champions” in Product Groups
At the Advanced level, most SDL activities are heavily supported by the central security team. As organizations
move to the Dynamic level, security expertise and responsibility will become more distributed to “champions”
embedded in each product group who have a deeper level of experience and can specialize and contribute security
expertise on a continual basis across the lifecycle. At this level, the central security team will focus more on
ensuring compliance with the policy prior to release, assisting the product teams as necessary and developing
technologies to improve the effectiveness of the SDL within the organization.
Requirement: Security “champions” in product groups
Yes
No
Ownership of the SDL activities and responsibilities is partially distributed
to embedded security “champions” in major product groups.
For more information, see the Security “Champions” in Product Groups capability section in the SDL Optimization
Model Implementer Resource Guide: Advanced to Dynamic.
Capability: SDL Is Adapted to the Development Methodology
By the time the Advanced level is reached, the SDL is becoming a regular part of developing software at an
organization. At the Dynamic level, the SDL activities are fully integrated into the ordinary process and governance
of the software development methodology, whether it is waterfall, Agile, or another style. For product teams, the
SDL is a normal part of the way they create software, not an additional set of requirements.
Requirement: SDL is adapted to the development methodology.
Yes
No
The SDL activities are an integral and mandatory part of how the
organization creates software, and practices are integrated with
the development methodology (such as waterfall or Agile).
For more information, see the Development Methodology Integration capability section in the SDL Optimization
Model Implementer Resource Guide: Advanced to Dynamic.
6
Capability Area: Requirements and Design
Requirements for the Standardized maturity level
Capability: Risk Assessment
The Standardized level of optimization requires that new projects in business areas with meaningful security risk
(as defined by the organization’s SDL policy) fill out a risk-assessment questionnaire. This gives the security
management team visibility into the total organizational need for a security review and helps to prioritize the most
important projects so resources can be properly allocated.
Requirement: Questionnaires used to identify and prioritize
projects for security review and assistance
Yes
No
A risk questionnaire exists and is a mandatory part of the project
initiation or requirements lifecycle phase and the SDL pilot
projects have been identified based upon this questionnaire.
For more information, see the Risk Assessment capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Capability: Quality Gates
At project inception, it should be determined whether a feature or product qualifies for the SDL. Typically, features
rated as low risk, or certain classes of product (such as software development kits [SDKs]), may not qualify for
these practices. At the Standardized level, participation in the SDL is opportunistic, rather than mandated, and it
applies only to the pilot projects selected for their risk ranking or ability to absorb and perform the newly required
practices. It is important at an early stage of the software development lifecycle to identify which projects qualify
and what their final security exit criteria before release will be. This allows accurate estimates of security practices
to be built into the project timeline.
Requirement: The SDL eligibility and quality gates are determined
for qualifying projects.
Yes
No
A definition of security and privacy bug classifications exist as
release criteria for the SDL pilot projects.
For more information, please see the Quality Gates capability section in SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Capability: Threat Modeling
At the Standardized level, it is recommended that threat models be created for system components that have
large attack surfaces, are relied upon by other components to enforce security requirements, or have complex
interactions with untrusted systems. A security expert (internal or external) can provide direct assistance and
moderation in the creation of a threat model with the product team.
7
Requirement: Threat models created as needed for high-risk
projects with expert assistance and moderation
Yes
No
A security expert (internal or external) identifies projects that
would benefit from threat modeling and provides direct assistance
to product teams in creating threat models.
For more information, see the Threat Modeling capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Requirements for the Advanced maturity level
Capability: Risk Assessment
The Standardized level of optimization requires that new projects in business areas with meaningful security risk
fill out a risk-assessment questionnaire to give the security management team visibility into the total
organizational need for security review and assistance and to help prioritize available resources to the most
important projects. To reach the Advanced level, all projects and supported products must be risk assessed, and
the ability to track and verify the risk assessment must exist.
Requirement: Questionnaires are used to identify and prioritize
projects for security review and assistance.
Yes
No
A risk questionnaire exists as a mandatory part of the project initiation
or requirements lifecycle phase. All new projects have responded and
legacy products have also been retroactively risk assessed. The central
security team is capable of tracking and verifying the risk assessments.
For more information, see the Risk Assessment capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Capability: Functional Security Requirements
The Advanced level of optimization requires that the organization-specific, standard solutions for meeting
functional security requirements and mitigating common attack classes be cataloged and that the security team
can provide guidance on the proper application of these solutions. Examples include common authorization
libraries and input/output filtering modules.
Requirement: Standardized security solutions are cataloged and
can be applied.
Yes
No
The security expert team has cataloged and can guide the development
team in applying approved, standard solutions for meeting functional
security requirements and mitigating common attack classes.
For more information, see the Functional Security Requirements capability section in the SDL Optimization Model
Implementer Resource Guide: Standardized to Advanced.
8
Capability: Design Requirements
The Advanced level of optimization requires that the security expert group be able to validate proper application
of standardized solutions and mitigations for new projects categorized as high risk.
Requirement: Ability to validate technical adherence to standard
security solutions for new, high-risk projects
Yes
No
The security expert team is capable of auditing and verifying the
application of standard and approved solutions for functional security
requirements and threat mitigation for new projects classified as high risk.
For more information, see the Design Requirements capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Capability: Quality Gates
At project inception, it should be determined whether a feature or product qualifies for the SDL. Typically, features
rated as low risk, or certain classes of product (such as SDKs), may not qualify for these practices. Once a project is
deemed subject to the SDL (by the SDL policy), it is important to identify the final security and privacy exit criteria
before release. This allows accurate estimates of security practices to be built into the project timeline. At the
Advanced level, all new projects evaluated as having high risk fall under the SDL mandates.
Requirement: SDL eligibility and quality gates are determined for
all new and high-risk projects.
Yes
No
Security and privacy criteria for release are defined and mandated
for all new projects evaluated as having meaningful security risk.
For more information, please see the Quality Gates capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Capability: Threat Modeling
At the Standardized level, Threat Modeling is opportunistic and expert led. At the Advanced level, the central
security team is capable of assisting with the creation of threat models for all new, high-risk features.
Requirement: Threat models are created for all new and high-risk
projects with the central security team.
The central security team assists product groups with threat
modeling for all new and high-risk projects.
The central security team can validate existing threat models for
correctness.
Threat models are used to enumerate attack surfaces, and the
central security team can recommend appropriate actions for attack
surface reduction.
9
Yes
No
For more information, see the Threat Modeling capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Requirements for the Dynamic maturity level
Capability: Threat Modeling
At the Dynamic level, product teams should be experienced with and capable of producing their own threat
models. These threat models are subject to review by the central security team but require much less centralized
effort and supervision to create. Threat modeling is an ordinary part of the development process.
Requirement: Threat models created for all new and high-risk
projects with the central security team
Yes
No
Product groups independently create threat models. The central
security team reviews but does not generally need to participate in
creating threat models.
For more information, see the Threat Modeling capability section in the SDL Optimization Model Implementer
Resource Guide: Advanced to Dynamic.
Capability Area: Implementation
Requirements for the Standardized maturity level
Capability: Secure Coding Policies
Strengthening compiler defenses can produce excellent defense-in-depth for many projects. The Standardized
level currently requires the following:






Use the latest compiler and linker because important defenses are added by the tools.
If using Visual C++®, use Visual Studio® 2005 SP1 or later.
Compile with appropriate compiler flags.
Compile clean at the highest possible warning level.
Compile with –GS to detect stack-based buffer overruns.
Link with appropriate linker flags: /NXCOMPAT to get NX defenses, /DynamicBase to get ASLR, and
/SafeSEH to get exception handler protections.
 For GCC, use at least GCC 4.1 with –fstack-protector or –fstack-protector-all.
Implementing the use of Banned.h or a subset to prevent use of dangerous APIs in C and C++ code is a low-cost
step for new code. Alternately, a simple, free code scanner, such as RATS, can be utilized as part of the
development code review process to manually identify dangerous API usage. For .NET code, use FxCop security
rules.
10
Requirement: Compiler defenses strengthened
Yes
No
Yes
No
The SDL pilot teams and high-risk projects in native code utilize
appropriate compiler defenses.
Requirement: Use of Banned.h or basic code scanning tools
Banned.h is used to exclude banned APIs from new code, or security
code scanners are used in conjunction with code review to identify
dangerous API usage.
For more information, see the Secure Coding Policies capability section in the SDL Optimization Model
Implementer Resource Guide: Basic to Standardized.
Capability: XSS and SQL Injection Defenses
Web applications selected as pilot projects must build in systematic defenses against cross-site scripting (XSS) and
SQL injection vulnerabilities.
Requirement: Evaluation of tools for core development platform
Yes
No
The security expert team is working with the SDL pilot teams to
evaluate XSS and SQL Injection Defenses for Web applications.
Specifically, this includes input validation, output encoding, and the
use of parameterized queries.
For more information, see the XSS and SQL Injection Defenses capability section in the SDL Optimization Model
Implementer Resource Guide: Basic to Standardized.
11
Requirements for the Advanced maturity level
Capability: Security Tools
At the Advanced level, the use of tools to improve software security at the implementation level moves beyond
compiler defenses and simple code scanners to more advanced tools. The central security team should be able to
recommend and to help apply the tools that are appropriate to the platforms and languages in use.
Requirement: Evaluate and recommend appropriate security tools.
Yes
No
Yes
No
The central security team is able to specify appropriate tools based
upon a project type (for example, managed versus native code, Web
versus Win32®), ascertain the quality of available tools (commercial
or open source), and make appropriate recommendations.
Requirement: Use of a static analysis tool on native code
The central security team is able to identify appropriate static analysis
tools for native code projects and triage the tool output to identify false
positives and false negatives. The security team can assist product teams
in understanding and prioritizing the output of such tools.
For more information, see the Security Tools capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Requirements for the Dynamic maturity level
Capability: Security Tools
At the Dynamic level, appropriate static-analysis tools are in widespread use on all code with meaningful security
or privacy risk. The organization also has the capability to develop or customize tools in-house to address specific
threats and needs that are not otherwise met by off-the-shelf software.
Requirement: Static analysis for all code
Yes
No
Yes
No
Appropriate static analysis tools are in widespread use on all code.
Requirement: In-house security tool customization
The organization is able to evaluate, develop, or customize security
tools for its unique needs when off-the-shelf software is not sufficient.
For more information, see the Security Tools capability section in the SDL Optimization Model Implementer
Resource Guide: Advanced to Dynamic.
12
Capability Area: Verification
Requirements for the Standardized maturity level
Capability: Dynamic Analysis and Application Scanning (Web Applications)
For Web applications, dynamic scanning tools and passive proxies can be highly effective at finding common
classes of security vulnerabilities. At the Standardized level, for organizations deploying Web applications, the
security expert team should be evaluating such tools against selected pilot projects.
Requirement: Pilot evaluation of dynamic scanning tools for Web
applications
Yes
No
The security expert team is working with the SDL pilot teams to evaluate
and incorporate dynamic scanning tools for Web applications.
For more information, see the Dynamic Analysis and Application Scanning section in the SDL Optimization Model
Implementer Resource Guide: Basic to Standardized.
Capability: Fuzzing
Complex, custom parsing of file formats done in C or C++ is a frequent and avoidable source of high-severity
security bugs. The Standardized level requires that fuzz testing be performed to attempt to identify such
vulnerabilities in native code parsers. A variety of free and commercial tools are available to perform fuzz testing.
Requirement: File fuzzing for native parsers
Yes
No
Custom file format parsers implemented in native C or C++ code
have been fuzzed for the SDL pilot projects.
For more information, see the Fuzzing capability section in the SDL Optimization Model Implementer Resource
Guide: Basic to Standardized.
Capability: Penetration Testing
Organizations at the Basic level are likely not to have a full grasp of the set of security issues present in their
products. An outside perspective can help clarify the current state of security maturity and the types of
vulnerabilities that other processes are not preventing. It is recommended that the pilot products with the greatest
risk exposure for the organization undergo penetration testing by outside experts.
Requirement: Penetration testing by third parties as appropriate
External experts are engaged to perform penetration testing on the
pilot projects with the greatest business risk.
13
Yes
No
For more information, see the Penetration Testing capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Requirements for the Advanced maturity level
Capability: Dynamic Analysis and Application Scanning (Web Applications)
For Web applications, dynamic scanning tools and passive proxies can be highly effective at finding common
classes of security vulnerabilities. At the Advanced level, the use of scanners must be comprehensive.
Requirement: Comprehensive dynamic scanning tools for Web
applications
Yes
No
Dynamic analysis tools are applied to all Web applications, and the
central security team can assist with triaging, tuning, and
understanding the output of such tools.
For more information, see the Dynamic Analysis and Application Scanning capability section in the SDL
Optimization Model Implementer Resource Guide: Standardized to Advanced.
Capability: Fuzzing
Complex, custom parsing of file formats done in C or C++ is a frequent and avoidable source of high-severity
security bugs. At the Advanced level, all complex native parsers that take untrusted input must be fuzzed,
especially network protocol endpoints.
Yes
Requirement: File fuzzing for native parsers
No
All parsers of untrusted data (network protocol, file format, or
others) implemented in native code meet fuzzing requirements.
For more information, see the Fuzzing capability section in the SDL Optimization Model Implementer Resource
Guide: Standardized to Advanced.
Capability: Threat Model Validated
At the Advanced level, threat models created at the Design stage are re-examined at the Verification stage to
ensure that relevant test cases are in place and that appropriate negative testing has been performed to validate
threat mitigation strategies.
Requirement: Threat model validated
Yes
Threat models are used in the creation of test plans and test cases
to validate threat mitigation strategies.
14
No
For more information, see the Threat Model Validated capability section in the SDL Optimization Model
Implementer Resource Guide: Standardized to Advanced.
Requirements for the Dynamic maturity level
Capability: Custom Tools to Detect Vulnerabilities
At the Dynamic level, the verification and test team, along with development engineers, are creating customized
tools to find security vulnerabilities, such as integrating common vulnerability classes into automated regression
suites or deploying tools to comprehensively scan for issues identified by root-cause analysis of past incidents.
Requirement: Custom tools to detect vulnerability
Yes
No
The verification and test team is capable of creating custom tools to
detect security vulnerabilities where off-the-shelf software tools are
insufficient.
For more information, see the Custom Security Test Tools capability section in the SDL Optimization Model
Implementer Resource Guide: Advanced to Dynamic.
Capability: Penetration Testing
At the Dynamic level, experts are engaged to perform design reviews and targeted code reviews, in addition to
standard penetration testing.
Requirement: Penetration Testing
Yes
No
Penetration testing is done by third parties, as appropriate, including
design and code reviews.
For more information, see the Penetration Testing capability section in the SDL Optimization Model Implementer
Resource Guide: Advanced to Dynamic.
15
Capability Area: Release and Response
Requirements for the Standardized maturity level
Capability: Final Security Review
The Final Security Review (FSR) stage, performed by the security expert team, is the final stage before release
wherein the activities of earlier SDL phases can be verified. The SDL pilot projects should be given a Final Security
Review.
Requirement: Ability to identify high-risk projects as final security
review candidates
Yes
No
Yes
No
Yes
No
Yes
No
Security expert team and product teams conduct an FSR for the SDL
pilot projects to ensure compliance with the SDL requirements.
Requirement: Review all verified but unfixed or declined security
bugs.
Quality gates are enforced for the number and severity of bugs
released to production, and relevant bugs have not been
downgraded or ignored.
Requirement: Review internal and external policy and regulatory
compliance.
Verify that internal security policies have been followed and that
products meet relevant external regulatory requirements for privacy
and security.
Requirement: Review exception requests.
The security expert team reviews and approves all requested
exceptions to security policies and quality gates.
For more information, see the Final Security Review capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Capability: Project Archiving
To better facilitate the debugging of security vulnerabilities reported to you, it is strongly recommended that you
upload debugging symbols to a central, internal site that can be easily accessed by your engineers. Debuggers use
symbols to turn addresses and numbers into human-readable function names and variable names. This debug
symbol requirement applies to all publicly released binaries.
Requirement: Debug symbols are archived for all publicly released
binaries.
Support engineers can easily retrieve symbols for all versions of
publicly released binaries.
16
Yes
No
For more information, see the Project Archiving capability section in the SDL Optimization Model Implementer
Resource Guide: Basic to Standardized.
Capability: Response Planning and Execution
The security team should work with project teams for high-risk projects to develop an incident response plan
before software is released and should be able to execute servicing and to track and analyze incidents for
production code.
Requirement: Need 24 x 7 x 365 contact information for
engineering and operations recorded for projects
Yes
No
New code and projects have recorded contacts for incident
response, and a security response first responder contact point is
made available to clients and the general public.
For more information, see the Response Planning and Execution capability section in the SDL Optimization Model
Implementer Resource Guide: Basic to Standardized.
Requirements for the Advanced maturity level
Capability: Final Security Review
The tasks in the Final Security Review stage are performed by the security expert team for all projects falling under
the expanded SDL mandate.
Requirement: Final Security Review for all SDL-qualified projects
Yes
No
The security expert team performs a Final Security Review for all
projects falling under the organizational mandate for SDL
compliance. Projects must meet their FSR requirements or go
through an approved exception process prior to release.
For more information, see the Final Security Review capability section in the SDL Optimization Model Implementer
Resource Guide: Standardized to Advanced.
Capability: Response Planning and Execution
Organizations reaching the Advanced level should have experience responding to security incidents and should
have a full response plan in place. In addition to the requirements at the Standardized level, this response plan
should include a catalog of and the ability to respond to vulnerabilities introduced by third-party code and
dependencies, along with code owned directly by the organization.
17
Requirement: Response plan in place and tested
Yes
No
Yes
No
A proven response plan is in place and has been tested by real-world
incidents or in readiness exercises.
Requirement: Incidents tracked and basic root-cause analysis is
performed
Vulnerabilities found after release are recorded and analyzed to
provide benchmarks for the effectiveness of the SDL process and to
suggest ways to improve it within the organization.
For more information, see the Response Planning and Execution capability section in the SDL Optimization Model
Implementer Resource Guide: Standardized to Advanced.
Requirements for the Dynamic maturity level
Capability: Response Planning and Execution
At the Dynamic level, incident tracking and security response should be well rehearsed and should be able to
happen in near real time, for internal code and for third-party code or dependencies. Root-cause analysis is
advanced and includes scrubbing of all code for similar vulnerabilities and formal feedback into the SDL policy to
prevent repeat incidents of the same bug class.
Requirement: Response in near real time
Yes
No
Yes
No
Security incident tracking and response can happen in near real time
for internal and for third-party code or dependencies.
Requirement: Advanced root-cause analysis with feedback into the
SDL policy
The root cause of all security incidents is analyzed. Code is scrubbed for
other instances of the same vulnerability and incident analysis feeds back
into the SDL policy. New activities and practices are introduced where
necessary to prevent future bugs of the same class as historical ones.
For more information, see the Response Planning and Execution capability section in the SDL Optimization Model
Implementer Resource Guide: Advanced to Dynamic.
18