New SDLC: Security Development Life Cycle

simplify @Image courtesy of digitalart/

New SDLC: Security Development Life Cycle

Welcome to CodeSpread!

When I heard Security Development Life Cycle, my first reaction was, is it really possible?

But, as always, Microsoft surprised me with the introduction of SDL. I just went through a paper published by Microsoft and , I have included most of the points ‘as-is’ in this article.

What is SDLC or Security Development Life Cycle?

It is a simple framework for the pragmatic inclusion of security practices in the software development process. It outlines a series of discrete, non-proprietary security development activities that when joined with effective process automation and solid policy guidance represent the steps necessary for an organization to objectively claim compliance with the Microsoft SDL as defined by the “Advanced” level in the SDL Optimization Model.

Just stress on few keywords in the above definition for ex: ‘security practices’ , ‘series’ , ‘organization’ , ‘compliance’. Now, we can try and and relate these terms in a generic manner, first of all by ‘generic practices’- we mean that SDL is not a hand written document but these are few practices which originated from individual or group’s experiences. Second, ‘series’ implies that these are a chain of steps or guidelines which are followed in an organized manner to achieve the goal. Third, ‘organization’ – this is the most important keyword which stresses on a dynamic SDLC dependent on an organization’s needs. It basically holds the due share of an organization in applying SDLC. Fourth and Last, ‘compliance’- which says set your standards and I’ll follow. This is the basic need of industry and widely accepted as a criteria in every organization.

What are the activities expected?

To achieve Security, Integration of secure development concepts into an existing development process is required. Here, we have mentioned all the stages of our other SDLC [Software Development Life Cycle] combined with security concepts to achieve our new SDLC [Security Development Life Cycle].


We will see what all security concepts can be accumulated at each stage of SDLC.

Pre-SDL Requirements: Security Training

SDL Practice 1: Training Requirements

All members of a software development team(developers, testers, and program managers) must receive appropriate training to stay informed about security basics and recent trends in security and privacy.
Basic software security training should cover foundational concepts such as:

  1. Secure design, including the following topics:
    •    Attack surface reduction
    •    Defense in depth
    •    Principle of least privilege
    •    Secure defaults
  2. Threat modeling, including the following topics:
    •    Overview of threat modeling
    •    Design implications of a threat model
    •    Coding constraints based on a threat model
  3. Secure coding, including the following topics:
    •    Buffer overruns (for applications using C and C++)
    •    Integer arithmetic errors (for applications using C and C++)
    •    Cross-site scripting (for managed code and Web applications)
    •    SQL injection (for managed code and Web applications)
    •    Weak cryptography
  4. Security testing, including the following topics:
    •    Differences between security testing and functional testing
    •    Risk assessment
    •    Security testing methods
  5. Privacy, including the following topics:
    •    Types of privacy-sensitive data
    •    Privacy design best practices
    •    Risk assessment
    •    Privacy development best practices
    •    Privacy testing best practices
    The preceding training establishes an adequate knowledge baseline for technical personnel. As time and resources permit, training in advanced concepts may be necessary. Examples include, but are not limited to, the following:
    •    Advanced security design and architecture
    •    Trusted user interface design
    •    Security vulnerabilities in detail
    •    Implementing custom threat mitigations

Phase One: Requirements

SDL Practice 2: Security Requirements

Requirement Phase allows development teams to identify security and privacy needs in a way that minimizes any disruption to plans and schedules. Security and privacy requirements analysis is performed at project inception and includes specification of minimum security requirements for the application as it is designed to run in its planned operational environment and specification and deployment of a security vulnerability/work item tracking system.

SDL Practice 3: Quality Gates/Bug Bars

Quality gates and bug bars are used to establish minimum acceptable levels of security and privacy quality. A project team must negotiate quality gates (for example, all compiler warnings must be triaged and fixed prior to code check-in) for each development phase. A bug bar is a quality gate which is used to define 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.

