NIST SSDF 1.1: A Brief Overview of the Final Version

The 2021 Executive Order on strengthening the nation’s cybersecurity prompted NIST to create documents on secure software development practices. The NIST SSDF 1.1, the latest iteration of this framework, is nearing completion. This framework brings best practices and a common language to help foster accessible communication of security principles. 

The NIST SSDF version 1.1 is a core set of high-level software development practices that organizations can integrate into the SDLC to maximize application security. The purpose of this guidance is to help organizations reduce their number of escaped vulnerabilities, reduce the blast radius of breaches that may occur, and optimize the software development processes to minimize recurrences of these vulnerabilities. This cybersecurity framework also provides a shared vocabulary for software acquirers and software suppliers to improve communication of software security.

NIST SSDF 1.1 Practices

The NIST SSDF version 1.1 is the final release of this framework’s fundamental practices. These practices fall into four (4) categories. We break each of these practices down in a straightforward, easy-to-understand way that directly benefits your organization.

Prepare the Organization (PO)

• Define Security Requirements for Software Development – Ensure that security requirements for software development are known at all times so that developers can take them into account throughout the SDLC. Development teams can minimize duplication of effort because the requirements information can be collected once and shared.
• Implement Roles and Responsibilities – Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.
• Implement Toolchains that Prioritize Security – Using automation reduces human effort. Mitigating human error as a factor improves security practices throughout the SDLC. Utilizing automation improves accuracy, reproducibility, usability, and comprehensiveness of security. This automation provides a way to document and demonstrate the use of these practices. Teams may use toolchains and tools at different levels of the organization, such as organization-wide or project-specific. They may address a particular part of the SDLC, such as a build pipeline.
• Define and Use Criteria for Software Security Checks – Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development. Such measures may include achieving a certain level of SLSA.
  
• Implement and Maintain Secure Environments for Software Development – Strongly protect all components of the environments for software development from internal and external threats. Organizations should take steps to mitigate the risk of compromise to the development environment or the software being developed or maintained within; one such measure is adhering to the principle of least privilege. Examples of environments for software development include development, build, test, and distribution environments.

Protect Software (PS)

• Protect All Forms of Code from Unauthorized Access and Tampering – Help prevent unauthorized changes to code, both accidental and intentional, which could circumvent or negate the intended security characteristics of the software. For private or proprietary code not intended to be publicly accessible, this helps prevent software theft and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.
• Provide a Mechanism for Verifying Software Release Integrity – Help software acquirers ensure that the software they acquire is legitimate and code tampering has not occurred.
• Archive and Protect Each Software Release – Preserve software releases to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

Produce Well-Secured Software (PW)

• Design Software to Meet Security Requirements and Mitigate Security Risks – Identify and evaluate the security requirements for the software. Determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks. Justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design is critical for improving software security and also helps improve development efficiency.
• Review the Software Design to Verify Compliance with Security Requirements and Risk Information – Help ensure that the software meets the security requirements and adequately addresses the identified risk information. Creating a software bill of materials helps audit each included component for risk information.
• Reusing Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality – Reusing software components lowers software development costs, increases software development velocity, and decreases the likelihood of introducing additional security vulnerabilities into the software by reusing its software modules and services that have already had their security posture checked. Minimizing exposures is particularly important for software that implements security functionality, such as cryptographic modules and protocols.
• Create Source Code by Adhering to Secure Coding Practices – Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
• Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security – Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.
• Review and Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements – Help identify vulnerabilities so development teams can correct them before releasing the software to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form that an organization deems human-readable.
• Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements – Help identify vulnerabilities so that developers can correct them before releasing the software to prevent exploitation. Executable code includes binaries, directly executed bytecode and source code, and any other form that an organization deems executable.
• Configure Software to Have Secure Settings by Default – Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

Respond to Vulnerabilities (RV)

• Identify and Confirm Vulnerabilities on an Ongoing Basis – Help identify vulnerabilities quickly so that they can be remediated more rapidly by risk, reducing the window of opportunity for attackers.
  
• Assess, Prioritize, and Remediate Vulnerabilities – Help ensure that vulnerabilities are remediated per risk to reduce the window of opportunity for attackers.
  
• Analyze Vulnerabilities to Identify Their Root Causes – Help reduce the frequency of vulnerabilities in the future by iteratively refining the software development process. This process should help prevent the same exposure from reoccurring.

NIST SSDF 1.1 Common Language

Similar to the approach taken by the NIST Cybersecurity Framework, the NIST Secure Software Development Framework provides a common language to describe the aforementioned secure software development practices. Officially defining a shared lexicon helps foster clear understanding and communication between all organizational stakeholders.

Target Audience for the NIST SSDF 1.1

Organizational Stakeholders

Organizational stakeholders include business owners, software developers, project managers, tech leads, cybersecurity professionals, operations personnel, and platform engineers within an organization who need to communicate about secure software development.

Software Acquirers

Software acquirers, including federal agencies and other organizations, want to define required or desired characteristics for software in their acquisition processes to have higher-quality software.

Software Producers

Software producers are entities that want to integrate secure software development practices throughout their SDLCs, express their safe software practices to their customers, or define requirements to their suppliers.

Implementing the NIST SSDF 1.1 with Cycode

The NIST SSDF provides loose guidance for organizations but cannot help establish strong governance over these tools. Cycode’s platform can help organizations implement the NIST SSDF into their development cycle. Cycode may be implemented into developer workflows, boosting the security for each commit without slowing developer velocity. 

Cycode’s platform can support the requirements of the NIST SSDF, thus helping ensure security best practices for IaC code when using Terraform, Kubernetes, YAML, ARM, and CloudFormation. Cycode can help improve the security of your software supply chain by providing complete visibility into enterprise DevOps tools and infrastructure.

Want To Learn More?

A great place to start is with a free assessment of the security of your DevOps pipeline. 

Further Reading

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

https://cycode.com/nist-ssdf-explained/

https://cycode.com/overview-of-the-nist-cybersecurity-framework/