Secure Software Development Lifecycle
A secure software development lifecycle adds security work to the way you plan, design, build, verify, release, and maintain software. It turns security requirements, reviews, tests, and vulnerability response into routine development work instead of a final check.
itOffensive security and application security | OpenSkills.info
Intro
Secure Software Development Lifecycle
A secure software development lifecycle, or secure SDLC, integrates security practices into an existing software development lifecycle. You keep your delivery method. You add security requirements, responsibilities, evidence, and feedback wherever they change a decision.
This matters because a final penetration test sees only part of the system. It arrives after teams have made architecture choices, selected dependencies, built delivery infrastructure, and written most of the code. Some findings can still be fixed. Others require expensive redesign or remain as accepted risk.
A secure SDLC moves relevant work closer to the decisions it can influence:
prepare → require → design → implement → verify → release → respond
↑ ↓
└──────────── lessons, defects, and new threats ──────────┘
The path is a loop, not a one-time checklist. Released software still changes. Its dependencies, environment, users, and threats change too. Vulnerability reports and incidents should update requirements, designs, tests, and development practices.
Start with outcomes
NIST's Secure Software Development Framework, or SSDF, groups its practices into four outcome areas:
- Prepare the Organization: Define requirements, roles, training, tools, and development environments.
- Protect the Software: Protect code and releases from unauthorized access or change.
- Produce Well-Secured Software: Apply secure design, implementation, review, testing, and component practices.
- Respond to Vulnerabilities: Receive reports, remediate vulnerabilities, and address root causes.
These areas do not prescribe a waterfall process. NIST designed the SSDF practices for integration into any software development lifecycle. An agile team can add security criteria to backlog items and automated checks to each change. A team with formal stage gates can require specific evidence before a phase closes.
The framework gives you a common vocabulary. Your program must still translate each outcome into work, ownership, and evidence.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Sources
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- Secure development practices integrated into any software development lifecycle
- SSDF purpose, scope, common vocabulary, and risk-based implementation
- Reduction of released vulnerabilities, mitigation of undetected vulnerabilities, and prevention of recurrence
- Reference-path rationale for the NIST SSDF publication
- https://doi.org/10.6028/NIST.SP.800-218
Supports
- Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities
- Requirements, roles, training, toolchains, development environment protection, and release integrity
- Threat modeling, design review, code review, security testing, third-party component review, and secure defaults
- Vulnerability intake, remediation, root-cause analysis, and process improvement
- Quiz answers and all lifecycle, evidence, tailoring, and response claims
- https://owaspsamm.org/about/
Supports
- SAMM as a measurable, actionable, risk-driven model for the complete software lifecycle
- Current-state assessment, target definition, and incremental improvement roadmap
- Tailoring maturity targets rather than requiring maximum maturity in every practice
- Reference-path rationale and maturity quiz answer
- https://owaspsamm.org/model/
Supports
- Governance, Design, Implementation, Verification, and Operations business functions
- Detailed practices, activities, maturity levels, and success metrics
- Lifecycle tailoring, exception governance, measures, and improvement claims
- Reference-path rationale for detailed SAMM practices
- https://owasp.org/www-project-application-security-verification-standard/
Supports
- ASVS 5.0.0 as the current stable release
- Technical requirements for web application design, development, testing, metrics, and procurement
- Versioned requirement identifiers and machine-readable requirement lists
- Requirement-selection guidance, glossary, quiz answer, and reference-path rationale
- https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-security-development-lifecycle
Supports
- Training, requirements, design, implementation, verification, release, and response activities
- Maintained security requirements and threat models
- Static, binary, secret, encryption, fuzz, configuration, component, manual, and penetration testing
- Independent review, release decisions, monitoring, and post-release response
- Introductory examples, quiz answers, and reference-path rationale
- https://www.microsoft.com/en-us/securityengineering/sdl/practices
Supports
- Security risks across design, code, build and deploy, and runtime
- Governance, proven security features, threat modeling, supply-chain security, engineering environment security, testing, operations, response, and training
- Protection of repositories and build systems
- Reference-path rationale for the current SDL practice set
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Application Security and DevSecOps awesome lists
- https://github.com/jakob-pennington/awesome-devsecops
Supports
- Curated discovery of OWASP Threat Dragon, Semgrep, OWASP Dependency-Check, ZAP, and OWASP Juice Shop
- Tool categories spanning threat modeling, static analysis, dependency analysis, dynamic analysis, and intentionally vulnerable applications
- https://owasp.org/www-project-threat-dragon/
Supports
- Threat-model diagrams, recorded threats, mitigations, and visual threat surfaces
- Web and desktop application options
- Threat-model quiz answer and Awesome Links rationale
- https://www.threatdragon.com/docs/
Supports
- Learner destination for installing, using, and working with Threat Dragon models
- Awesome Links destination and rationale
- https://docs.semgrep.dev/
Supports
- Static application security testing, software composition analysis, and secrets scans
- Code-standard enforcement with custom rules and finding triage
- Static-analysis scope quiz answer and Awesome Links rationale
- https://owasp.org/www-project-dependency-check/
Supports
- Software composition analysis that associates dependencies with publicly disclosed vulnerabilities
- Command-line, build plug-in, and continuous integration options
- Awesome Links rationale
- https://www.zaproxy.org/docs/
Supports
- ZAP guides, desktop documentation, automation, containers, authentication, and alert details
- Dynamic security testing learner destination and Awesome Links rationale
- https://owasp.org/www-project-juice-shop/
Supports
- Intentionally insecure web application for training, demonstrations, and security-tool evaluation
- Guided challenges, coding challenges, and tracked practice
- Awesome Links rationale
- https://owasp-juice.shop/
Supports
- Current learner destination for OWASP Juice Shop