SDL Practice 4: Security and Privacy Risk Assessment

Security risk assessments (SRAs) and privacy risk assessments (PRAs) are mandatory processes that identify functional aspects of the software that require deep review. Such assessments must include the following information:
1.    (Security) Which portions of the project will require threat models before release?
2.    (Security) Which portions of the project will require security design reviews before release?
3.    (Security) Which portions of the project (if any) will require penetration testing by a mutually agreed upon group that is external to the project team?
4.    (Security) Are there any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks?
5.    (Security) What is the specific scope of the fuzz testing requirements?
6.    (Privacy) What is the Privacy Impact Rating? The answer to this question is based on the following guidelines:
•    P1 High Privacy Risk. The feature, product, or service stores or transfers PII, changes settings or file type associations, or installs software.
•    P2 Moderate Privacy Risk. The sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer (for example, the user clicks on a link and the software goes out to a Web site).
•    P3 Low Privacy Risk. No behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user’s behalf, and no software is installed.

Phase Two: Design

SDL Practice 5: Design Requirements

It is critically important to consider security and privacy concerns during the design phase. There is a basic difference between “secure features” and “security features”. Secure features are defined as features whose functionality is well engineered with respect to security, including rigorous validation of all data before processing or cryptographically robust implementation of libraries for cryptographic services. The term security features describes program functionality with security implications, such as Kerberos authentication or a firewall.
Design specifications should describe security or privacy features that will be directly exposed to users, like user authentication and authorization before allowing use of a  privacy feature. Also, It should also describe how to securely implement all functionalities.

SDL Practice 6: Attack Surface Reduction

Attack surface reduction is a means of reducing risk by giving attackers less opportunity to exploit a potential weak spot or vulnerability. Attack surface reduction includes restricting access to system services, applying the principle of least privilege, and employing layered defenses wherever possible.

SDL Practice 7: Threat Modeling

Threat modeling allows consideration of security issues at the component or application level. It favors involvement of program/project managers, developers, and testers, and represents the primary security analysis task performed during the software design stage.

Phase Three: Implementation

SDL Practice 8: Use Approved Tools

Development teams should use the latest version of approved tools to take advantage of new security analysis functionality and protections.This list of tools should be approved by the security advisor for the project team.

SDL Practice 9: Deprecate Unsafe Functions

Project teams should analyze all functions and APIs that will be used in conjunction with a software development project and prohibit those that are determined to be unsafe. Many commonly used functions and APIs are not secure in the face of the current threat environment. These functions should be replaced with safer alternatives.

SDL Practice 10: Static Analysis

Static analysis of source code provides a scalable capability for security code review and can help ensure that secure coding policies are being followed. The security team and security advisors should be aware of the strengths and weaknesses of static analysis tools and be prepared to augment static analysis tools with other tools or human review as appropriate.

Phase Four: Verification

SDL Practice 11: Dynamic Program Analysis

Run-time verification of software programs is necessary to ensure that a program’s functionality works as designed. This verification task should specify tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.

SDL Practice 12: Fuzz Testing

Fuzz testing is a specialized form of dynamic analysis used to induce program failure by deliberately introducing malformed or random data to an application. The fuzz testing strategy is derived from the intended use of the application and the functional and design specifications for the application.

SDL Practice 13: Threat Model and Attack Surface Review

Although re-work is avoided but sometimes it is fruitful to re-review threat models and attack surface measurement of a given application. This review ensures that any design or implementation changes to the system have been accounted for, and that any new attack vectors created as a result of the changes have been reviewed and mitigated.

Phase Five: Release

SDL Practice 14: Incident Response Plan

