NIST SP 800-218 (Secure Software Development Framework — SSDF)
The NIST framework that organizes secure software development practices into four groups, now required for all software sold to the US federal government.
NIST Special Publication 800-218, "Secure Software Development Framework (SSDF) Version 1.1," published February 2022, consolidates secure software development practices from multiple sources (ISO/IEC 27034, BSIMM, OWASP SAMM, SAFECode) into a common vocabulary organized into four practice groups: Prepare the Organization (PO) — establishing security requirements and tooling; Protect the Software (PS) — protecting all components of the software from tampering and unauthorized access; Produce Well-Secured Software (PW) — producing software with minimal security vulnerabilities; and Respond to Vulnerabilities (RV) — identifying residual vulnerabilities and responding appropriately. Each practice contains specific tasks and example implementation approaches. OMB M-22-18 requires all software producers selling to the US government to attest to SSDF conformance.
Engineering implementation of the SSDF maps directly to DevSecOps pipeline controls. PW.4 (Reuse existing, well-secured software) requires SCA/SBOM tooling to be integrated into the build pipeline, blocking builds that include components with CVSS ≥7.0 unmitigated vulnerabilities. PW.7 (Review the software for security vulnerabilities) requires SAST tools (Semgrep, SonarQube, Checkmarx) with findings reviewed before merge to main. PW.8 (Test executable code to identify vulnerabilities) requires DAST tools (OWASP ZAP, Burp Suite) integrated into staging environment test gates. PS.1 (Protect all forms of code from unauthorized access and tampering) requires signed commits, artifact signing (Sigstore/cosign), and container image signing with policy enforcement in the deployment pipeline. The SSDF does not mandate specific tools — it mandates outcomes and requires documentation of how each practice is implemented.
The OMB M-22-18 attestation requirement has direct procurement implications. Software producers must complete a standard self-attestation form (released by CISA in April 2023) affirming conformance with all SSDF practices, or provide a third-party assessment by an accredited organization. For "critical software" (as categorized by NIST guidance), attestation must include an SBOM (SPDX or CycloneDX format) and may require artifact evidence. Federal agencies are required to obtain these attestations before acquiring new software and before renewing existing software contracts. Agencies may not use software from producers who fail to provide a complete attestation. This creates a supply chain security gate: any software company with federal revenue must have a documented, demonstrable SSDF-conformant development program.
We implement SSDF-conformant development programs by integrating security controls at each pipeline stage: signed commits and branch protection policies for PS controls, SAST/DAST/SCA tooling with policy gates for PW controls, automated vulnerability triage workflows for RV controls, and developer security training programs for PO controls. We produce the documentation artifacts required for CISA self-attestation forms and support third-party assessments.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.