SDL Process: Verification

This phase involves a comprehensive effort to ensure that the code meets the security and privacy tenets established in the previous phases.

Training
  • Core Security Training
Requirements
  • Establish Security Requirements
  • Create Quality Gates/Bug Bars
  • Perform Security and Privacy Risk Assessments
Design
  • Establish Design Requirements
  • Perform Attack Surface Analysis/ Reduction
  • Use Threat Modeling
Implementation
  • Use Approved Tools
  • Deprecate Unsafe Functions
  • Perform Static Analysis
Verification
  • Perform Dynamic Analysis
  • Perform Fuzz Testing
  • Conduct Attack Surface Review
Release
  • Create an Incident Response Plan
  • Conduct Final Security Review
  • Certify Release and Archive
Response
  • Execute Incident Response Plan

SDL Practice #11: Perform Dynamic Analysis

Performing run-time verification of your software checks functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.

When should this practice be implemented?

Traditional Software development: Verification Phase
Agile development: Bucket Verification

SDL Practice #12: Perform Fuzz Testing

Inducing program failure by deliberately introducing malformed or random data to an application helps reveal potential security issues prior to release while requiring modest resource investment.

When should this practice be implemented?

Traditional Software development: Verification Phase
Agile development: Bucket Verification

SDL Practice #13: Conduct Attack Surface Review

Reviewing attack surface 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.

When should this practice be implemented?

Traditional Software development: Verification Phase
Agile development: Bucket Verification