The software development life cycle, or SDLC, is the set of stages software passes through from planning to retirement. Most SDLC models say little about security, so NIST's Secure Software Development Framework, SP 800-218, adds a core set of practices to fit into any of them. Map them to your phases, not the other way round.
What are the usual phases?
Names vary by team, but the shape is steady: plan and gather requirements, design, build, test, release and deploy, operate and maintain, retire. Agile teams loop through these in weeks. Waterfall teams do them once in order. A DevOps team may blur several into one pipeline.
NIST makes the key point in the abstract of SP 800-218: few SDLC models explicitly address software security in detail, so secure development practices usually need to be added to each model. That is why a team can follow a textbook life cycle and still ship vulnerable code.
How does the SSDF organize practices?
The framework groups practices into four sets. Prepare the Organization (PO) is about people, processes and technology being ready. Protect the Software (PS) is about keeping code and artifacts from tampering. Produce Well-Secured Software (PW) is about designing, building and testing with few vulnerabilities. Respond to Vulnerabilities (RV) is about finding and fixing issues in released software and addressing root causes.
NIST says following the practices should help producers reduce vulnerabilities in released software, lessen the impact of exploitation of undetected ones, and address root causes to prevent repeats. It also says the common vocabulary helps buyers talk to suppliers during acquisition.
Where does security go in each phase?
Plan. Decide the security requirements: data handled, who may access it, regulations that apply. Assign who owns risk decisions. This is PO territory.
Design. Model threats before building. Ask what an attacker would target and what happens if a component fails. A design review is far cheaper than a rebuild.
Build. Use secure coding standards, review code, manage secrets outside source control, and track every third-party dependency. This is where PS and PW overlap, since the source and build environment themselves need protection.
Test. Combine static analysis, dependency checks, dynamic testing of running builds and targeted manual review for risky features. Run them in the pipeline so failures block merges where it makes sense.
Release. Sign artifacts, keep a record of what went into each build, and verify what gets deployed is what was built.
Operate. Monitor, patch and respond. RV applies here. Have a way to receive vulnerability reports and a path to fix and ship quickly.
Retire. Remove old systems, revoke their keys and accounts, and plan data disposal. Forgotten systems are common entry points.
A constructed example
A team of 25 builds an invoicing web app on a two-week sprint cycle. They map each phase to one check. At planning, the product owner records that the app stores bank details, so it is marked high sensitivity. At design, a one-hour threat review finds that exported invoices could be fetched by guessing IDs, and adds an authorization check to the plan. At build, pull requests need one review and a dependency check. At release, the pipeline signs the container image. After release, a customer reports a flaw through a published address, and the team fixes and ships within the same sprint. Six months on, the team retires an old reporting service, removing its database credentials the same day.
How to check or apply this
- Write down your actual phases, as practiced, not as documented.
- Map one security activity to each phase and name an owner.
- Add automated checks to the pipeline for dependencies, secrets and code issues.
- Keep a bill of materials for each release.
- Publish a way to report vulnerabilities, and track time to fix.
- Review each incident for a root cause, and add a check that would catch it next time.
- Compare your practices with the SSDF groups and note gaps.
Safeguard's SBOM and dependency scanning and its policies and gates can sit in the build and test phases, and reachability analysis helps decide which dependency findings to fix first. They cover part of the life cycle, not all of it.
Quick check
Is the SSDF a certification?
No. It is a framework of recommended practices published by NIST.
Does Agile change where security goes?
The phases repeat in each iteration, so the activities repeat too. Automating checks keeps them from slowing every sprint.
Sources
Last reviewed: 18 October 2026.
