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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
RV.3: Analyze Vulnerabilities to Identify Their Root Causes
Help reduce the frequency of vulnerabilities in the future.