U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Secure Software Development Framework SSDF

Overview

Thanks for your help in shaping SSDF version 1.1! The public comment period for NIST Draft Special Publication (SP) 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities is now closed.  

NIST used findings from the June 2-3, 2021 virtual workshop in support of NIST's responsibilities under Executive Order 14028 to shape SSDF version 1.1.

Has your organization produced a set of secure software development practices? If you want to map those practices to the SSDF, please contact us at ssdf@nist.gov so we can introduce you to the National Online Informative References (OLIR) Program. You can contribute your mapping to our collection of informative references.

 

SSDF Value | SSDF Practices | NIST Plans | Contact Us

The Secure Software Development Framework (SSDF) is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode. Few software development life cycle (SDLC) models explicitly address software security in detail, so practices like those in the SSDF need to be added to and integrated with each SDLC implementation.

Key practices in the SSDF include:

  • Define criteria for software security checks
  • Protect all forms of code from unauthorized access and tampering by safeguarding the development, build, distribution, and update environments and following the least privilege principle
  • Provide a mechanism for verifying software release integrity by digitally signing the code throughout the software lifecycle
  • Design software to meet security requirements and mitigate security risks
  • Verify third-party software complies with security requirements
  • Configure the compilation and build processes to improve executable security
  • Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements
  • Test executable code to identify vulnerabilities and verify compliance with security requirements
  • Configure the software to have secure settings by default
  • Archive and protect each software release
  • Identify, analyze, and remediate vulnerabilities on a continuous basis

Back to Top

SSDF Value

Following the SSDF practices should help software producers reduce the number of vulnerabilities in released software, mitigate the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences. Also, because the SSDF provides a common vocabulary for secure software development, software consumers can use it to foster communications with suppliers in acquisition processes and other management activities.

Back to Top

SSDF Practices

The SSDF practices are organized into four groups:

  • Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for each individual project.
  • Protect the Software (PS): Protect all components of the software from tampering and unauthorized access.
  • Produce Well-Secured Software (PW): Produce well-secured software that has minimal security vulnerabilities in its releases.
  • Respond to Vulnerabilities (RV): Identify vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Each practice is defined with the following elements:

  • Practice: A brief statement of the practice, along with a unique identifier and an explanation of what the practice is and why it is beneficial.
  • Task: An individual action (or actions) needed to accomplish a practice.
  • Implementation Example: An example of a type of tool, process, or other method that could be used to implement this practice; not intended to imply that any example or combination of examples is required or that only the stated examples are feasible options.
  • Reference: An established secure development practice document and its mappings to a particular task.

The SSDF version 1.0 practices are defined in the NIST Cybersecurity White Paper, Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF).

Back to Top

NIST Plans

NIST is currently updating the SSDF to version 1.1. Changes that NIST has adopted include the following:

  • Development infrastructure: Added practices and tasks on securing development infrastructure
  • Threats against software development: Reviewed the current practices and tasks to determine what threats against software development they may not address adequately, then created new practices and tasks to fill those gaps
  • Preparation for secure software use: Expanded practices and tasks to emphasize the importance of preparing software for secure deployment, operation, and maintenance by the organizations acquiring the software
  • Reference updates: Updated all original SSDF references to the latest version, removed any references that have been retired by their sources, and added more SSDF references to include software for additional types of technologies

NIST used findings from the June 2-3, 2021 virtual workshop in support of NIST's responsibilities under Executive Order 14028 to shape SSDF version 1.1. The new SSDF draft also includes mappings from EO 14028 clauses to the SSDF practices and tasks that help address each clause. 

There has also been considerable interest from industry and others in NIST illustrating how the SSDF can be applied to particular SDLC models, especially transitioning DevOps implementations to DevSecOps. For more information on this, see the NIST DevSecOps project site.

Back to Top

Contact Us

Your comments and suggestions for the SSDF project are always welcome. Contact us at ssdf@nist.gov.

Back to Top

Created February 25, 2021, Updated November 10, 2021