Open Source Project Security Baseline checklist#
The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to its maturity level. It is maintained by the OpenSSF Security Baseline SIG according to the project governance documentation.
OSPS Baseline checklist, version: 2025-10-10
Tip
Please check for the latest version of the OSPS Baseline. If you spot a newer release, please raise an issue so we can update the version hosted here.
Level 1#
[ ] OSPS-AC-01.01: 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.
[ ] OSPS-AC-02.01: 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.
[ ] OSPS-AC-03.01: When a direct commit is attempted on the project’s primary branch, an enforcement mechanism MUST prevent the change from being applied.
[ ] OSPS-AC-03.02: 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.
[ ] OSPS-BR-01.01: When a CI/CD pipeline accepts an input parameter, that parameter MUST be sanitized and validated prior to use in the pipeline.
[ ] OSPS-BR-01.02: When a CI/CD pipeline uses a branch name in its functionality, that name value MUST be sanitized and validated prior to use in the pipeline.
[ ] OSPS-BR-03.01: When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels.
[ ] OSPS-BR-03.02: When the project lists a URI as an official distribution channel, that URI MUST be exclusively delivered using encrypted channels.
[ ] OSPS-BR-07.01: The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system.
[ ] OSPS-DO-01.01: When the project has made a release, the project documentation MUST include user guides for all basic functionality.
[ ] OSPS-DO-02.01: When the project has made a release, the project documentation MUST include a guide for reporting defects.
[ ] OSPS-GV-02.01: While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.
[ ] OSPS-GV-03.01: While active, the project documentation MUST include an explanation of the contribution process.
[ ] OSPS-LE-02.01: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
[ ] OSPS-LE-02.02: While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
[ ] OSPS-LE-03.01: While active, the license for the source code MUST be maintained in the corresponding repository’s LICENSE file, COPYING file, or LICENSE/ directory.
[ ] OSPS-LE-03.02: 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.
[ ] OSPS-QA-01.01: While active, the project’s source code repository MUST be publicly readable at a static URL.
[ ] OSPS-QA-01.02: The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made.
[ ] OSPS-QA-02.01: When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies.
[ ] OSPS-QA-04.01: While active, the project documentation MUST contain a list of any codebases that are considered subprojects.
[ ] OSPS-QA-05.01: While active, the version control system MUST NOT contain generated executable artifacts.
[ ] OSPS-QA-05.02: While active, the version control system MUST NOT contain unreviewable binary artifacts.
[ ] OSPS-VM-02.01: While active, the project documentation MUST contain security contacts.
Level 2#
[ ] OSPS-AC-04.01: 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.
[ ] OSPS-BR-02.01: When an official release is created, that release MUST be assigned a unique version identifier.
[ ] OSPS-BR-04.01: When an official release is created, that release MUST contain a descriptive log of functional and security modifications.
[ ] OSPS-BR-05.01: When a build and release pipeline ingests dependencies, it MUST use standardized tooling where available.
[ ] OSPS-BR-06.01: When an official release is created, that release MUST be signed or accounted for in a signed manifest including each asset’s cryptographic hashes.
[ ] OSPS-DO-06.01: When the project has made a release, the project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies.
[ ] OSPS-GV-01.01: While active, the project documentation MUST include a list of project members with access to sensitive resources.
[ ] OSPS-GV-01.02: While active, the project documentation MUST include descriptions of the roles and responsibilities for members of the project.
[ ] OSPS-GV-03.02: While active, the project documentation MUST include a guide for code contributors that includes requirements for acceptable contributions.
[ ] OSPS-LE-01.01: 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.
[ ] OSPS-QA-03.01: When a commit is made to the primary branch, any automated status checks for commits MUST pass or be manually bypassed.
[ ] OSPS-QA-06.01: 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.
[ ] OSPS-SA-01.01: When the project has made a release, the project documentation MUST include design documentation demonstrating all actions and actors within the system.
[ ] OSPS-SA-02.01: When the project has made a release, the project documentation MUST include descriptions of all external software interfaces of the released software assets.
[ ] OSPS-SA-03.01: 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.
[ ] OSPS-VM-01.01: While active, the project documentation MUST include a policy for coordinated vulnerability disclosure (CVD), with a clear timeframe for response.
[ ] OSPS-VM-03.01: While active, the project documentation MUST provide a means for private vulnerability reporting directly to the security contacts within the project.
[ ] OSPS-VM-04.01: While active, the project documentation MUST publicly publish data about discovered vulnerabilities.
Level 3#
[ ] OSPS-AC-04.02: 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.
[ ] OSPS-BR-02.02: 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.
[ ] OSPS-BR-07.02: 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.
[ ] OSPS-DO-03.01: When the project has made a release, the project documentation MUST contain instructions to verify the integrity and authenticity of the release assets.
[ ] OSPS-DO-03.02: 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.
[ ] OSPS-DO-04.01: 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.
[ ] OSPS-DO-05.01: 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.
[ ] OSPS-GV-04.01: While active, the project documentation MUST have a policy that code collaborators are reviewed prior to granting escalated permissions to sensitive resources.
[ ] OSPS-QA-02.02: When the project has made a release, all compiled released software assets MUST be delivered with a software bill of materials.
[ ] OSPS-QA-04.02: 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.
[ ] OSPS-QA-06.02: While active, project’s documentation MUST clearly document when and how tests are run.
[ ] OSPS-QA-06.03: 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.
[ ] OSPS-QA-07.01: 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.
[ ] OSPS-SA-03.02: 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.
[ ] OSPS-VM-04.02: 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.
[ ] OSPS-VM-05.01: While active, the project documentation MUST include a policy that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses.
[ ] OSPS-VM-05.02: While active, the project documentation MUST include a policy to address SCA violations prior to any release.
[ ] OSPS-VM-05.03: 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.
[ ] OSPS-VM-06.01: While active, the project documentation MUST include a policy that defines a threshold for remediation of SAST findings.
[ ] OSPS-VM-06.02: 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.
Attribution: Input used from from OpenSSF Baseline project by OpenSSF, used under Apache License,Version 2.0, January 2004.