Skip to main content
SSDF And How It Impacts Your CSO-KAS

SSDF and How it Impacts your CSO-KAS

The Basics

On May 12, 2021, the Executive Branch of the Federal Government issued Executive Order (EO) 14028 in an attempt to improve the nation’s overall cybersecurity. Section 4(e) of the order states the following:

“Within 90 days of publication of the preliminary guidelines pursuant to subsection (c) of this section, the Secretary of Commerce acting through the Director of NIST, in consultation with the heads of such agencies as the Director of NIST deems appropriate, shall issue guidance identifying practices that enhance the security of the software supply chain. Such guidance may incorporate the guidelines published pursuant to subsections (c) and (i) of this section.”

This prompted the National Institute of Standards and Technology (NIST) to develop NIST Special Publication (SP) 800-218, titled “Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.” The SSDF is a collection of recommended practices that enable cloud service providers (CSF) and other software developers to reduce their information security risks by lowering the number of vulnerabilities in their software and minimizing the possible impact of exploiting vulnerabilities that exist in their software.

The SSDF provides a systematic approach to managing risk that is tailored to an organization's unique needs and circumstances. Within the SSDF, there are practices organized into four (4) groups. Those groups are as follows:

  • Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.
  • Protect the Software (PS): Protect all components of the organization’s software from tampering and unauthorized access.
  • Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
  • Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

For many FedRAMP-authorized CSPs, the above groups could be thought of as control families for software development. Each group has different practices which could be regarded as individual controls in FedRAMP baselines. The elements of each group are outlined below:

  • Practice: The name of the practice and a unique identifier, followed by a brief explanation of what the practice is and why it is beneficial.
  • Task: An action that may be needed to perform a practice.
  • Notional Implementation Example: A notional example of types of tools, processes, or other methods that could be used to help implement a task. No examples or combination of examples are required, and the stated examples are not the only feasible options.
  • Reference: A pointer to an established secure development practice document and its mappings to a particular task.

Here is an example of a task, PO.1.1, from practice PO.1 in SSDF 1.1’s PO group:

Here is an example of a task, PO.1.1, from practice PO.1 in SSDF 1.1’s PO group:

Implementing the SSDF enables CSPs to reduce the likelihood and severity of vulnerabilities in their software that could lead to data breaches, system compromises, and other incidents. By identifying and addressing security risks earlier in the development process, CSPs can reduce the costs associated with fixing security issues later in the development lifecycle or after deployment. Improving the security and reliability of the CSP’s services also leads to increased customer satisfaction and loyalty. By implementing the SSDF, CSPs can demonstrate compliance with these regulations, potentially avoiding costly fines and legal issues associated with non-compliance.

Additionally, a federal agency may require evidence of conformity with the SSDF to comply with a “Software Bill of Materials”. Moreover, the adoption of the SSDF can aid CSPs in conforming to regulatory standards concerning data security and privacy. Regulations such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA) require organizations to implement security controls and practices to protect sensitive data.

On September 14, 2022, OMB Memorandum M-22-18 was issued, which directs all federal agencies leveraging external providers to ensure that those providers follow EO 14028 and the SSDF for their software development. As a result, federal agencies have started to require CSPs to either self-attest or have their Third-Party Assessment Organization (3PAO) audit the practices in the SSDF against their Software Development Lifecycle practices. In the event a CSP is unable to conform to a specified practice in the SSDF, a Plan of Actions and Milestones (POA&M) entry should be made to track the risk associated with the missed practice.

Partnering with an outside auditor and/or consultant to assist with the implementation of the SSDF practices could be beneficial, as consultants can aid organizations in developing a comprehensive and effective risk management program that is aligned with their business objectives and risk appetite.

If you have any questions or need assistance in implementing the SSDF, contact us at!


NIST CSRC Secure Software Development Framework

NIST SP 800-218 Secure Software Development Framework (SSDF) Version 1.1

Software Cybersecurity for Producers and Purchasers

Executive Order on Improving the Nation's Cybersecurity

Memorandum for the Heads of Executive Departments and Agencies



Mike Strohecker 
Karen Scarfone