openssf/osps-baseline Control Catalog

Objective

Reduce the risk of account compromise or insider threats by requiring multi-factor authentication for collaborators modifying the project repository settings or accessing sensitive data.

Assessment requirements

1. When a user attempts to read or modify a sensitive resource in the project's authoritative repository, the system MUST require the user to complete a multi-factor authentication process.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Reduce the risk of unauthorized access to the project's repository by limiting the permissions granted to new collaborators.

Assessment requirements

1. When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Reduce the risk of accidental changes or deletion of the primary branch of the project's repository by preventing unintentional modification.

Assessment requirements

1. When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied.

   Applicability: maturity-1, maturity-2, maturity-3

2. When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Reduce the risk of unauthorized access to the project's build and release processes by limiting the permissions granted to steps within the CI/CD pipelines.

Assessment requirements

1. When a CI/CD task is executed with no permissions specified, the CI/CD system MUST default the task's permissions to the lowest permissions granted in the pipeline.

   Applicability: maturity-2, maturity-3

2. When a job is assigned permissions in a CI/CD pipeline, the source code or configuration MUST only assign the minimum privileges necessary for the corresponding activity.

   Applicability: maturity-3

Objective

Reduce the risk of code injection or other security vulnerabilities in the project's build and release pipelines by preventing untrusted input from accessing privileged resources.

Assessment requirements

1. When a CI/CD pipeline operates on untrusted metadata, those parameters MUST be sanitized and validated prior to use in the pipeline.

   Applicability: maturity-1, maturity-2, maturity-3

2. Retired in https://github.com/ossf/security-baseline/pull/443

   Applicability: maturity-1, maturity-2, maturity-3

3. When a CI/CD pipeline operates on untrusted code snapshots, it MUST prevent access to privileged CI/CD credentials and assets.

   Applicability: maturity-1, maturity-2, maturity-3

4. CI/CD pipelines which accept trusted collaborator input MUST sanitize and validate that input prior to use in the pipeline.

   Applicability: maturity-3

Objective

Ensure that each software asset produced by the project is uniquely identified, enabling users to track changes and updates to the project over time.

Assessment requirements

1. When an official release is created, that release MUST be assigned a unique version identifier.

   Applicability: maturity-2, maturity-3

2. When an official release is created, all assets within that release MUST be clearly associated with the release identifier or another unique identifier for the asset.

   Applicability: maturity-3

Objective

Protect the confidentiality and integrity of project source code during development, reducing the risk of eavesdropping or data tampering.

Assessment requirements

1. When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels.

   Applicability: maturity-1, maturity-2, maturity-3

2. When the project lists a URI as an official distribution channel, that channel MUST be protected from adversary-in-the-middle attacks using cryptographically authenticated channels.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Provide transparency and accountability for changes made to the project's software releases in such a way that users can understand the modifications and improvements included in each release.

Assessment requirements

1. When an official release is created, that release MUST contain a descriptive log of functional and security modifications.

   Applicability: maturity-2, maturity-3

Objective

Ensure that the project's build and release pipelines use standardized tools and processes to manage dependencies, reducing the risk of compatibility issues or security vulnerabilities in the software.

Assessment requirements

1. When a build and release pipeline ingests dependencies, it MUST use standardized tooling where available.

   Applicability: maturity-2, maturity-3

Objective

Ensure released software assets can be verified by users to ensure integrity of each asset when it is used.

Assessment requirements

1. When an official release is created, that release MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.

   Applicability: maturity-2, maturity-3

Objective

Ensure that data which can lead to security vulnerabilities or supply chain compromise is not disclosed, compromised, or misused.

Assessment requirements

1. The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system.

   Applicability: maturity-1

2. The project MUST define a policy for managing secrets and credentials used by the project. The policy should include guidelines for storing, accessing, and rotating secrets and credentials.

   Applicability: maturity-3

Objective

Ensure that users have a clear and comprehensive understanding of the project's current features in order to prevent damage from misuse or misconfiguration.

Assessment requirements

1. When the project has made a release, the project documentation MUST include user guides for all basic functionality.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Enable users and contributors to report defects or issues with the released software assets, facilitating communication and collaboration on defect fixes and improvements.

Assessment requirements

1. When the project has made a release, the project documentation MUST include a guide for reporting defects.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Enable users to verify the authenticity and integrity of the project's released software assets, reducing the risk of using tampered or unauthorized versions of the software.

Assessment requirements

1. When the project has made a release, the project documentation MUST contain instructions to verify the integrity and authenticity of the release assets.

   Applicability: maturity-3

