NIST is currently working on a Secure Software Development Framework (SSDF). The goal of the SSDF is to reduce the number of vulnerabilities in released software. The SSDF aims to meet these goals by providing a common vocabulary and set of controls around supply chain security. A draft of version 1.1 of the SSDF is available as NIST SP 800-218

What Software Security Practices Does the SSDF Include?

The SSDF is a set of development practices that CISOs can implement in the enterprise SDLC. These best practices align with the CNCF Software Supply Chain Best Practices Paper, SLSA, OWASP, SAFECode, and other best practices organizations and guidance.

• 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 continuously

SSDF Practice Areas

The SSDF is organized into four practice 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 of these practice areas 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.

SSDF Status

The SSDF is currently in draft status. On Monday, November 8th, NIST held a workshop on Executive Order 14028: Guidelines for Enhancing Software Supply Chain Security. In this workshop, NIST focused heavily on the current status of the SSDF and are seeking industry input. NIST SP 800-161 Revision 1 is recently published and is open for industry comment. 800-161 is the document that establishes the guidelines for secure software development. These guidelines are set to be published in their final form on February 6th, 2022.

How is the SSDF Different than SLSA?

The SSDF is a set of controls that are familiar to CISOs and industry regulators. SLSA, on the other hand, provides a software supply chain maturity model and rules that are familiar to developers. Your organization should use SLSA as a tool to meet SSDF supply chain-related SSDF controls.

What Does the SSDF Mean for My Organization?

If you are a CISO for a software company, you are likely to hear a lot more about secure development frameworks. If you are a highly regulated industry or sell software into a highly regulated industry, you should expect compliance requirements to start hitting contracting late in 2022.

In addition to regulation, there is additional legal pressure on software suppliers. A recent decision in a federal district court held a software producer, Blackbaud, Inc., responsible for flaws in their software, resulting in a data breach. As a result of legal pressure and increasing cyber attacks, cyber security insurance premiums are on the rise, with no clear ceiling. Frameworks such as SLSA and SSDF give insurance providers the tools they need to evaluate client risk.

Both SLSA and SSDF require attestation of the performance of software components. Therefore, automating the attestation and certification is essential to maintaining agility and speed in an evolving regulatory environment.

How can My Organization Prepare for Regulation around Software Supply Chains?

Regulatory burden, increased risk from cybercriminals, increasing complexity, and a tight labor market point to the need for new solutions around supply chain security. At TestifySec, we are working on the Witness platform. It gives the CISO a unified view of all enterprise software supply chains and security status. Witness enforces compliance without sacrificing developer flexibility or agility. Contact us to preview what is next.