The Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities is a publication from the US National Institute of Standards and Technology (NIST).

It provides a framework for integrating security practices at the organizational level and throughout the software development life cycle (SDLC), beginning at the design phase. The goal is to reduce the number of vulnerabilities in released software and minimize the potential impact of exploitation. The framework defines high-level secure development practices and recommends specific activities for each.

The framework defines four high-level secure development practices: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV), along with recommended activities for each. The diagram below summarizes these activities by practice and maps them to stages of the software development life cycle (SDLC).

Originally published as a voluntary guide in 2020, the SSDF has since evolved into a key component of the U.S. government’s software security strategy. Over time, it has shifted from guidance to a required standard for federal agencies and their software suppliers, with a growing emphasis on verifiable compliance measures.

How Chainloop Helps You Track and Verify SSDF Compliance

In Chainloop, the SSDF is primarily presented as a self-assessment checklist, allowing you to upload supporting evidence manually. The official SSDF publication includes a companion spreadsheet with example implementations for each recommended activity. This guidance spreadsheet can help you assess your compliance with the SSDF.

We are actively developing new automated policies to assist in evaluating SSDF compliance within Chainloop. If you are interested in early access to new functionalities, please contact us.

Additionally Chainloop maps vulnerability management best practices to SSDF Respond to Vulnerabilities (RV) recommended activities. Our expanded manual evidence and automated policies verify that your vulnerability management process follows industry-recommended practices that support compliance with the SSDF:

  • Identify all components included in your software: an SBOM is present and includes the generally adopted minimum elements recommended by the US National Telecommunications and Information Administration.
  • Implement a vulnerability reporting mechanism to enable users and researchers to report issues.
  • Perform regular vulnerability scanning to detect known issues across all software components: an SCA scan is performed daily.
  • Remediate vulnerabilities based on risk: Critical vulnerabilities are fixed within 2 days.
  • Maintain a coordinated vulnerability disclosure (CVD) policy, outlining how reports are handled and timelines for response.
  • Provide a mechanism for timely distribution of security updates and transparent disclosure of relevant vulnerability information to users.

PREPARE THE ORGANIZATION (PS)

PO.1: Define Security Requirements for Software Development

Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations). List of requirements for manual confirmation to ensure that cybersecurity is embedded into the design and development processes.

RequirementDescriptionChainloop Policy
ssdf-po-1-1Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.Self-assessment
ssdf-po-1-2Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.Self-assessment
ssdf-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]Self-assessment

PO.2: 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.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-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.Self-assessment
ssdf-po-2-3Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development-related roles and responsibilities.Self-assessment

PO.4: 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.

RequirementDescriptionChainloop Policy
ssdf-po-4-1Define criteria for software security checks and track throughout the SDLC.Self-assessment
ssdf-po-4-2Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.Self-assessment

PO.5: Implement and Maintain Secure Environments for Software Development

Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

RequirementDescriptionChainloop Policy
ssdf-po-5-1Separate and protect each environment involved in software development.Self-assessment
ssdf-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.Self-assessment

PROTECT THE SOFTWARE (PS)

PS.1: Protect All Forms of Code from Unauthorized Access and Tampering

Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment

PS.2: Provide a Mechanism for Verifying Software Release Integrity

Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.

RequirementDescriptionChainloop Policy
ssdf-ps-2-1Make software integrity verification information available to software acquirers.Self-assessment

PS.3: Archive and Protect Each Software Release

Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.

RequirementDescriptionChainloop Policy
ssdf-ps-3-1Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.Self-assessment
ssdf-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(1)])

(1)Identify all components included in your software: an SBOM is present and includes the generally adopted minimum elements recommended by the US National Telecommunications and Information Administration.
sbom-present (automatic), sbom-ntia (automatic), other-provenance-exists (manual evidence), other-provenance-evidence (optional manual evidence)

PRODUCE WELL-SECURED SOFTWARE (PW)

PW.1: 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; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-pw-1-2Track and maintain the software’s security requirements, risks, and design decisions.Self-assessment
ssdf-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]Self-assessment

PW.2: Review the Software Design to Verify Compliance with Security Requirements and Risk Information

Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment

PW.4: Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality

Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-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.Self-assessment
ssdf-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.Self-assessment

PW.5: 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.