2. When the project has made a release, the project documentation MUST contain instructions to verify the expected identity of the person or process authoring the software release.

   Applicability: maturity-3

Objective

Provide users with clear expectations regarding the project's support lifecycle in such a way that enables downstream consumers to ensure the continued functionality and security of their systems.

Assessment requirements

1. When the project has made a release, the project documentation MUST include a descriptive statement about the scope and duration of support for each release.

   Applicability: maturity-3

Objective

Communicate when the project maintainers will no longer fix defects or security vulnerabilities.

Assessment requirements

1. When the project has made a release, the project documentation MUST provide a descriptive statement when releases or versions will no longer receive security updates.

   Applicability: maturity-3

Objective

Provide information about how the project selects, obtains, and tracks third-party components that are required for the software to function.

Assessment requirements

1. When the project has made a release, the project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies.

   Applicability: maturity-2, maturity-3

Objective

Ensure that users have a clear and comprehensive instructions on how to build the software from source code.

Assessment requirements

1. The project documentation MUST include instructions on how to build the software, including required libraries, frameworks, SDKs, and dependencies.

   Applicability: maturity-2, maturity-3

Objective

Document project roles and responsibilities to help project participants, potential contributors, and downstream consumers understand who is working on the project and what areas of authority they may have.

Assessment requirements

1. While active, the project documentation MUST include a list of project members with access to sensitive resources.

   Applicability: maturity-2, maturity-3

2. While active, the project documentation MUST include descriptions of the roles and responsibilities for members of the project.

   Applicability: maturity-2, maturity-3

Objective

Encourage open communication and collaboration within the project community by enabling users to provide feedback and discuss proposed changes or usage challenges.

Assessment requirements

1. While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Provide guidance on how to participate in the project, outlining the steps required to submit changes or enhancements to the project's codebase.

Assessment requirements

1. While active, the project documentation MUST include an explanation of the contribution process.

   Applicability: maturity-1, maturity-2, maturity-3

2. While active, the project documentation MUST include a guide for code contributors that includes requirements for acceptable contributions.

   Applicability: maturity-2, maturity-3

Objective

Ensure that code contributors are vetted and reviewed before being granted elevated permissions to sensitive resources within the project, reducing the risk of unauthorized access or misuse.

Assessment requirements

1. While active, the project documentation MUST have a policy that code collaborators are reviewed prior to granting escalated permissions to sensitive resources.

   Applicability: maturity-3

Objective

Ensure that code contributors are aware of and acknowledge their legal responsibility for the contributions they make to the project, reducing the risk of intellectual property disputes against the project.

Assessment requirements

1. While active, the version control system MUST require all code contributors to assert that they are legally authorized to make the associated contributions on every commit.

   Applicability: maturity-2, maturity-3

Objective

Ensure that the project's source code is distributed under a recognized and legally enforceable open source software license, providing clarity on how the code can be used and shared by others.

Assessment requirements

1. While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.

   Applicability: maturity-1, maturity-2, maturity-3

2. While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Ensure that the project's source code and released software assets are distributed with the appropriate license terms, making it clear to users and contributors how each can be used and shared.

Assessment requirements

1. While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory.

   Applicability: maturity-1, maturity-2, maturity-3

2. While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Enable users to access and review the project's source code and history, promoting transparency and collaboration within the project community.

Assessment requirements

1. While active, the project's source code repository MUST be publicly readable at a static URL.

   Applicability: maturity-1, maturity-2, maturity-3

2. The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Provide transparency and accountability for the project's dependencies while enabling users and contributors to understand the software's direct dependencies.

Assessment requirements

1. When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies.

   Applicability: maturity-1, maturity-2, maturity-3

2. When the project has made a release, all compiled released software assets MUST be delivered with a software bill of materials.

   Applicability: maturity-3

Objective

Ensure that the project's approvers do not become accustomed to tolerating failing status checks, even if arbitrary, because it increases the risk of overlooking security vulnerabilities or defects identified by automated checks.

Assessment requirements

1. When a commit is made to the primary branch, any automated status checks for commits MUST pass or be manually bypassed.

   Applicability: maturity-2, maturity-3

Objective

Ensure that all codebases produced by the project are well documented and held to the same security standard.

Assessment requirements

1. Projects with multiple repositories MUST document a list of codebases that are part of the project.

   Applicability: maturity-1, maturity-2, maturity-3

2. When the project has made a release comprising multiple source code repositories, all subprojects MUST enforce security requirements that are as strict or stricter than the primary codebase.

   Applicability: maturity-3

Objective