Every software release subject to the requirements of the SDL must include an incident response plan. The incident response plan should include:
•    A emergency response plan (ERP) that identifies the appropriate engineering, marketing, communications, and management staff to act as points of first contact in a security emergency.
•    On-call contacts with decision-making authority that are available 24 hours a day, seven days a week.
•    Security servicing plans for code inherited from other groups within the organization.
•    Security servicing plans for licensed third-party code, including file names, versions, source code, third-party contact information, and contractual permission to make changes (if appropriate).

SDL Practice 15: Final Security Review

The Final Security Review (FSR) is a deliberate examination of all the security activities performed on a software application prior to release.  The FSR includes an examination of threat models, exception requests, tool output, and performance against the previously determined quality gates or bug bars. The FSR results in one of three different outcomes:
•    Passed FSR. All security and privacy issues identified by the FSR process are fixed or mitigated.
•    Passed FSR with exceptions. All security and privacy issues identified by the FSR process are fixed or mitigated and/or all exceptions are satisfactorily resolved. Those issues that cannot be addressed (for example, vulnerabilities posed by legacy “design level” issues) are logged and corrected in the next release.
•    FSR with escalation. If a team does not meet all SDL requirements and the security advisor and the product team cannot reach an acceptable compromise, the security advisor cannot approve the project, and the project cannot be released.

SDL Practice 16: Release/Archive

Software release to manufacturing (RTM) or release to Web (RTW) is conditional on completion of the SDL process. The security advisor assigned to the release must certify (using the FSR and other data) that the project team has satisfied security requirements.

In addition, all pertinent information and data must be archived to allow for post-release servicing of the software. This includes all specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, license and servicing terms for any third-party software and any other data necessary to perform post-release servicing tasks.

These are the guidelines or practices which can be adapted to achieve security in SDLC. We recommend use of Security Development Life Cycle, so for more information, please visit msdn site.

Author: hershey

A passion for knowledge drives me to do programming, A passion for programming drives me to create something different, A passion for creation drives me to spread the knowledge.

Share This Post On


  1. nice superb explaination

    Post a Reply
  2. thanks for the tutorial
    I am having a problem.
    The feature “Create SQL server database” isn’t available , I can’t select it.
    Can you help, please ?

    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

More from CodeSpread:

  • Agile Encounters UnpredictabilityAgile Encounters UnpredictabilityWhat is Agile? Wikipedia says “Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through...
  • Security Leak: Session Fixation vulnerabilitySecurity Leak: Session Fixation vulnerabilityWhat is a Session? HTTP is a stateless protocol. Each request to the server is independent and does not contain any information about the user like who has requested which page or any information/...
  • Unused Useful Tools in Visual StudioUnused Useful Tools in Visual StudioBack from a vacation is always a great and refreshing feeling. A small break always adds a new dimension to the thoughts. Lets see what we have today which we can call ‘new’ . We are good workin...
  • SDLC: Importance of Requirement Analysis.SDLC: Importance of Requirement Analysis.What is SDLC? SDLC is the acronym for Software Development Life Cycle or System Development Life Cycle.It is a conceptual model that describes the stages involved in development of a software or a...
  • Tip : Code Structure C#Tip : Code Structure C#As a developer, I always stress on developing a habit of following the best practices to structure the code. It helps me to easily navigate through the code and also saves a lot of effort in search...
  • NetBiscuits: How fascinating can it be to create a mobile website?NetBiscuits: How fascinating can it be to create a mobile website?My very first impression was like why do I need it, who wants to see a site on a mobile? How would a website be able to fit into my mobile without destroying the look and feel of a desktop site? ...
  • Reusability defined by Microsoft Enterprise LibraryReusability defined by Microsoft Enterprise LibraryWikipedia says “The Microsoft Enterprise Library is a set of tools and programming libraries for the Microsoft .NET Framework. It provides an API to facilitate proven practices in core areas of pro...
  • Software Testing Life Cycle (STLC)Software Testing Life Cycle (STLC)Software Testing Life Cycle (STLC) is a process which consists of a number of phases to improve the quality of the product. Each phase involves various testing activities like Requirement An...