The Secure Software Development Framework (SSDF) is a set of high-level secure software development practices published by the US National Institute of Standards and Technology (NIST) as Special Publication 800-218. It does not prescribe a specific development method or tool. Instead, it describes outcomes that can be added to any software development life cycle, so that software producers release fewer vulnerabilities, limit the damage from the ones that slip through and fix root causes. It also gives buyers and suppliers a shared vocabulary for talking about how software is built. This entry is general information, not legal advice.
At a glance
- The SSDF groups its practices into four areas: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities.
- It is written for software producers, but buyers use it to question vendors during procurement.
- Version 1.1 is the current final version; NIST has published a draft revision for comment.
- NIST does not certify against the SSDF; evidence is a self-attestation, a mapping or an independent review.
- A companion publication, SP 800-218A, adds practices for generative AI and dual-use foundation models.
What problem it solves
Most organizations depend on software they did not write: SaaS applications, on-premises products, firmware and open-source components. When a vendor ships a vulnerable or tampered product, the customer inherits the risk, and a supply chain attack through one widely used product can reach thousands of companies at once.
Buyers have had few good ways to judge a vendor’s development discipline before signing. Questionnaires asked vague questions and got vague answers. The SSDF gives a structured, vendor-neutral list of practices, so a buyer can ask specific questions and a producer can describe what it actually does. For organizations that build software themselves, it gives development, security and operations teams a common baseline, which fits naturally with DevSecOps ways of working.
How it works
Practices, tasks and examples. Each practice has an identifier, a short statement of the outcome, tasks that achieve it, examples of how to implement it and references to other standards and guidance. Producers choose how to meet each practice in their own process.
Risk-based adoption. NIST presents the practices as something to adopt according to risk, cost and the software’s purpose, not as a checklist every team must complete in the same way. A small internal tool and a widely deployed commercial product may reasonably apply them differently.
Common vocabulary. Because the practices are stable and named, a buyer can reference them in contracts or questionnaires and a producer can map its secure development program to them. Federal software purchasing in the US has drawn on the SSDF, for example through supplier attestations; those requirements have changed over time, so confirm what currently applies.
Fit with other publications. The SSDF connects to NIST’s broader security guidance, including the control catalog in NIST SP 800-53 and supply chain guidance in NIST SP 800-161. See the NIST SP 800 series for how these documents relate.
Practice groups
The SSDF has no levels or certification tiers. Its structure is four practice groups, each with its own practices and tasks.
| Practice group | What it covers | How it is shown | Typical evidence |
|---|---|---|---|
| Prepare the Organization (PO) | Roles, training, security requirements for software, toolchains and secure development environments | Producer’s own program, sometimes independently reviewed | Policies, training records, documented requirements |
| Protect the Software (PS) | Protecting code and components from tampering and unauthorized access, and providing ways to verify releases | Producer’s own controls | Access controls on repositories, signed releases, archived builds |
| Produce Well-Secured Software (PW) | Secure design, review and testing, safe use of third-party components and secure default settings | Producer’s own process, plus testing | Threat models, code review and test results, component inventories such as an SBOM |
| Respond to Vulnerabilities (RV) | Finding, assessing and fixing vulnerabilities in released software and preventing repeats | Producer’s own process | Vulnerability disclosure policy, advisories, fix timelines, root-cause analysis |
Because none of this is certified by NIST, a vendor stating it “follows the SSDF” is describing its own view, an attestation or an assessor’s review. Ask which one, and for which products.
When it matters for buyers
- When a customer asks you to attest. Software producers selling to government or large enterprises may be asked to confirm SSDF-aligned practices.
- When evaluating a critical software vendor. Use the four practice groups to structure questions about how the product is built, protected and patched.
- When writing procurement or third-party risk requirements. Referencing the SSDF is clearer than asking whether a vendor “develops securely”.
- When building software in-house. It gives your teams a baseline that maps to tooling such as code scanning and pipeline security.
- When a vendor claims to be secure by design. The SSDF gives you specific practices to ask about.
Our application security testing overview covers services that test code and help producers show evidence for these practices.
Questions to ask vendors
- Do you map your development practices to the SSDF, and can we see that mapping for the product we would buy?
- Is your SSDF claim a self-attestation or has an independent party reviewed it?
- How do you protect source code, build systems and release artifacts from tampering, and can we verify a release is genuine?
- Can you provide an SBOM, and how do you track vulnerabilities in third-party components?
- What is your vulnerability disclosure process, and what fix timelines do you commit to for critical issues?
- Which SSDF version do your documents reference, and how will you handle the newer revision when it is final?
How it differs from Secure by Design
Secure by design is a broad principle and public campaign urging manufacturers to build security in from the start and ship safe defaults, and to take ownership of customer security outcomes. The SSDF is a specific NIST publication that breaks secure development into named practices and tasks that can be mapped, attested and checked. Secure by design says what a producer should aim for; the SSDF gives a structured way to show how it gets there. DevSecOps is the working model many teams use to put those practices into day-to-day delivery.
Problems this helps with
- A federal or enterprise customer asks us to attest to secure development practices
- No consistent way to judge how software vendors build and patch their products
- Our own development teams follow different security practices
- Worried about vulnerabilities and tampering in software we buy
