NIST published the Secure Software Development Framework (SP 800-218) in February 2022, and it became mandatory reading for anyone selling software to the U.S. federal government after OMB Memorandum M-22-18 required a signed self-attestation form for every federal software producer by June 2023 (later formalized as the CISA Secure Software Development Attestation Form in March 2024). SSDF is not a checklist you complete once — it's a set of 42 practices grouped into four categories that map to how software actually gets built: preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. Unlike SOC 2 or ISO 27001, SSDF doesn't certify a company; it certifies that specific development practices exist for specific products. That distinction is why procurement teams now ask vendors for SSDF attestation letters alongside SBOMs, and why security teams need tooling that produces the artifacts SSDF actually demands, not just a policy binder.
What Is the NIST SSDF?
The NIST SSDF is NIST Special Publication 800-218, a framework of 42 secure development practices published in final form on February 3, 2022. It was built by combining existing standards — including BSA's Framework for Secure Software, OWASP's SAMM, and NIST's own SP 800-160 — into one common vocabulary so agencies could ask vendors a single, comparable set of questions instead of a different framework per contract. Each practice carries a task-level identifier (for example, PW.4.4 covers reusing existing, well-secured software rather than duplicating functionality) so audits can point to a specific line item instead of a vague "secure coding" claim. NIST maintains it as a living document; SP 800-218A, released in June 2024, added SSDF practices specific to AI model development.
What Are the Four SSDF Practice Groups?
The four groups are Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). PO covers organizational readiness — things like defining security requirements and training developers (PO.2.1, PO.2.2). PS covers protecting code and build infrastructure from tampering, including storing all forms of code with tightly controlled access (PS.1.1) and provenance verification. PW is the largest group, with practices like PW.4.1 (verifying third-party components before use) and PW.7.1 (reviewing code for vulnerabilities before release), and it's where most of the SBOM, static analysis, and dependency-review requirements live. RV covers vulnerability response: PW.7's sibling group RV.1.1 requires identifying and confirming vulnerabilities on an ongoing basis, and RV.1.3 requires analyzing each vulnerability to determine root cause. Federal contractors are typically evaluated against subsets of all four groups depending on contract type.
Who Has to Comply With SSDF, and Since When?
Any organization selling software to the U.S. federal government has had to attest to SSDF compliance since June 11, 2023, per OMB M-22-18. That memo required agencies to obtain a self-attestation from software producers before using their products, covering software developed or modified after that date. CISA's standardized attestation form, finalized in March 2024, gave vendors 90 days after use of "critical software" (and 180 days for other software) to submit the form once an agency requested it. The requirement applies to any producer of software used by a federal agency — prime contractors and subcontractors alike — which is why defense and civilian suppliers as small as five-person dev shops have had to produce SSDF evidence, not just large primes like Lockheed Martin or Booz Allen.
What Evidence Does an SSDF Attestation Actually Require?
An SSDF attestation requires documented proof for specific practices, not a narrative description of your security culture. The CISA form asks vendors to affirm, among other things, that the software was developed in environments with separated production and build infrastructure (PS.3.1), that a Software Bill of Materials or equivalent is available (PW.4.4/PW.1.3), and that vulnerability disclosure and response processes exist (RV.1.1–RV.3.4). If a vendor can't self-attest, they must submit a Plan of Action and Milestones (POA&M) instead — effectively admitting a gap in writing to every agency customer. In practice, the hardest line items to prove are provenance (can you show a signed build chain from commit to artifact?) and vulnerability remediation timeliness (can you show, with timestamps, that a critical CVE was triaged and fixed within your stated SLA?) — both of which require tooling most teams didn't have before 2023.
How Is SSDF Different From SLSA or SOC 2?
SSDF, SLSA, and SOC 2 address different questions and are not interchangeable. SSDF (NIST SP 800-218) is a practice framework for how software is built and answers "did you follow secure development practices?" SLSA (Supply-chain Levels for Software Artifacts, now at v1.0 under the OpenSSF) is a build-integrity ladder with four levels and answers "can you prove the artifact wasn't tampered with between source and release?" SOC 2 is an auditor-attested report on an organization's controls over a 3-12 month observation period and answers "does this company operate consistent security controls?" A vendor can hold a clean SOC 2 Type II report and still fail an SSDF attestation if they can't produce an SBOM or show a documented vulnerability response process — the frameworks overlap in intent but not in required artifacts. Federal RFPs increasingly ask for SSDF attestation plus an SBOM plus SOC 2, which is why security teams are consolidating tooling rather than running three separate compliance projects.
How Safeguard Helps
Safeguard maps directly onto the SSDF practices that are hardest to evidence manually. Our SBOM generation and ingest pipeline satisfies PW.4.4 and the CISA attestation's SBOM requirement automatically, producing a component inventory on every build rather than a point-in-time snapshot. Reachability analysis addresses PW.7.1 and RV.1.1 by showing which flagged vulnerabilities are actually exploitable in your runtime call paths, so remediation work maps to real risk instead of a raw CVE count. Griffin AI, Safeguard's remediation engine, generates auto-fix PRs that resolve vulnerable dependencies with tested upgrade paths, giving you the timestamped remediation evidence RV.2.1 and RV.3.3 require for attestation and audit. Together, these turn SSDF from a quarterly documentation scramble into artifacts your pipeline produces continuously.