On February 3, 2022, NIST published the final version of Special Publication 800-218, the Secure Software Development Framework (SSDF). This document translates the requirements of Executive Order 14028 into concrete practices that software producers must follow. If your organization develops software used by the US federal government, the SSDF is now your compliance baseline.
What Is the SSDF?
The SSDF is not a standard in the traditional sense — it does not prescribe specific tools or technologies. Instead, it defines a set of high-level practices organized into four groups, each representing a fundamental aspect of secure software development:
1. Prepare the Organization (PO)
Ensure that people, processes, and technology are prepared to perform secure software development.
Key practices:
- PO.1: Define security requirements for software development
- PO.2: Implement roles and responsibilities for security
- PO.3: Implement supporting toolchains
- PO.4: Define and use criteria for software security checks
- PO.5: Implement and maintain secure environments for software development
2. Protect the Software (PS)
Protect all components of the software from tampering and unauthorized access.
Key practices:
- PS.1: Protect all forms of code from unauthorized access and tampering
- PS.2: Provide a mechanism for verifying software release integrity
- PS.3: Archive and protect each software release
3. Produce Well-Secured Software (PW)
Produce well-secured software with minimal security vulnerabilities in its releases.
Key practices:
- PW.1: Design software to meet security requirements and mitigate risks
- PW.2: Review the software design to verify compliance with security requirements
- PW.4: Reuse existing well-secured software when feasible
- PW.5: Create source code by adhering to secure coding practices
- PW.6: Configure the compilation, interpreter, and build processes to improve executable security
- PW.7: Review and analyze human-readable code to identify vulnerabilities
- PW.8: Test executable code to identify vulnerabilities
- PW.9: Configure software to have secure settings by default
4. Respond to Vulnerabilities (RV)
Identify residual vulnerabilities in software releases and respond appropriately.
Key practices:
- RV.1: Identify and confirm vulnerabilities on an ongoing basis
- RV.2: Assess, prioritize, and remediate vulnerabilities
- RV.3: Analyze vulnerabilities to identify their root causes
SSDF and SBOMs
While the SSDF does not explicitly mandate SBOMs, several practices implicitly require the capabilities that SBOMs provide:
PW.4 (Reuse existing, well-secured software): You cannot evaluate the security of reused components without knowing what they are. An SBOM provides this inventory.
RV.1 (Identify and confirm vulnerabilities): Continuously monitoring for vulnerabilities in your dependencies requires a current component inventory — which is what an SBOM is.
PS.3 (Archive and protect each software release): Archiving the composition of each release (what components it contains) is an SBOM function.
In practice, organizations pursuing SSDF compliance will find that SBOM generation and management is a prerequisite for multiple practices.
Self-Attestation Requirements
In September 2022, OMB would issue Memorandum M-22-18, requiring software producers selling to the federal government to self-attest to SSDF compliance. This means:
- Your organization must document that it follows SSDF practices
- You must be able to provide this attestation to federal customers upon request
- For critical software, third-party assessment may be required
The attestation is not a one-time event. It is an ongoing commitment that your development practices align with the SSDF.
Mapping SSDF to Existing Frameworks
The SSDF intentionally maps to practices you may already be implementing under other frameworks:
| SSDF Practice | ISO 27001 | NIST CSF | OWASP SAMM | |---------------|-----------|----------|------------| | PO.1 (Security requirements) | A.14.1 | PR.IP-2 | Governance | | PS.1 (Protect code) | A.14.2 | PR.DS-6 | Implementation | | PW.7 (Code review) | A.14.2.8 | DE.CM-4 | Verification | | RV.1 (Identify vulnerabilities) | A.12.6 | ID.RA-1 | Operations |
If your organization already has a mature security program, you are likely already implementing many SSDF practices. The gap analysis should focus on areas specific to software development that general security frameworks may not cover in depth.
Practical Implementation Steps
Step 1: Gap Analysis
Map your current development practices against each SSDF practice. Identify where you have coverage, partial coverage, or gaps. Focus on the practices most relevant to your risk profile.
Step 2: Prioritize by Impact
Not all SSDF practices carry equal weight for your organization. Prioritize based on:
- Which practices address your highest risks?
- Which practices are required by your federal customers?
- Which practices are easiest to implement (quick wins)?
Step 3: Implement Tooling
Many SSDF practices benefit from or require tooling support:
- SBOM generation for component inventory (PW.4, RV.1)
- SAST/DAST scanners for vulnerability detection (PW.7, PW.8)
- Dependency scanners for known vulnerability identification (RV.1)
- Code signing for release integrity (PS.2)
- Access controls for source code protection (PS.1)
Step 4: Document Everything
Self-attestation requires evidence. Document your practices, tools, and processes. Maintain records of security reviews, vulnerability assessments, and remediation actions.
Step 5: Continuous Improvement
The SSDF is not a checkbox exercise. It expects ongoing improvement of security practices. Build feedback loops that incorporate lessons from vulnerability discoveries, incident response, and industry developments.
How Safeguard.sh Helps
Safeguard.sh directly supports multiple SSDF practices. Our platform automates SBOM generation (PW.4, PS.3), provides continuous vulnerability monitoring (RV.1), enables vulnerability prioritization and tracking (RV.2), and maintains an audit trail that supports self-attestation documentation. For organizations pursuing SSDF compliance, Safeguard.sh provides the technical foundation that makes attestation defensible rather than aspirational.