• SDL Process: Release

  • The focus of this phase is readying a project for public release, including planning ways to effectively perform post-release servicing tasks and address security or privacy vulnerabilities that may occur later.

Training

Requirements

Design

Implementation

Verification

Release

Response

  1. Core Security Training

  1. Establish Security Requirements

  1. Create Quality Gates/Bug Bars

  1. Perform Security and Privacy Risk Assessments

  1. Establish Design Requirements

  1. Perform Attack Surface Analysis/ Reduction

  1. Use Threat Modeling

  1. Use Approved Tools

  1. Deprecate Unsafe Functions

  1. Perform Static Analysis

  1. Perform Dynamic Analysis

  1. Perform Fuzz Testing

  1. Conduct Attack Surface Review

  1. Create an Incident Response Plan

  1. Conduct Final Security Review

  1. Certify Release and Archive

  1. Execute Incident Response Plan

Previous previous phase
next phase Next
  • SDL Practice #14: Create an Incident Response Plan
  • Preparing 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.
  • When should this practice be implemented?
  • Traditional Software development: Release Phase
    Agile development: One Time
  • SDL Practice #15: Conduct Final Security Review
  • Deliberately 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.

    The FSR results in one of three different outcomes: Passed FSR, Passed FSR with exceptions, FSR with escalation.
  • When should this practice be implemented?
  • Traditional Software development: Release Phase
    Agile development: Every Sprint
  • SDL Practice #16: Certify Release and Archive
  • Certifying 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.

    Archiving should include all specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, and license and servicing terms for any third-party software.
  • When should this practice be implemented?
  • Traditional Software development: Release Phase
    Agile development: Every Sprint