Version: devel
Not for production use.
The Open Source Project Security (OSPS) Baseline is a set of security criteria that projects should meet to demonstrate a strong security posture. The controls are organized by maturity level and category. In the detailed subsections you will find the control, rationale, and details notes.
Where possible, we have added control mappings to external frameworks. These are not guaranteed to be 100% matches, but instead serve as references when working to meet the corresponding controls.
For more information on the project and to make contributions, visit the GitHub repo.
OSPS-AC-01.01: When a user attempts to access a sensitive resource in the project's version control system, 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-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 or additional repositories.
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.
OSPS-AC-04.01: When a CI/CD task is executed with no permissions specified, the project's version control system MUST default to the lowest available permissions for all activities 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.
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-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 contributors 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 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.
Access Control focuses on the mechanisms and policies that control access to the project's version control system and CI/CD pipelines. These controls help ensure that only authorized users can access sensitive data, modify repository settings, or execute build and release processes.
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.
Requirement: When a user attempts to access a sensitive resource in the project's version control system, the system MUST require the user to complete a multi-factor authentication process.
Recommendation: Enforce multi-factor authentication for the project's version control system, requiring collaborators to provide a second form of authentication when accessing sensitive data or modifying repository settings. Passkeys are acceptable for this control.
BPB: CC-G-1
CRA: 1.2d, 1.2e, 1.2f
SSDF: PO.3.2, PS.1, PS.2
CSF: PR.A-02, PR.A-05
OCRE: 486-813, 124-564, 347-352, 333-858, 152-725, 201-246
Reduce the risk of unauthorized access to the project's repository by limiting the permissions granted to new collaborators.
Requirement: 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.
Recommendation: Most public version control systems are configured in this manner. Ensure the project's version control system always assigns the lowest available permissions to collaborators by default when added, granting additional permissions only when necessary.
CRA: 1.2f
SSDF: PO.2, PO.3.2, PS.1, PS.2
CSF: PR.AA-02, PR.AA-05
OCRE: 486-813, 124-564, 802-056, 368-633, 152-725
Reduce the risk of accidental changes or deletion of the primary branch of the project's repository by preventing unintentional modification.
Requirement: When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied.
Recommendation: If the VCS is centralized, set branch protection on the primary branch in the project's VCS. Alternatively, use a decentralized approach, like the Linux kernel's, where changes are first proposed in another repository, and merging changes into the primary repository requires a specific separate act.
Requirement: 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.
Recommendation: Set branch protection on the primary branch in the project's version control system to prevent deletion.
CRA: 1.2f
SSDF: PO.3.2, PS.1, PS.2
CSF: PR.A-02, PR.A-05
OCRE: 486-813, 124-564, 152-725
ScCrd: Branch-Protection
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.
Requirement: When a CI/CD task is executed with no permissions specified, the project's version control system MUST default to the lowest available permissions for all activities in the pipeline.
Recommendation: Configure the project's settings to assign the lowest available permissions to new pipelines by default, granting additional permissions only when necessary for specific tasks.
Requirement: 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.
Recommendation: Configure the project's CI/CD pipelines to assign the lowest available permissions to users and services by default, elevating permissions only when necessary for specific tasks. In some version control systems, this may be possible at the organizational or repository level. If not, set permissions at the top level of the pipeline.
CRA: 1.2d, 1.2e, 1.2f
SSDF: PO.2, PO.3.2, PS.1, PS.2
CSF: PR.AA-02, PR.AA-05
OCRE: 486-813, 124-564, 347-507, 263-284, 123-124
SLSA: Producer - Choose an appropriate build platform, Build platform - Isolation strength - Isolated
Build and Release focuses on the processes and tools used to compile, package, and distribute the project's software. These controls help ensure that the project's build and release pipelines are secure, consistent, and reliable, reducing the risk of vulnerabilities or errors in the software distribution process.
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.
Requirement: When a CI/CD pipeline accepts an input parameter, that parameter MUST be sanitized and validated prior to use in the pipeline.
Recommendation:
Requirement: 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.
Recommendation:
CRA: 1.2f
SSDF: PO.3.2, PO.5.2, PS.1, PS.2
CSF: PR.AA-02
OCRE: 486-813, 124-564, 357-352
SLSA: Choose an appropriate build platform
Ensure that each software asset produced by the project is uniquely identified, enabling users to track changes and updates to the project over time.
Requirement: When an official release is created, that release MUST be assigned a unique version identifier.
Recommendation: Assign a unique version identifier to each release produced by the project, following a consistent naming convention or numbering scheme. Examples include SemVer, CalVer, or git commit id.
Requirement: 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.
Recommendation: Assign a unique version identifier to each software asset produced by the project, following a consistent naming convention or numbering scheme. Examples include SemVer, CalVer, or git commit id.
BPB: CC-B-5, CC-B-6, CC-B-7
CRA: 1.2f
SSDF: PO.3.2, PS.1, PS.2, PS.3
OCRE: 486-813, 124-564
SLSA: Follow a consistent build process, Provenance generation- Exists, Authentic
Protect the confidentiality and integrity of project source code during development, reducing the risk of eavesdropping or data tampering.
Requirement: When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels.
Recommendation: Configure the project's websites and version control systems to use encrypted channels such as SSH or HTTPS for data transmission. Ensure all tools and domains referenced in project documentation can only be accessed via encrypted channels.
Requirement: When the project lists a URI as an official distribution channel, that URI MUST be exclusively delivered using encrypted channels.
Recommendation: Configure the project's release pipeline to only fetch data from websites, API responses, and other services which use encrypted channels such as SSH or HTTPS for data transmission.
BPB: B-B-11
CRA: 1.2d, 1.2e, 1.2f, 1.2i, 1.2j, 1.2k
SSDF: PO.3.2, PO.5.2, PS.1, PS.2
OCRE: 483-813, 124-564, 263-184
SLSA: Choose an appropriate build platform
Provide transparency and accountability for changes made to the project's software releases, enabling users to understand the modifications and improvements included in each release.
Requirement: When an official release is created, that release MUST contain a descriptive log of functional and security modifications.
Recommendation: Ensure that all releases include a descriptive change log. It is recommended to ensure that the change log is human-readable and includes details beyond commit messages, such as descriptions of the security impact or relevance to different use cases. To ensure machine readability, place the content under a markdown header such as "## Changelog".
BPB: CC-B-8, CC-B-9, Q-B-7, A-B-1, A-S-1
CRA: 1.2d, 1.2f, 1.2h, 1.2j, 1.2l, 2.5
SSDF: PS.1, PS.2, PS.3, PW.1.2
OCRE: 483-813, 068-486, 124-564, 757-271, 347-352, 263-184, 208-355, 745-356, 732-148
SLSA: Choose an appropriate build platform, Follow a consistent build process, Build platform - Isolation strength - isolated
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.
Requirement: When a build and release pipeline ingests dependencies, it MUST use standardized tooling where available.
Recommendation: Use a common tooling for your ecosystem, such as package managers or dependency management tools to ingest dependencies at build time. This may include using a dependency file, lock file, or manifest to specify the required dependencies, which are then pulled in by the build system.
BPB: Q-B-2
CRA: 1.2b, 1.2d, 1.2f, 1.2h, 1.2j, 2.1, 2.2, 2.3
SSDF: PO.3.2, PS.1, PS.2
OCRE: 486-813, 124-564, 347-352, 715-334
SLSA: Isolation strength - isolated
All released software assets MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.
Requirement: When an official release is created, that release MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.
Recommendation: Sign all released software assets at build time with a cryptographic signature or attestations, such as GPG or PGP signature, Sigstore signatures, SLSA provenance, or SLSA VSAs. Include the cryptographic hashes of each asset in a signed manifest or metadata file.
Documentation focuses on the information provided to users, contributors, and maintainers of the project. These controls help ensure that the project's documentation is comprehensive, accurate, and up-to-date, enabling users to understand the project's features and functionality, maintenance, support, security and release practices.
Ensure that users have a clear and comprehensive understanding of the project's current features in order to prevent damage from misuse or misconfiguration.
Requirement: When the project has made a release, the project documentation MUST include user guides for all basic functionality.
Recommendation: Create user guides or documentation for all basic functionality of the project, explaining how to install, configure, and use the project's features. If there are any known dangerous or destructive actions available, include highly-visible warnings.
BPB: B-B-1, B-B-9, B-S-7, B-S-9
CRA: 1.2b, 1.2j, 1.2k
SSDF: PW.1.2
CSF: GV.OC-04, GV.OC-05
OC: 4.1.4
OCRE: 036-275
Enable users and contributors to report defects or issues with the released software assets, facilitating communication and collaboration on defect fixes and improvements.
Requirement: When the project has made a release, the project documentation MUST include a guide for reporting defects.
Recommendation: It is recommended that projects use their VCS default issue tracker. If an external source is used, ensure that the project documentation and contributing guide clearly and visibly explain how to use the reporting system. It is recommended that project documentation also sets expectations for how defects will be triaged and resolved.
BPB: B-B-3, R-B-1+, R-B-1, R-B-2, R-S-2
CRA: 1.2c, 1.2l, 2.1, 2.2, 2.5, 2.6
SSDF: PW.1.2, RV.1.1, RV.2.1, RV.1.2
CSF: RS.MA-02, GV.RM-05
OC: 4.2.1
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.
Requirement: When the project has made a release, the project documentation MUST contain instructions to verify the integrity and authenticity of the release assets.
Recommendation: Instructions in the project should contain information about the technology used, the commands to run, and the expected output. When possible, avoid storing this documentation in the same location as the build and release pipeline to avoid a single breach compromising both the software and the documentation for verifying the integrity of the software.
Requirement: 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.
Recommendation: The expected identity may be in the form of key IDs used to sign, issuer and identity from a sigstore certificate, or other similar forms. When possible, avoid storing this documentation in the same location as the build and release pipeline to avoid a single breach compromising both the software and the documentation for verifying the integrity of the software.
Provide users with clear expectations regarding the project's support lifecycle. This allows downstream consumers to take relevant actions to ensure the continued functionality and security of their systems.
Requirement: 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.
Recommendation: In order to communicate the scope and duration of support for the project's released software assets, the project should have a SUPPORT.md file, a "Support" section in SECURITY.md, or other documentation explaining the support lifecycle, including the expected duration of support for each release, the types of support provided (e.g., bug fixes, security updates), and any relevant policies or procedures for obtaining support.
Communicating when the project maintainers will no longer fix defects or security vulnerabilities is crucial for downstream consumers to find alternative solutions or alternative means of support for the project.
Requirement: 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.
Recommendation: In order to communicate the scope and duration of support for security fixes, the project should have a SUPPORT.md or other documentation explaining the project's policy for security updates.
Provide information about how the project selects, obtains, and tracks dependencies, libraries, frameworks, etc. to help downstream consumers understand how the project operates in regards to third-party components that are required necessary for the software to function.
Requirement: When the project has made a release, the project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies.
Recommendation: It is recommended to publish this information alongside the project's technical & design documentation on a publicly viewable resource such as the source code repository, project website, or other channel.
Governance focuses on the policies and procedures that guide the project's decision-making and community interactions. These controls help ensure that the project is well positioned to respond to both threats and opportunities.
Documenting project roles and responsibilities helps project participants, potential contributors, and downstream consumers have an accurate understanding of who is working on the project and what areas of authority they may have.
Requirement: While active, the project documentation MUST include a list of project members with access to sensitive resources.
Recommendation: Document project participants and their roles through such artifacts as members.md, governance.md, maintainers.md, or similar file within the source code repository of the project. This may be as simple as including names or account handles in a list of maintainers, or more complex depending on the project's governance.
Requirement: While active, the project documentation MUST include descriptions of the roles and responsibilities for members of the project.
Recommendation: Document project participants and their roles through such artifacts as members.md, governance.md, maintainers.md, or similar file within the source code repository of the project.
Encourages open communication and collaboration within the project community, enabling users to provide feedback and discuss proposed changes or usage challenges.
Requirement: While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.
Recommendation: Establish one or more mechanisms for public discussions within the project, such as mailing lists, instant messaging, or issue trackers, to facilitate open communication and feedback.
Provide guidance to new contributors on how to participate in the project, outlining the steps required to submit changes or enhancements to the project's codebase.
Requirement: While active, the project documentation MUST include an explanation of the contribution process.
Recommendation: Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the contribution process including the steps for submitting changes, and engaging with the project maintainers.
Requirement: While active, the project documentation MUST include a guide for code contributors that includes requirements for acceptable contributions.
Recommendation: Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project documentation to outline the requirements for acceptable contributions, including coding standards, testing requirements, and submission guidelines for code contributors. It is recommended that this guide is the source of truth for both contributors and approvers.
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.
Requirement: While active, the project documentation MUST have a policy that code contributors are reviewed prior to granting escalated permissions to sensitive resources.
Recommendation: Publish an enforceable policy in the project documentation that requires code contributors to be reviewed and approved before being granted escalated permissions to sensitive resources, such as merge approval or access to secrets. It is recommended that vetting includes establishing a justifiable lineage of identity such as confirming the contributor's association with a known trusted organization.
BPB: B-B-5, B-S-3, B-B-4+, Q-G-2
CRA: 1.2d, 1.2l, 2.1, 2.2, 2.5, 2.6
SSDF: PO.2, PO.3.2
CSF: PR.AA-02, PR.AA-05
OCRE: 123-124, 152-725
OC: 4.1.2
Legal focuses on the policies and procedures that govern the project's licensing and intellectual property. These controls help ensure that the project's source code is distributed under a recognized and legally enforceable open source software license, reducing the risk of intellectual property disputes or licensing violations.
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.
Requirement: 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.
Recommendation: Include a DCO or CLA in the project's repository, requiring code contributors to assert that they are legally authorized to commit the associated contributions on every commit. Use a status check to ensure the assertion is made. Some version control systems, such as GitHub, may include this in the platform terms of service.
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.
Requirement: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
Recommendation: Add a LICENSE file to the project's repo with a license that is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Releasing to the public domain meets this control if there are no other encumbrances such as patents.
Requirement: While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
Recommendation: If a different license is included with released software assets, ensure it is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Note that the license for the released software assets may be different than the source code.
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.
Requirement: While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory.
Recommendation: Include the project's source code license in the project's LICENSE file, COPYING file, or LICENSE/ directory to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.
Requirement: 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.
Recommendation: Include the project's released software assets license in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.
Quality focuses on the processes and practices used to ensure the quality and reliability of the project's source code and software assets. These controls help ensure that the project's source code is well maintained, secure, and reliable, reducing the risk of defects or vulnerabilities in the software.
Enable users to access and review the project's source code and history, promoting transparency and collaboration within the project community.
Requirement: While active, the project's source code repository MUST be publicly readable at a static URL.
Recommendation: Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the repository is publicly readable. Avoid duplication or mirroring of repositories unless highly visible documentation clarifies the primary source. Avoid frequent changes to the repository that would impact the repository URL. Ensure the repository is public.
Requirement: The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made.
Recommendation: Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a publicly readable commit history. Avoid squashing or rewriting commits in a way that would obscure the author of any commits.
BPB: CC-B-1, CC-B-2, CC-B-3, R-B-5
CRA: 1.2b, 1.2f, 1.2j
SSDF: PS.1, PS.2, PS.3, PW.1.2, PW.2.1
OCRE: 486-813, 124-564, 757-271
CSF: ID.AM-02, ID.RA-01, ID.RA-08
OC: 4.1.4
SLSA: Build platform - isolation strength - Isolated
Provide transparency and accountability for the project's dependencies while enabling users and contributors to understand the software's direct dependencies.
Requirement: When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies.
Recommendation: This may take the form of a package manager or language dependency file that enumerates all direct dependencies such as package.json, Gemfile, or go.mod.
Requirement: When the project has made a release, all compiled released software assets MUST be delivered with a software bill of materials.
Recommendation: It is recommended to auto-generate SBOMs at build time using a tool that has been vetted for accuracy. This enables users to ingest this data in a standardized approach alongside other projects in their environment.
BPB: Q-S-8, Q-S-9
CRA: 2.1, 2.2, 2.3
SSDF: PO.3.3, PS.1, PS.2, PS.3.2, PW.4
CSF: ID.AM.01, ID.AM-02
OC: 4.1.5, 4.3.1
OCRE: 486-813, 124-564, 673-475, 863-521, 613-286
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.
Requirement: When a commit is made to the primary branch, any automated status checks for commits MUST pass or be manually bypassed.
Recommendation: Configure the project's version control system to require that all automated status checks pass or require manual acknowledgement before a commit can be merged into the primary branch. It is recommended that any optional status checks are NOT configured as a pass or fail requirement that approvers may be tempted to bypass.
Ensure that additional code repositories or subprojects produced by the project are held to a standard that is clear and appropriate for that codebase.
Requirement: While active, the project documentation MUST contain a list of any codebases that are considered subprojects or additional repositories.
Recommendation: Document any additional subproject code repositories produced by the project and compiled into a release. This documentation should include the status and intent of the respective codebase.
Requirement: 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.
Recommendation: Any additional subproject code repositories produced by the project and compiled into a release must enforce security requirements as applicable to the status and intent of the respective codebase. In addition to following the corresponding OSPS Baseline requirements, this may include requiring a security review, ensuring that it is free of vulnerabilities, and ensuring that it is free of known security issues.
CRA: 1.2b, 1.2f
SSDF: PO.3.2, PO.4.1, PS.1, PS.2, RV.1.2
OCRE: 486-813, 124-564
SLSA: Build platform - isolation strength - Isolated
ScCrd: Binary-Artifacts
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.
Requirement: While active, the version control system MUST NOT contain generated executable artifacts.
Recommendation: Remove generated executable artifacts in the project's version control system. It is recommended that any scenario where a generated executable artifact appears critical to a process such as testing, it should be instead be generated at build time or stored separately and fetched during a specific well-documented pipeline step.
Requirement: While active, the version control system MUST NOT contain unreviewable binary artifacts.
Recommendation: Do not add any unreviewable binary artifacts to the project's version control system. This includes executable application binaries, library files, and similar artifacts. It does not include assets such as graphical images, sound or music files, and similar content typically stored in a binary format.
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.
Requirement: 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.
Recommendation: Automated tests should be run prior to every merge into the primary branch. The test suite should be run in a CI/CD pipeline and the results should be visible to all contributors. The test suite should be run in a consistent environment and should be run in a way that allows contributors to run the tests locally. Examples of test suites include unit tests, integration tests, and end-to-end tests.
Requirement: While active, project's documentation MUST clearly document when and how tests are run.
Recommendation: Add a section to the contributing documentation that explains how to run the tests locally and how to run the tests in the CI/CD pipeline. The documentation should explain what the tests are testing and how to interpret the results.
Requirement: 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.
Recommendation: Add a section to the contributing documentation that explains the policy for adding or updating tests. The policy should explain what constitutes a major change and what tests should be added or updated.
BPB: Q-B-4, Q-B-8, Q-B-9, Q-B-10, Q-S-2
CRA: 2.3
SSDF: PW.8.2
CSF: ID.AM-02
OC: 4.1.5
OCRE: 207-435, 088-377
ScCrd: CI-Tests
Ensure that the project's version control system requires at least one non-author approval of changes before merging into the release or primary branch.
Requirement: When a commit is made to the primary branch, the project's version control system MUST require at least one non-author approval of the changes before merging.
Recommendation: Configure the project's version control system to require at least one non-author approval of changes before merging into the release or primary branch. This can be achieved by requiring a pull request to be reviewed and approved by at least one other contributor before it can be merged.
BPB: B-G-3
ScCrd: Code-Review
Security Assessment encourages practices that help ensure that the project is well positioned to identify and address security vulnerabilities and threats in the software.
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.
Requirement: When the project has made a release, the project documentation MUST include design documentation demonstrating all actions and actors within the system.
Recommendation: Include designs in the project documentation that explains the actions and actors. Actors include any subsystem or entity that can influence another segment in the system. Ensure this is updated for new features or breaking changes.
BPB: B-B-1, B-S-7, B-S-8
CRA: 1.2a, 1.2b
SSDF: PO.1, PO.2, PO.3.2
CSF: ID.AM-02
OCRE: 155-155, 326-704, 068-102, 036-275, 162-655
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.
Requirement: When the project has made a release, the project documentation MUST include descriptions of all external software interfaces of the released software assets.
Recommendation: Document all software interfaces (APIs) of the released software assets, explaining how users can interact with the software and what data is expected or produced. Ensure this is updated for new features or breaking changes.
BPB: B-B-10, B-S-7
CRA: 1.2a, 1.2b
SSDF: PW.1.2
CSF: GV.OC-05, ID.AM-01
OC: 4.1.4
OCRE: 155-155, 068-102, 072-713, 820-878
Provide project maintainers an understanding of how the software can be misused or broken allows them to plan mitigations to close off the potential of those threats from occurring.
Requirement: 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.
Recommendation: Performing a security assessment informs both project members as well as downstream consumers that the project understands what problems could arise within the software. Understanding what threats could be realized helps the project manage and address risk. This information is useful to downstream consumers to demonstrate the security acumen and practices of the project. Ensure this is updated for new features or breaking changes.
Requirement: 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.
Recommendation: Threat modeling is an activity where the project looks at the codebase, associated processes and infrastructure, interfaces, key components and "thinks like a hacker" and brainstorms how the system be be broken or compromised. Each identified threat is listed out so the project can then think about how to proactively avoid or close off any gaps/vulnerabilities that could arise. Ensure this is updated for new features or breaking changes.
BPB: B-S-8, S-G-1
CRA: 1.1, 1.2j, 1.2k, 2.2
SSDF: PO.5.1, PW.1.1
CSF: ID.RA-01, ID.RA-04, ID.RA-05, DE.AE-07
OC: 4.1.5
OCRE: 068-102, 154-031, 888-770
Vulnerability Management focuses on the processes and practices used to identify and address security vulnerabilities in the project's software dependencies. These controls help ensure that the project is well positioned to respond to security threats and vulnerabilities in the software.
Establish a process for reporting and addressing vulnerabilities in the project, ensuring that security issues are handled promptly and transparently.
Requirement: While active, the project documentation MUST include a policy for coordinated vulnerability disclosure (CVD), with a clear timeframe for response.
Recommendation: Create a SECURITY.md file at the root of the directory, outlining the project's policy for coordinated vulnerability disclosure. Include a method for reporting vulnerabilities. Set expectations for how the project will respond and address reported issues.
BPB: R-B-6, R-B-8, R-S-2, S-B-14, S-B-15
CRA: 2.1, 2.2, 2.3, 2.6, 2.7, 2.8
SSDF: RV.1.3
CSF: GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08
OC: 4.1.5, 4.2.1, 4.3.2
OCRE: 887-750
ScCrd: Security-Policy
Reports from researchers and users are an important source for identifying vulnerabilities in a project. People with vulnerabilities to report should have a clear understanding of the process so that they can quickly submit the report to the project.
Requirement: While active, the project documentation MUST contain security contacts.
Recommendation: Create a security.md (or similarly-named) file that contains security contacts for the project.
BPB: B-S-8
CRA: 2.5
SSDF: RV.1.3
CSF: GV.PO-01, GV.PO-02, ID.RA-01
OC: 4.1.1, 4.1.3, 4.1.5, 4.2.2
OCRE: 464-513
ScCrd: Security-Policy
Security vulnerabilities should not be shared with the public until such time the project has been provided time to analyze and prepare remediations to protect users of the project.
Requirement: While active, the project documentation MUST provide a means for private vulnerability reporting directly to the security contacts within the project.
Recommendation: Provide a means for security researchers to report vulnerabilities privately to the project. This may be a dedicated email address, a web form, VCS specialized tools, email addresses for security contacts, or other methods.
Consumers of the project must be informed about known vulnerabilities found within the project.
Requirement: While active, the project documentation MUST publicly publish data about discovered vulnerabilities.
Recommendation: Provide information about known vulnerabilities in a predictable public channel, such as a CVE entry, blog post, or other medium. To the degree possible, this information should include affected version(s), how a consumer can determine if they are vulnerable, and instructions for mitigation or remediation.
Requirement: 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.
Recommendation: Establish a VEX feed communicating the exploitability status of known vulnerabilities, including assessment details or any mitigations in place preventing vulnerable code from being executed.
Ensure that the project clearly communicates the threshold for remediation of SCA findings, including vulnerabilities and license issues in software dependencies. Ensure that violations of your SCA policy are addressed before software is merged as well as before it releases, reducing the risk of compromised delivery mechanisms or released software assets that are vulnerable or malicious.
Requirement: While active, the project documentation MUST include a policy that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses.
Recommendation: Document a policy in the project that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses. Include the process for identifying, prioritizing, and remediating these findings.
Requirement: While active, the project documentation MUST include a policy to address SCA violations prior to any release.
Recommendation: Document a policy in the project to address applicable Software Composition Analysis results before any release, and add status checks that verify compliance with that policy prior to release.
Requirement: 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.
Recommendation: Create a status check in the project's version control system that runs a Software Composition Analysis tool on all changes to the codebase. Require that the status check passes before changes can be merged.
BPB: B-S-8, Q-B-12, Q-S-9, S-B-14, S-B-15, A-B-1, A-B-3, A-B-8, A-S-1
CRA: 1.2a, 1.2b, 1.2c, 2.1, 2.2, 2.3, 2.4
SSDF: PO.4, PW.1.2, PW.8.1, RV.1.2, RV.1.3, RV.2.1, RV.2.2
CSF: GV.RM-05, GV.RM-06, GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08, ID.IM-02
OC: 4.1.5, 4.2.1, 4.2.2, 4.3.2
OCRE: 155-155, 124-564, 757-271, 464-513, 611-158, 207-435, 088-377
ScCrd: Security-Policy, Vulnerabilities
Identify and address defects and security weaknesses in the project's codebase early in the development process, reducing the risk of shipping insecure software.
Requirement: While active, the project documentation MUST include a policy that defines a threshold for remediation of SAST findings.
Recommendation: Document a policy in the project that defines a threshold for remediation of Static Application Security Testing (SAST) findings. Include the process for identifying, prioritizing, and remediating these findings.
Requirement: 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.
Recommendation: Create a status check in the project's version control system that runs a Static Application Security Testing (SAST) tool on all changes to the codebase. Require that the status check passes before changes can be merged.
BPB: B-S-8, Q-B-12, Q-S-9, S-B-14, S-B-15, A-B-1, A-B-3, A-B-8, A-S-1
CRA: 1.2a, 1.2b, 1.2c, 2.1, 2.2, 2.3, 2.4
SSDF: PO.4, PW.1.2, PW.8.1, RV.1.2, RV.1.3, RV.2.1, RV 2.2
CSF: GV.RM-05, GV.RM-06, GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08, ID.IM-02
OC: 4.1.5, 4.2.1, 4.2.2, 4.3.2
OCRE: 155-155, 124-564, 757-271, 464-513, 611-158, 207-435, 088-377
ScCrd: Security-Policy, Vulnerabilities, SAST
Controls within this document may map to the following external frameworks:
Code provided by an external source that is executed by a system without validation or restriction.
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective.
See OWASP's Attack Surface Analysis Cheat Sheet for more information.
References:
A collection of pre-written test cases that, when invoked,
execute the software to verify that actual results are expected results
without requiring manual intervention.
An automated test suite must return an overall "pass" or "fail" result,
and is often implemented using a test framework.
Common ways to invoke automated tests include make check, make test, npm test, and cargo test manually or as part of a Continuous Integration workflow.
The OpenSSF Best Practices Badge Identifies FLOSS best practices & implements a badging system for those practices.
References:
A series of automated processes that compile and deploy software. Similar to the generic term CI/CD Pipelines, but this term excludes some pipelines, such as pre-merge status checks.
Any alteration of the project's codebase, CI/CD Pipelines, or documentation. This may include addition, deletion, or modification of content.
Automated pipelines for Continuous Integration and Continuous Delivery. Responsible for building, testing, and delivering changes. These pipelines integrate contributions frequently, enabling rapid and reliable software delivery. CI focuses on testing and building code, while CD delivers software to location such as a package registry.
In the context of the Open Source Project Security Baseline, CD refers only to continuous delivery, not to continuous deployment, as sometimes used elsewhere.
Entities who commit code or documentation to the project. Code contributors include collaborators or external participants who submit changes.
In the context of the Open Source Project Security Baseline, code contributors does not address non-code contributions such as designing, triaging, reviewing, or testing.
The collection of source code and related assets that make up the project. The codebase includes all files necessary to build and test the software. Lives in the repository, sometimes alongside documentation and CI/CD pipelines. The contents of the codebase are the primary deliverable in a release.
A user with a role on the project's version control system who can approve changes or manage the repository settings. Collaborators may have varying permission levels based on their role in the project. This does not include contributors whose changes only originate through a request from a repository fork.
A record of a single change submitted to the version control system. Each commit includes details such as the modifications made, the contributor who made them, and the timestamp of the change.
A process of gathering information from vulnerability finders, coordinating the sharing of that information between relevant stakeholders, and disclosing the existence of software vulnerabilities and their mitigations to various stakeholders including the public.
References:
https://certcc.github.io/CERT-Guide-to-CVD/
https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1-1
https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/about-coordinated-disclosure-of-security-vulnerabilities
Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA). 2024 European cybersecurity law that goes into full effect December 2027. Focuses on products sold within the European Union and the cybersecurity and vulnerability management practices used to create and support the product.
References:
The NIST Cyber Security Framework (CSF) helps organizations understand and improve their management of cybersecurity risk.
References:
https://www.nist.gov/cyberframework
https://doi.org/10.6028/NIST.CSWP.29
Errors or flaws in the software that cause it to produce incorrect or unintended results, or to behave in an unintended way. Defects can include bugs, vulnerabilities, or other issues that impact the software's functionality or security. Defects may have originally been intentional, but a change in environment or understanding has made them undesirable.
An initiative aimed at standardizing the way End-of-Life and End-of-Support information is exchanged within the software and hardware industries. Covering both vendors and open-source maintainers, OpenEoX strives to provide a transparent, efficient, and unified approach to managing product lifecycles.
References:
Defects in the software that can be leveraged by attackers to gain unauthorized access, execute arbitrary code, or cause other undesired outcomes.
A legal document that defines the terms under
which the software can be used, modified, and
distributed. May be stored at the top level
of the repository in a file named LICENSE
or within files in a directory named
LICENSE/. The license applies to repository
contents and any released software assets,
unless otherwise stated.
Publicly acknowledged exploitable vulnerabilities that have been identified within the software. These vulnerabilities often have associated advisories, patches, or recommended mitigations.
All proposed changes to the project's codebase must be automatically evaluated against a documented policy for known vulnerabilities and blocked in the event of violations.
An authentication method that requires two or more verification factors (e.g., a password and a token) to gain access to a resource. This method strengthens security by requiring multiple forms of identification.
A Linux Foundation project that oversee two ISO/IEC standards to better understand and manage software supply chains.
References:
https://openchainproject.org/
https://openchainproject.org/license-compliance
An OWASP project that converts cybersecurity requirements into a hierarchical, machine-readable format.
References:
https://www.opencre.org/
https://zeljkoobrenovic.github.io/opencre-explorer/
An OpenSSF project that helps users assesses open source projects for security risks through a series of automated checks. It was created by OSS developers to help improve the health of critical projects that the community depends on.
References:
https://github.com/ossf/scorecard
https://scorecard.dev/
The main development branch in the version
control system, representing the latest
stable codebase. Releases are typically made
from this branch. Commonly named main or
master. In some situations where branches
are not featured, a repository with forked
repositories will have the original repo
acting as an equivalent to the primary
branch.
The process of privately reporting a vulnerability to the project maintainers or security team before disclosing it publicly. This allows the project to address the issue before it becomes widely known.
References:
Written materials related to the project, such as user guides, developer guides, and contribution guidelines. These documents help users and developers understand, contribute to, and interact with the software. At release time, this may include provenance information, licensing details, and other metadata.
Information that, if disclosed to unauthorized parties, would lead to unauthorized access, data exfiltration, financial loss, or other undesirable outcomes. This includes secrets (like passwords, access tokens, etc.), financial account information, personally identifiable information (PII), and data about embargoed vulnerabilities.
Resources that, if compromised, would provide a vector for further compromising software build and delivery or for disclosing sensitive data to unauthorized parties. This includes build systems, image repositories, and data storage.
Information about the origin and history of the released software assets. This may include details about its development, dependencies, vulnerabilities, contributors, and licensing.
Deliverables provided to users as part of a release. These assets can include binaries, libraries, or containers.
A storage location managed by a version control system where the project's code, documentation, and other resources are stored. It tracks changes, manages collaborator permissions, and includes configuration options such as branch protection and access controls.
The NIST Secure Software Development Framework (SP 800-218) is a broadly reviewed and collaborative set of fundamental secure software development practices.
References:
https://csrc.nist.gov/projects/ssdf
https://csrc.nist.gov/pubs/sp/800/218/final
A list of all components that make up a given piece of software or hardware, formatted as CycloneDX or SPDX. This list must include the following data elements for the components included in the released software asset: license, supplier name, filename of the component, component name, component version, software identifiers, relationship between the components, author of the SBOM data and timestamp. Additionally, for deployable and executable components, the SBOM should record their cryptographic hashes.
References:
https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf
https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf
https://spdx.dev
https://cyclonedx.org
The process of identifying and cataloging all components and dependencies in a software codebase. SCA is essential for managing security vulnerabilities and ensuring compliance with organizational policies.
Automated tests or validations that run on commits before they are merged. Status checks ensure that any changes meet the project's quality and security standards.
A codebase that is part of the project but maintained in a separate repository. Subprojects may be compiled into the primary project or used as standalone components.
An OpenSSF project that sets guidelines for securing software supply chain infrastructure and artifact integrity.
References:
https://openssf.org/projects/slsa/
https://slsa.dev/
Threat modeling is an activity where the project looks at the codebase, associated processes and infrastructure, interfaces, key components and "thinks like a hacker" to brainstorm how the system be be broken or compromised.
Each identified threat is listed out so the project can then think about how to proactively avoid or close off any gaps/vulnerabilities that could arise.
Examples of threat modeling methodologies include the Shostack "4 Questions" model, STRIDE, and tools such as the Elevation of Privilege Threat Modeling Card Game or Threat Dragon.
References:
https://github.com/adamshostack/4QuestionFrame
https://owasp.org/www-community/Threat_Modeling_Process
https://www.microsoft.com/en-us/download/details.aspx?id=20303
https://owasp.org/www-project-threat-dragon
A label assigned to a specific release of the
software, such as v1.2.3. Commonly
recommended formats are Semantic Versioning
or Calendar Versioning.
A tool that tracks changes to files over time and facilitates collaboration among contributors. Examples of version control systems include Git, Subversion, and Mercurial.
The act of identifying and documenting exploitable vulnerabilities in released software assets. This may include privately or openly reporting vulnerabilities to maintainers, security teams, or the public, as well as tracking the resolution of these vulnerabilities.
References:
This baseline was created by community leaders from across the Linux Foundation, including: