NIST SSDF v1.1
Secure Software Development Framework - Practices for integrating security into SDLC
This is a reference tool, not an authoritative source. For official documentation, visit csrc.nist.gov.
42 All
PO — Prepare the Organization (13 tasks)
PO.1.1Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.
PO.1.2Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.
PO.1.3Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. [Formerly PW.3.1]
PO.2.1Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC. Periodically review and maintain the defined roles and responsibilities, updating them as needed.
PO.2.2Provide role-based training for all personnel with responsibilities that contribute to secure development. Periodically review personnel proficiency and role-based training, and update the training as needed.
PO.2.3Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development-related roles and responsibilities.
PO.3.1Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.
PO.3.2Follow recommended security practices to deploy, operate, and maintain tools and toolchains.
PO.3.3Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.
PO.4.1Define criteria for software security checks and track throughout the SDLC.
PO.4.2Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.
PO.5.1Separate and protect each environment involved in software development.
PO.5.2Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.
PS — Protect the Software (4 tasks)
PS.1.1Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.
PS.2.1Make software integrity verification information available to software acquirers.
PS.3.1Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.
PS.3.2Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]).
PW — Produce Well-Secured Software (16 tasks)
PW.1.1Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software.
PW.1.2Track and maintain the software’s security requirements, risks, and design decisions.
PW.1.3Where appropriate, build in support for using standardized security features and services (e.g., enabling software to integrate with existing log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services. [Formerly PW.4.3]
PW.2.1Have 1) a qualified person (or people) who were not involved with the design and/or 2) automated processes instantiated in the toolchain review the software design to confirm and enforce that it meets all of the security requirements and satisfactorily addresses the identified risk information.
PW.4.1Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, open-source, and other third-party developers for use by the organization’s software.
PW.4.2Create and maintain well-secured software components in-house following SDLC processes to meet common internal software development needs that cannot be better met by third-party software components.
PW.4.4Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles.
PW.5.1Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.
PW.6.1Use compiler, interpreter, and build tools that offer features to improve executable security.
PW.6.2Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations.
PW.7.1Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization.
PW.7.2Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.
PW.8.1Determine whether executable code testing should be performed to find vulnerabilities not identified by previous reviews, analysis, or testing and, if so, which types of testing should be used.
PW.8.2Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.
PW.9.1Define a secure baseline by determining how to configure each setting that has an effect on security or a security-related setting so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services.
PW.9.2Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.
RV — Respond to Vulnerabilities (9 tasks)
RV.1.1Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.
RV.1.2Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities.
RV.1.3Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.
RV.2.1Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response.
RV.2.2Plan and implement risk responses for vulnerabilities.
RV.3.1Analyze identified vulnerabilities to determine their root causes.
RV.3.2Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently.
RV.3.3Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports.
RV.3.4Review the SDLC process, and update it if appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to the software or in new software that is created.