Reduce the risk of including generated executable artifacts in the project's version control system, ensuring that only source code and necessary files are stored in the repository.

Assessment requirements

1. While active, the version control system MUST NOT contain generated executable artifacts.

   Applicability: maturity-1, maturity-2, maturity-3

2. While active, the version control system MUST NOT contain unreviewable binary artifacts.

   Applicability: maturity-1, maturity-2, maturity-3

Objective

Ensure that the project uses at least one automated test suite for the source code repository and clearly documents when and how tests are run.

Assessment requirements

1. Prior to a commit being accepted, the project's CI/CD pipelines MUST run at least one automated test suite to ensure the changes meet expectations.

   Applicability: maturity-2, maturity-3

2. While active, project's documentation MUST clearly document when and how tests are run.

   Applicability: maturity-3

3. While active, the project's documentation MUST include a policy that all major changes to the software produced by the project should add or update tests of the functionality in an automated test suite.

   Applicability: maturity-3

Objective

Ensure that the project's version control system requires at least one non-author human approval of changes before merging into the release or primary branch.

Assessment requirements

1. When a commit is made to the primary branch, the project's version control system MUST require at least one non-author human approval of the changes before merging.

   Applicability: maturity-3

Objective

Provide an overview of the project's design and architecture, illustrating the interactions and components of the system to help contributors and security reviewers understand the internal logic of the released software assets.

Assessment requirements

1. When the project has made a release, the project documentation MUST include design documentation demonstrating all actions and actors within the system.

   Applicability: maturity-2, maturity-3

Objective

Provide users and developers with an understanding of how to interact with the project's software and integrate it with other systems, enabling them to use the software effectively.

Assessment requirements

1. When the project has made a release, the project documentation MUST include descriptions of all external software interfaces of the released software assets.

   Applicability: maturity-2, maturity-3

Objective

Provide project maintainers an understanding of how the software can be misused or broken, enabling them to plan mitigations accordingly.

Assessment requirements

1. When the project has made a release, the project MUST perform a security assessment to understand the most likely and impactful potential security problems that could occur within the software.

   Applicability: maturity-2, maturity-3

2. When the project has made a release, the project MUST perform a threat modeling and attack surface analysis to understand and protect against attacks on critical code paths, functions, and interactions within the system.

   Applicability: maturity-3

Objective

Establish a process for reporting and addressing vulnerabilities in the project, ensuring that security issues are handled promptly and transparently.

Assessment requirements

1. While active, the project documentation MUST include a policy for coordinated vulnerability disclosure (CVD), with a clear timeframe for response.

   Applicability: maturity-2, maturity-3

Objective

Enable external parties, such as researchers, to easily understand who they should contact in the event that a vulnerability is found, and what process they should follow.

Assessment requirements

1. While active, the project documentation MUST contain security contacts.

   Applicability: maturity-1

Objective

Provide a means for reporting privately to the security contacts within the project so that security vulnerabilities are not be shared with the public until the project has been provided time to analyze and prepare remediations to protect users of the project.

Assessment requirements

1. While active, the project documentation MUST provide a means for private vulnerability reporting directly to the security contacts within the project.

   Applicability: maturity-2, maturity-3

Objective

Ensure that project end users have a well known mechanism to understand vulnerabilities found within the project.

Assessment requirements

1. While active, the project documentation MUST publicly publish data about discovered vulnerabilities.

   Applicability: maturity-2, maturity-3

2. While active, any vulnerabilities in the software components not affecting the project MUST be accounted for in a VEX document, augmenting the vulnerability report with non-exploitability details.

   Applicability: maturity-3

Objective

Identify and address defects and security weaknesses in the project's imported code early in the development process, reducing the risk of shipping insecure software.

Assessment requirements

1. While active, the project documentation MUST include a policy that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses.

   Applicability: maturity-3

2. While active, the project documentation MUST include a policy to address SCA violations prior to any release.

   Applicability: maturity-3

3. While active, all changes to the project's codebase MUST be automatically evaluated against a documented policy for malicious dependencies and known vulnerabilities in dependencies, then blocked in the event of violations, except when declared and suppressed as non-exploitable.

   Applicability: maturity-3

Objective

Identify and address defects and security weaknesses in the project's codebase early in the development process, reducing the risk of shipping insecure software.

Assessment requirements

1. While active, the project documentation MUST include a policy that defines a threshold for remediation of SAST findings.

   Applicability: maturity-3

2. While active, all changes to the project's codebase MUST be automatically evaluated against a documented policy for security weaknesses and blocked in the event of violations except when declared and suppressed as non-exploitable.

   Applicability: maturity-3