RequirementDescriptionChainloop Policy
ssdf-pw-5-1Follow all secure coding practices that are appropriate to the development languages and environment to meet the organization’s requirements.Self-assessment

PW.6: 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.

RequirementDescriptionChainloop Policy
ssdf-pw-6-1Use compiler, interpreter, and build tools that offer features to improve executable security.Self-assessment
ssdf-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.Self-assessment

PW.7: Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

Help identify vulnerabilities so that they can be corrected before the software is released 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 of code that an organization deems human-readable.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-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.Self-assessment

PW.8: Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-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.Self-assessment

PW.9: 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.

RequirementDescriptionChainloop Policy
ssdf-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.Self-assessment
ssdf-pw-9-2Implement the default settings (or groups of default settings, if applicable), and document each setting for software administrators.Self-assessment

RESPOND TO VULNERABILITIES (RV)

RV.1: Identify and Confirm Vulnerabilities on an Ongoing Basis

Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.

  • RV.1.1: Gather 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.2: Review, analyze, and/or test the software’s code to identify or confirm the presence of previously undetected vulnerabilities.
  • RV.1.3: Have a policy that addresses vulnerability disclosure and remediation, and implement the roles, responsibilities, and processes needed to support that policy.
RequirementDescriptionChainloop Policy
ssdf-rv-1-1Implement a vulnerability reporting mechanism to enable users and researchers to report issues.reporting-mechanism-exists (manual evidence), security-contact-exists (manual evidence), security-response-team-exists (manual evidence), security-response-sla-exists (manual evidence), reporting-mechanism-public (manual evidence), security-feeds-monitoring-exists (optional manual evidence), reporting-mechanism-evidence (optional manual evidence)
ssdf-rv-1-2Perform regular vulnerability scanning to detect known issues across all software components: an SCA scan is performed daily.vulnerability-scan-present(periodicity:daily) (automatic)
ssdf-rv-1-3Maintain a coordinated vulnerability disclosure (CVD) policy, outlining how reports are handled and timelines for response.cvd-process-exists (manual evidence), cvd-triggering-communicated (manual evidence), cvd-team-defined (manual evidence), cvd-response-guidance (manual evidence), cvd-communication-guidance (manual evidence), cvd-vendors-coordination (manual evidence), cvd-evidence (optional manual evidence), cvd-triggering-defined (manual evidence), cvd-rollout-guidance (manual evidence)

RV.2: Assess, Prioritize, and Remediate Vulnerabilities

Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.

  • RV.2.1: Analyze each vulnerability to gather sufficient information about risk to plan its remediation or other risk response.
  • RV.2.2: Plan and implement risk responses for vulnerabilities.
RequirementDescriptionChainloop Policy
ssdf-rv-2-1Remediate vulnerabilities based on risk: Critical vulnerabilities are fixed within 2 days.vulnerabilities(severity:critical SLA:48h) (automatic)
ssdf-rv-2-2Remediate vulnerabilities based on risk: Critical vulnerabilities are fixed within 2 days.

Provide a mechanism for timely distribution of security updates and transparent disclosure of relevant vulnerability information to users.
vulnerabilities(severity:critical SLA:48h) (automatic), updates-distribution-policy-exists (manual evidence), updates-distribution-information (manual evidence), update-distribution-automatic (optional manual evidence), updates-distribution-public (manual evidence), updates-distribution-timeline (manual evidence), updates-distribution-free (manual evidence), updates-distribution-evidence (optional manual evidence), disclosure-policy-exists (manual evidence), security-advisories-process (manual evidence), security-advisories-public (manual evidence), security-advisory-details (manual evidence), disclosure-timeline-exception (manual evidence), disclosure-policy-evidence (optional manual evidence)

RV.3: Analyze Vulnerabilities to Identify Their Root Causes

Help reduce the frequency of vulnerabilities in the future.

RequirementDescriptionChainloop Policy
ssdf-rv-3-1Analyze identified vulnerabilities to determine their root causes.Self-assessment
ssdf-rv-3-2Analyze the root causes over time to identify patterns, such as a particular secure coding practice not being followed consistently.Self-assessment
ssdf-rv-3-3Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, and proactively fix them rather than waiting for external reports.Self-assessment
ssdf-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.Self-assessment