Chapter 1. Secure Development Lifecycle
A Note for Early Release Readers
With Early Release ebooks, you get books in their earliest formthe authors raw and unedited content as they writeso you can take advantage of these technologies long before the official release of these titles.
This will be the 3rd chapter of the final book.
If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at rfernando@oreilly.com.
A secure development lifecycle (SDL) consists of activities that strengthen an application or products security posture during the software development lifecycle (SDLC). This can also be known as a secure software development lifecycle (SSDL, SSDLC, S-SDLC) or Secure Software Development Framework (SSDF). However you call it, its main goal is to augment an SDLC such as waterfall, Agile (e.g., Scrum, XP, or Kanban), hybrid, or iterative (combined waterfall and Agile methodologies). Your organization may already have SDL processes within its existing SDLC or DevOps processes, even if they arent called as such.
This chapter will discuss the details of SDLs, augmenting SDLCs, and the more popular SDLs you can use in your organization. SDLs are now a required element in many cybersecurity legal agreements and certifications. The decision of which SDL to use is specific to your organization. Once your organization has selected an SDL, document the selection and appropriate details in a corporate SDL policy.
Secure Development Lifecycle Control 01
Control SDL-01: Maintain a Secure Development Lifecycle (SDL) framework and policy which requires employees, contractors, and third parties to follow SDL practices for applications and products.
Key Elements of an SDL
An SDL is the foundation for a secure software supply chain. There are four key elements of an SDL that exist across the various SDL frameworks: security requirements, secure design, secure development, and security testing. Although you can reduce risk by implementing various aspects of an SDL, such as secure testing, without an SDL, you may still find yourself at a disadvantage. An SDL will help you implement a secure software supply chain with secure requirements, design, and development in a reproducible process.
Security Requirements
Security requirements may be defined in laws, regulations, and SDL frameworks, or by customers, internal requirements, and threat models. for cryptographic modules. At some point, all of these security requirements should be documented in a requirements or user stories database. Traceability between these requirements, the threat models, and secure test cases are important for validating the requirements prior to a product or application release.
For some software supply chain security risks, you can transform the security control into a security requirement. One such example would be the Infrastructure Security Control IS-08 for patching as seen in Chapter 4, Infrastructure Security in the Product Lifecycle. An application security requirement or user story specifically to auto-update software would resolve part of the IS-08 security control.
Secure Development Lifecycle Control 02
Control SDL-02: Document and maintain security requirements for applications and products. Include security requirements that are required by applicable laws and regulations.
Secure Design
The concept of secure design (or secure-by-design) is not only about architecture and infrastructure, but also about the security requirements implemented into the system. Within a product or application, secure design is when a product has gone through activities to evaluate the requirements and potential threats to limit risk. Risk to software supply chain security is greatly reduced when secure design activities such as threat modeling are performed. Even products that have been previously designed will benefit greatly from a complete threat model that analyzes entry points, code, services, protocols, APIs, and more. Threat models should be considered living artifacts that you must re-examine when architecture changes. When risks are identified through threat models, additional security requirements must be added to the product.
Another type of secure design is privacy by design (sometimes called PbD).This includes data security, data protection, and data localization requirements for personal or business data. Considering PbD early in the design process can significantly reduce rearchitecting databases, structures, and common methods such as encryption to meet changing privacy requirements.
Secure Development Lifecycle Control 03
Control SDL-03: Use secure-by-design and privacy-by-design concepts when designing applications and products. Conduct threat modeling on all code, services, systems, infrastructure, APIs, and protocols.
Secure Development
Secure development is one of the four key elements of an SDL. Secure development involves the methods, techniques, and practices developers should follow and use during code development. This includes important areas such as proper error handling, fault handling, memory management, and following secure coding standards. Secure coding standards always should include evaluation for back doors or private keys. Secure coding rules must be specific for the technology and languages your organization uses but if your organization does not have secure coding standards in place, refer to the OWASP Secure Coding Practices-Quick Reference Guide to use as a baseline for your organization.