SDL Practice #1: Core Security Training
This practice is a prerequisite for implementing the SDL. Foundational concepts for building better software include secure design, threat modeling, secure coding, security testing, and best practices surrounding privacy.
When should this practice be implemented?
Software development team members in technical roles (developers, testers, and program managers) must attend at least one unique security training class each year. For training that is relevant to each development phase, see Recommended Training below.
SDL Practice #7: Use Threat Modeling
Applying 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.
When should this practice be implemented?
- Traditional Software development: Design Phase
- Agile development: Every Sprint
-
Resources specific to this practice
SDL Practice #8: Use Approved Tools
Publishing 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.
When should this practice be implemented?
- Traditional Software development: Implementation Phase
- Agile development: Every Sprint
-
Resources specific to this practice
SDL Practice #9: Deprecate Unsafe Functions
Analyzing 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.
When should this practice be implemented?
- Traditional Software development: Implementation Phase
- Agile development: Every Sprint
-
Resources specific to this practice
SDL Practice #10: Perform Static Analysis
Analyzing the source code prior to compile provides a scalable method of security code review and helps ensure that secure coding policies are being followed.
When should this practice be implemented?
- Traditional Software development: Implementation Phase
- Agile development: Every Sprint
-
Resources specific to this practice
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
-
Resources specific to this practice
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
-
Resources specific to this practice