Secure SDLC: Software Application Security Guide
A secure software development lifecycle (secure SDLC) puts a security activity into every stage of building software, so flaws are prevented in design and caught in testing instead of found in production. The reference most teams map to is NIST SP 800-218, the Secure Software Development Framework (SSDF).
This guide gives a stage-by-stage map with SSDF practice IDs, explains the testing types, and links to the tools that let you try each step.
Updated 3 November 2026
Secure SDLC stage by stage
| Stage | Security activity | SSDF practice (v1.1) | Try it |
|---|---|---|---|
| Requirements | Define security requirements and roles. | PO.1, PO.2 | SSDF self-assessment |
| Design | Threat model; review the design. | PW.1, PW.2 | Threat model |
| Implementation | Secure coding, code review, protect the repository and secrets. | PW.5, PW.7, PS.1 | Secret scanner |
| Build and CI | Harden build configuration and pipelines. | PW.6, PO.3 | GitHub Actions auditor |
| Testing | Test executable code (SAST, SCA, DAST). | PW.8 | Testing chooser, DAST |
| Release | Secure defaults; verify release integrity. | PW.9, PS.2, PS.3 | SSDF explained |
| Operations | Identify, prioritise and fix vulnerabilities; find root causes. | RV.1, RV.2, RV.3 | Vulnerability prioritizer |
Practice IDs are from SP 800-218 version 1.1 (February 2022), the version NIST lists as final. NIST published Rev. 1 (SSDF 1.2) as an initial public draft on 17 December 2025; as of 3 November 2026 no final version was listed on the NIST page.
Software application security testing, in order
- SCA finds known-vulnerable third-party components; run it on every build.
- SAST analyses source code without running it; run it on every commit or pull request.
- DAST probes the running application from outside; run it against staging. See what is DAST.
- IAST instruments the running app from inside during tests.
- Human review and penetration testing cover business logic and attack chains that tools miss.
Use the application security testing chooser to pick a starting point, and aim your design reviews at the flaws in OWASP Top 10 explained.
How to start without a big programme
- Rate yourself with the SSDF self-assessment and pick the three weakest practices.
- Add secret scanning and dependency checks to CI first; they are cheap and catch common problems.
- Threat model the one system holding the most sensitive data.
- Add DAST against staging, then triage findings by exploitability.
- Write down how vulnerability reports are received and fixed, and test that process once.
Frequently asked questions
What is a secure software development lifecycle (secure SDLC)?
A secure SDLC adds security activities to every stage of building software: requirements, design, coding, testing, release and response, rather than testing for security at the end. The NIST Secure Software Development Framework (SP 800-218) describes the outcomes such a lifecycle should achieve, in four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities.
What are the stages of a secure SDLC?
Common stages are requirements, design (with threat modelling), implementation (secure coding and code review), testing (SAST, SCA, DAST), release (integrity and secure defaults) and operations (vulnerability response). Each stage has a security activity attached. The table in this guide maps them to SSDF practice IDs.
What is the difference between SSDLC and the NIST SSDF?
A secure SDLC is the process your team runs. The SSDF is a set of high-level, outcome-based practices that you map onto whatever process you have. NIST says it does not prescribe how to implement each practice.
What is software application security testing?
It is the set of automated and manual techniques that find weaknesses in an application: static analysis of code (SAST), checks of third-party components (SCA), testing the running app from outside (DAST) and instrumented testing from inside (IAST). They are complementary. Use the application security testing chooser to decide which you need first.
Where does threat modelling fit?
In design, before code is written. It finds flaws that scanners cannot see, such as a missing authorisation boundary. Use the threat model tool to diagram the system and list threats per component.
Is SSDF attestation still required?
In January 2026, OMB memo M-26-05 rescinded the memos that made the federal self-attestation form mandatory; agencies may still use it and many buyers still ask for it. Check your customer contracts.