1. 1. Prepare the Organisation (PO)
   1. PO.1: Define Security Requirements for Software Development
      1. PO.1.1: Identify all applicable security requirements for the organization’s general software development, and maintain the requirements over time.
   2. PO.2: Implement Roles and Responsibilities
      1. PO.2.1: Create new roles and alter responsibilities for existing roles to encompass all parts of the SSDF. Periodically review the defined roles and responsibilities, and update them as needed.
      2. PO.2.2: Provide role-specific training for all personnel with responsibilities that contribute to secure development. Periodically review role-specific training and update it as needed.
      3. PO.2.3: Obtain upper management commitment to secure development, and convey that commitment to all with SSDF-related roles and responsibilities.
   3. PO.3: Implement a Supporting Toolchain
      1. PO.3.1: Specify which tools or tool types are to be included in each toolchain and which are mandatory, as well as how the toolchain components are to be integrated with each other.
      2. PO.3.2: Following sound security practices, deploy and configure tools, integrate them within the toolchain, and maintain the individual tools and the toolchain as a whole.
      3. PO.3.3: Configure tools to collect evidence and artifacts of their support of the secure software development practices.
   4. PO.4: Define Criteria for Software Security Checks
      1. PO.4.1: Define criteria for software security checks throughout the SDLC.
      2. PO.4.2: Implement processes, mechanisms, etc. to gather the necessary information in support of the criteria.
2. 2. Protect the Software (PS):
   1. PS.1: Protect All Forms of Code from Unauthorised Access and Tampering
      1. PS.1.1: Store all forms of code, including source code and executable code, based on the principle of least privilege so that only authorized personnel have the necessary forms of access.
   2. PS.2: Provide a Mechanism for Verifying Software Release Integrity
      1. PS.2.1: Make verification information available to software consumers.
   3. PS.3: Archive and Protect Each Software Release
      1. PS.3.1: Securely archive a copy of each release and all of its components (e.g., code, package files, third-party libraries, documentation), and release integrity verification information.
3. 3. Produce Well-Secured Software (PW)
   1. PW1: Design Software to Meet Security Requirements and Mitigate Security Risks
      1. PW.1.1: Use forms of risk modeling, such as threat modeling, attack modeling, or attack surface mapping, to help assess the security risk for the software.
   2. PW2: Review the Software Design to Verify Compliance with Security Requirements and Risk Information
      1. PW.2.1: Have a qualified person who was not involved with the software design review it to confirm that it meets all of the security requirements and satisfactorily addresses the identified risk information.
   3. PW3: Verify Third-Party Software Complies with Security Requirements
      1. PW.3.1: Communicate requirements to third parties who may provide software modules and services to the organization for reuse by the organization’s own software.
      2. PW.3.2: Use appropriate means to verify that commercial, open source, and all other third-party software modules and services comply with the requirements.
   4. PW4: Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality
      1. PW.4.1: Acquire well-secured components (e.g., software libraries, modules, middleware, frameworks) from third parties for use by the organization’s software.
      2. PW.4.2: Create 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
      3. PW.4.3: Where appropriate, build in support for using standardized security features and services (e.g., integrating with log management, identity management, access control, and vulnerability management systems) instead of creating proprietary implementations of security features and services.
   5. PW5: Create Source Code Adhering to Secure Coding Practices
      1. PW.5.1: Follow all secure coding practices that are appropriate to the development languages and environment
      2. PW.5.2: Have the developer review their own humanreadable code, analyze their own human-readable code, and/or test their own executable code to complement (not replace) code review, analysis, and/or testing performed by others
   6. PW6: Configure the Compilation and Build Processes to Improve Executable Security
      1. PW.6.1: Use compiler and build tools that offer features to improve executable security.
      2. PW.6.2: Determine which compiler and build tool features should be used and how each should be configured, then implement the approved configuration for compilation and build tools, processes, etc.
   7. PW7: Review and/or Analyse Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements
      1. PW.7.1: Determine whether code review (i.e., a person directly looks at the code to find issues) and/or code analysis (i.e., tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used.
      2. PW.7.2: Perform the code review and/or code analysis based on the organisation’s secure coding standards, and document and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system.
   8. PW8: Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements
      1. PW.8.1: Determine if executable code testing should be performed and, if so, which types should be used.
      2. PW.8.2: Design the tests, perform the testing, and document the results.
   9. PW9: Configure the Software to Have Secure Settings by Default
      1. PW.9.1: Determine how to configure each setting that has an effect on security so that the default settings are secure and do not weaken the security functions provided by the platform, network infrastructure, or services.
      2. PW.9.2: Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.
4. 4. Respond to Vulnerabilities (RV)
   1. RV.1: Identify and Confirm Vulnerabilities on an Ongoing Basis
      1. RV.1.1: Gather information from consumers and public sources on potential vulnerabilities in the software and any third-party components that the software uses, and investigate all credible reports.
      2. RV.1.2: Review, analyse, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities.
      3. RV.1.3: Have a team and process in place to handle the responses to vulnerability reports and incidents.
   2. RV2: Assess, Prioritise, and Remediate Vulnerabilities
      1. RV.2.1: Analyse each vulnerability to gather sufficient information to plan its remediation.
      2. RV.2.2: Develop and implement a remediation plan for each vulnerability
   3. RV3: Analyse Vulnerabilities to Identify Their Root Causes
      1. RV.3.1: Analyse all identified vulnerabilities to determine the root cause of each vulnerability.
      2. RV.3.2: Analyse the root causes over time to identify patterns, such as when a particular secure coding practice is not being followed consistently.
      3. RV.3.3: Review the software for other instances of the reported problem and proactively fix them rather than waiting for external reports.
      4. RV.3.4: Review the SDLC process, and update it as appropriate to prevent (or reduce the likelihood of) the root cause recurring in updates to this software or in new software that is created.