NIST Special Publication 800-218, the Secure Software Development Framework (SSDF). It defines outcomes to aim for, not tools to run, so it fits Agile, Waterfall, or DevSecOps. 42 tasks grouped into 19 practices under 4 pillars.
Prepare the Organization (PO)
Put people, rules, and tooling in place before coding starts.
Train and Vet Staff
Every new developer takes secure coding training. Anyone touching sensitive code gets a clearance check. Security policies are distributed and quiz-validated.
Control the Toolchain
Build-system scanners are kept fed with fresh vulnerability data. Libraries come from a curated, pre-vetted list. Unapproved third-party tools are blocked.
Define Security Goals
A ban list names bug classes that must never reach production. Remediation deadlines are set per severity, for example critical within 7 days. Security tests have a pass mark.
Lock Down the Environment
Developer accounts use MFA and access logging. Build servers sit on an isolated network. Dev and deployment environments are separate. Access is role-based, backed by a formal access control model.
Track Progress with Metrics
Training completion and quiz scores. Share of repos with active scanners. Count of unapproved libraries. Releases shipped with known flaws. On-time critical-fix rate. MFA adoption.
Enforce a CI/CD Security Gate
The gate must fail hard with exit code 1, so a committed API key or vulnerable library stops the build. Run cheap code checks before expensive dependency builds.
Protect the Software (PS)
Stop code and released artifacts from being tampered with or leaked, at rest and in transit.
Protect All Forms of Code
Source lives in version control with least-privilege access and mandatory review before merge. Sign commits where feasible so authorship is verifiable.
Verify Integrity on Release
Publish a cryptographic hash and signature for every release. Consumers then check that the download matches the build.
Archive Each Release
Keep the exact source, build inputs, and settings for every shipped version. An old release can then be rebuilt and investigated after a vulnerability report.
Record Provenance
List what went into each build: dependencies, build tools, parameters. This is usually a Software Bill of Materials (SBOM). Downstream users use it to assess exposure to a newly disclosed flaw.
Produce Well-Secured Software (PW)
Design, write, and test so that few vulnerabilities exist at release, and those that do are found early.
Start with Security Requirements
Model how the design could be attacked through data flows, trust boundaries, and abuse cases. Revise the architecture to remove or mitigate each threat.
Reuse Well-Secured Components
Prefer vetted internal or third-party modules over rewriting auth, crypto, or parsing code. Track their versions and known flaws.
Follow Secure Coding Practices
Use safer languages and library functions, compiler warnings, and hardening flags. Follow the organization’s coding standard. Keep humans away from error-prone tasks a tool can do.
Review and Test Code
Combine human review with static analysis, then dynamic analysis and fuzzing. Include negative tests for what must not happen. Fix root causes, not symptoms.
Configure Defaults Securely
Ship with least privilege, features off, and logging on, so a default install is safe.
Respond to Vulnerabilities (RV)
Find and fix flaws that reach production, and feed the lessons back into development.
Identify Vulnerabilities Continuously
Run a disclosure programme with a known intake channel. Monitor advisories for used components. Keep scanning released software.
Assess, Prioritise, and Remediate
Confirm each report. Judge severity and exploitability. Patch within the fix-time rule for that severity. Disclose to affected users.
Analyse Root Cause
For each confirmed vulnerability, find the underlying cause. Check whether similar flaws exist elsewhere. Update requirements, design, tooling, or training so the class does not recur.