Security Development Lifecycle (SDL) Study Plan
This page is updated based on jassics/security-study-plan/secure-software-development-lifecycle-study-plan. Also, I assume you have already checked and are comfortable with the Common Security Skills study plan.
SDL is about building security into each phase of software delivery - requirements, design, coding, testing, release, and maintenance - instead of treating security as a separate step at the end. It's more towards:
- Defining security activities and checkpoints in the SDLC
- Aligning developers, product, and security teams on expectations
- Integrating AppSec/DevSecOps/Product Security work into a repeatable process
- Giving organizations a structured way to measure and improve security maturity
It usually takes 6-12 weeks to be comfortable with SDL fundamentals and apply them in real projects.
In Short
- SDL is not just a document - it's how security is embedded into the way software is built.
- Think of it as a framework connecting Application Security, DevSecOps, Product Security, and Architecture.
- Be comfortable talking about SDLC phases and which security activities belong where.
- Know how to keep SDL practical for agile and cloud-native teams.
- Understand how to start small and evolve the SDL over time.
ToC
- SDL Fundamentals - 1-2 weeks
- Security in Requirements and Design - 2-3 weeks
- Security in Implementation and Code Review - 2-3 weeks
- Security Testing and Verification - 2-3 weeks
- Release, Operations and Feedback - 1-2 weeks
- Frameworks and Maturity Models - 1-2 weeks
- Books, Videos, Courses, Certifications
- Interview Questions
SDL Fundamentals
Duration: 1-2 weeks
Goal: understand what SDL is trying to achieve.
Week 1-2: The Big Picture
- Review basic SDLC models - waterfall vs iterative vs agile, and how modern teams actually deliver (Scrum/Kanban, CI/CD)
- Understand SDL goals - reduce vulnerabilities introduced during development, catch issues earlier when they're cheaper to fix, provide traceability for security activities
- Read or refresh related plans: Application Security, DevSecOps, Product Security, Security Architecture
Security in Requirements and Design
Duration: 2-3 weeks
Security must start before code is written.
Week 3-5: Shift Left
- Requirements phase - define security/privacy requirements alongside functional ones (authN/authZ, logging, encryption, data retention, compliance); work with Product Security and GRC to capture constraints
- Design phase - perform high-level architecture reviews, do threat modeling for new features/major changes (see Threat Modeling Study Plan), choose appropriate security patterns (gateway, zero trust, secure data flow)
- Deliverables - documented security requirements, threat models/risk assessments, architecture diagrams with security controls marked
Security in Implementation and Code Review
Duration: 2-3 weeks
Focus on day-to-day development activities.
Week 6-8: Secure Build
- Secure coding practices - follow language-specific secure coding guidelines (see this site's Secure Coding guide), use frameworks/libraries securely
- Code review - integrate basic security checks into regular code reviews, use checklists for common issues
- Automation - introduce SAST and SCA as part of the build; ensure findings are triaged and assigned, not ignored
- Deepen code review skills with the Secure Code Review Study Plan
Security Testing and Verification
Duration: 2-3 weeks
Testing must verify that controls are correctly implemented.
Week 9-11: Verification
- Unit and integration tests with security in mind where possible
- DAST/API testing for running apps and services
- Additional methods where relevant - IAST, fuzzing, penetration testing
- Non-functional aspects - performance/reliability under attack conditions (e.g., rate limiting)
- Ensure test results feed back into the backlog and SDL metrics
Release, Operations and Feedback
Duration: 1-2 weeks
Security doesn't end at release.
Week 12-13: Post-Release
- Pre-release - security sign-off criteria for high-risk features, checklist to verify critical controls (auth, logging, encryption)
- Operations - secure configuration management, monitoring/alerting for security-relevant events, patch/vulnerability management
- Feedback loop - use incidents and pen test findings to improve earlier SDL phases; regular retrospectives on security issues
Frameworks and Maturity Models
Duration: 1-2 weeks
Understand how SDL ties into broader frameworks.
Week 14-15: Maturity
- OWASP SAMM (Software Assurance Maturity Model) - high-level understanding of practice areas and maturity levels
- Microsoft SDL concepts, at a summary level
- How SDL relates to standards like ISO 27001, NIST, etc.
- Use maturity models to assess current state and plan incremental improvements
Books, Videos, Courses, Certifications
Books: books on building Application Security or Product Security programs (to see how SDL is implemented in practice); secure software development/secure coding books tied to SDLC
Videos: Developing Secure Software (LFD121) by The Linux Foundation (free); conference talks on secure SDLC in agile/DevOps environments; talks on OWASP SAMM and real-world program maturity journeys
Courses: courses focused on secure software development/secure SDLC; DevSecOps and Application Security courses on integrating security into pipelines and processes
Certifications: CSSLP: Certified Secure Software Lifecycle Professional; other secure software development or AppSec/DevSecOps certifications depending on your focus
Interview Questions
Reuse many questions from the Application Security and Product Security interview sets, but think through the SDL lens:
- How would you introduce security into an existing agile SDLC with minimal disruption?
- Which security activities would you recommend at each phase of the SDLC and why?
- How would you measure whether your SDL is working and improving over time?
Practice next: Application Security interview questions and DevSecOps interview questions, and jassics/security-study-plan for the latest updates to this plan.