The Secure Software Development Framework is NIST’s set of recommended secure development practices. SP 800-218, SSDF version 1.1, was published in February 2022. This article originally discussed its draft; consult the NIST SSDF project for later revisions and guidance.

What software security practices does the SSDF include?

The framework covers preparation, protection of software, production of well-secured software, and response to vulnerabilities. It includes people and processes as well as technical work. Selecting a tool does not establish that the organization performs every practice.

SSDF practice areas

  • Prepare the Organization (PO): establish the people, processes, and technology needed for secure development.
  • Protect the Software (PS): protect software components from unauthorized access and tampering.
  • Produce Well-Secured Software (PW): build software with security requirements, analysis, testing, and review.
  • Respond to Vulnerabilities (RV): identify and address vulnerabilities and their causes.

Use the publication’s practices and tasks to determine what your organization needs to do. Its examples illustrate possible implementations; they are not a universal product checklist.

How is the SSDF different from SLSA?

SSDF covers a broad secure development program. SLSA addresses defined supply-chain assurance requirements, including build provenance and builder protections. Evidence used for one may support part of the other, but the requirements are not interchangeable. Installing an attestation tool does not confer a SLSA level or complete SSDF conformance.

What does it mean for an engineering team?

Choose a practice, identify the work that supports it, and retain evidence that a reviewer can inspect. A test record might identify the commit, test procedure, result, producer, and relevant artifact. A remediation record may need the original finding, the change, and a validation test.

The control owner still decides whether the evidence covers the requirement. A successful command or a signed report does not establish adequate test coverage.

How can TestifySec help?

CI/lock captures configured work on your compute or hosted infrastructure. The platform maps retained test evidence to configured technical requirements. Pushgate evaluates requirements at the Git push boundary, and the platform manages multiple gates.

Read the technical control workflow and the trust architecture. Federal procurement and attestation obligations depend on the applicable requirements; use the authoritative government guidance for your contract and service.