This is a release candidate, not intended 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: The project's version control system MUST require multi-factor authentication for collaborators modifying the project repository settings or accessing sensitive data.
OSPS-AC-02.01: The project's version control system MUST restrict collaborator permissions to the lowest available privileges by default.
OSPS-AC-03.01: The project's version control system MUST prevent unintentional direct commits against the primary branch.
OSPS-AC-03.02: The project's version control system MUST prevent unintentional deletion of the primary branch.
OSPS-BR-01.01: The project's build and release pipelines MUST NOT permit untrusted input that allows access to privileged resources.
OSPS-BR-03.01: Any websites and version control systems involved in the project development MUST be delivered using SSH, HTTPS, or other encrypted channels.
OSPS-BR-07.01: Any websites or other services involved in the distribution of released software assets MUST be delivered using HTTPS or other encrypted channels.
OSPS-DO-01.01: The project documentation MUST provide user guides for all basic functionality.
OSPS-DO-02.01: The project documentation MUST include a mechanism for reporting defects.
OSPS-GV-02.01: The project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.
OSPS-GV-03.01: The project documentation MUST include an explanation of the contribution process.
OSPS-LE-02.01: The license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
OSPS-LE-03.01: The license for the source code MUST be maintained in a standard location within the project's repository.
OSPS-LE-03.02: The license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
OSPS-QA-01.01: The project's source code MUST be publicly readable and have 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: The source code repository MUST contain a dependency list that accounts for the direct language dependencies when the package management system supports it.
OSPS-VM-04.01: The project MUST publish contacts and process for reporting vulnerabilities.
OSPS-AC-04.01: The project's permissions in CI/CD pipelines MUST be configured to the lowest available privileges except when explicitly elevated.
OSPS-AC-05.01: The project's CI/CD pipelines MUST restrict permissions to the lowest available privileges by default.
OSPS-BR-02.01: All releases and released software assets MUST be assigned a unique version identifier for each release intended to be used by users.
OSPS-BR-04.01: All releases MUST provide a descriptive log of functional and security modifications.
OSPS-BR-05.01: All build and release pipelines MUST use standardized tooling where available to ingest dependencies at build time.
OSPS-BR-06.01: All released software assets MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.
OSPS-BR-07.02: Any websites, API responses or other services involved in release pipelines MUST be fetched using encrypted channels.
OSPS-DO-03.01: The project documentation MUST contain instructions to verify the integrity and authenticity of the release assets, including the expected identity of the person or process authoring the software release.
OSPS-DO-04.01: The project documentation MUST include a descriptive statement about the scope and duration of support.
OSPS-DO-06.01: The project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies.
OSPS-GV-01.01: The project documentation MUST include the Roles and Responsibilities for members of the project.
OSPS-GV-03.02: The project documentation MUST include a guide for code contributors that includes requirements for acceptable contributions.
OSPS-GV-04.01: The project documentation MUST have a policy that code contributors are reviewed prior to granting escalated permissions to sensitive resources.
OSPS-LE-01.01: The version control system MUST require all code contributors to assert that they are legally authorized to commit the associated contributions on every commit.
OSPS-QA-03.01: Any automated status checks for commits MUST pass or require manual acknowledgement prior to merge.
OSPS-QA-05.01: The version control system MUST NOT contain generated executable artifacts.
OSPS-QA-06.01: The project MUST use at least one automated test suite for the source code repository.
OSPS-QA-06.02: The project's documentation MUST clearly document when and how tests are run.
OSPS-SA-01.01: The project documentation MUST provide design documentation demonstrating all actions and actors within the system.
OSPS-SA-02.01: The project documentation MUST include descriptions of all external software interfaces of the released software assets.
OSPS-SA-03.01: 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-03.01: The project documentation MUST include a policy for coordinated vulnerability reporting, with a clear timeframe for response.
OSPS-VM-05.01: The project MUST provide a means for reporting security vulnerabilities privately to the security contacts within the project.
OSPS-VM-06.01: The project MUST publicly publish data about discovered vulnerabilities.
OSPS-DO-05.01: The project documentation MUST provide a descriptive statement when releases or versions will no longer receive security updates.
OSPS-QA-02.02: All compiled released software assets MUST be delivered with a software bill of materials.
OSPS-QA-04.01: 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.
OSPS-QA-06.03: 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: The project's version control system MUST require at least one non-author approval of changes before merging into the release or primary branch.
OSPS-SA-03.02: 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-01.01: The project documentation MUST include a policy that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses.
OSPS-VM-02.01: The project documentation MUST include a policy to address SCA violations prior to any release.
OSPS-VM-02.02: 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 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: The project's version control system MUST require multi-factor authentication for collaborators modifying the project repository settings or accessing sensitive data.
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: PO3.2, PS1
CSF: PR.A-02
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: The project's version control system MUST restrict 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.
Reduce the risk of accidental changes or deletion of the primary branch of the project's repository by preventing unintentional modification.
Requirement: The project's version control system MUST prevent unintentional direct commits against the primary branch.
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: The project's version control system MUST prevent unintentional deletion of the primary branch.
Recommendation: Set branch protection on the primary branch in the project's version control system to prevent deletion.
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: The project's permissions in CI/CD pipelines MUST be configured to the lowest available privileges except when explicitly elevated.
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: PO2, PO3.2, PS1
CSF: PR.AA-02, PR.AA-05
OCRE: 486-813, 124-564, 347-507, 263-284, 123-124
Reduce the risk of unauthorized access to the project's build and release processes by limiting the permissions granted to new CI/CD pipelines.
Requirement: The project's CI/CD pipelines MUST restrict permissions to the lowest available privileges by default.
Recommendation: Configure the project's CI/CD pipelines to assign the lowest available permissions to new pipelines by default, granting additional permissions only when necessary for specific tasks.
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: The project's build and release pipelines MUST NOT permit untrusted input that allows access to privileged resources.
Recommendation: Ensure that any integration or release pipeline actions that accept externally-controlled untrusted input do not use that input in ways that could provide unintended access to privileged resources. An example of a common infraction is improper use of git branch names.
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: All releases and released software assets MUST be assigned a unique version identifier for each release intended to be used by users.
Recommendation: Assign a unique version identifier to each release and associated software asset produced by the project, following a consistent naming convention or numbering scheme. Examples include SemVer, CalVer, or git commit id.
Protect the confidentiality and integrity of project source code during development, reducing the risk of eavesdropping or data tampering.
Requirement: Any websites and version control systems involved in the project development MUST be delivered using SSH, HTTPS, or other encrypted channels.
Recommendation: Configure the project's websites and version control systems to 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: PO3.2, PS1
OCRE: 483-813, 124-564, 263-184
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: All releases MUST provide 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.
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: All build and release pipelines MUST use standardized tooling where available to ingest dependencies at build time.
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
SSDF: PO3.2, PS1
OCRE: 486-813, 124-564, 347-352, 715-334
Provide users with a mechanism to verify the authenticity and integrity of released software assets, reducing the risk of tampering or unauthorized modifications.
Requirement: All released software assets 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.
Protect the confidentiality and integrity of release assets consumed by the project's users, reducing the risk of eavesdropping or data tampering.
Requirement: Any websites or other services involved in the distribution of released software assets MUST be delivered using HTTPS or other encrypted channels.
Recommendation: Configure the project's websites and distribution services to use encrypted channels such as HTTPS for data transmission.
Requirement: Any websites, API responses or other services involved in release pipelines MUST be fetched 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: PO3.2, PS1
OCRE: 483-813, 124-564, 263-184
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.
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: The project documentation MUST provide 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: PW1.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: The project documentation MUST include a mechanism 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: PW1.2, RV1.1, RV2.1, RV1.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: The project documentation MUST contain instructions to verify the integrity and authenticity of the release assets, including the expected identity of the person or process authoring the software release.
Recommendation: Instructions in the project should contain information about the technology used, the commands to run, and the expected output. 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: The project documentation MUST include a descriptive statement about the scope and duration of support.
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 or an OpenEoX file in a well known location.
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: The project documentation MUST provide a descriptive statement when releases or versions will no longer receive security updates.
Recommendation: While a machine-readable OpenEoX file is recommended, this may also be communicated in a SUPPORT.md or beneath a Support header in the primary README.md.
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: 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: The project documentation MUST include 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: 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: 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: 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: 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.
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: The version control system MUST require all code contributors to assert that they are legally authorized to commit 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.
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: 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.
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: The license for the source code MUST be maintained in a standard location within the project's repository.
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.
Requirement: 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.
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: The project's source code MUST be publicly readable and have 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.
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.2j, 1.2f
SSDF: PS1, PS2, PS3, PW1.2, PW2.1
OCRE: 486-813, 124-564, 757-271
CSF: ID.AM-02, ID.RA-01, ID.RA-08
OC: 4.1.4
Provide transparency and accountability for the project's dependencies while enabling users and contributors to understand the software's direct dependencies.
Requirement: The source code repository MUST contain a dependency list that accounts for the direct language dependencies when the package management system supports it.
Recommendation: This may take the form a package manager or language dependency file that enumerates all direct dependencies such as package.json, Gemfile, or go.mod.
Requirement: 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.3
SSDF: PO3.3, PS1, PS3.2
CSF: ID.M-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: Any automated status checks for commits MUST pass or require manual acknowledgement prior to merge.
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: 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.
Recommendation: The parent project should maintain a list of any codebases that are considered subprojects or additional repositories. Collaborators on those repositories should identify the proper maturity level and apply the Open Source Project Security Baseline to the codebase. Any subproject or repository from the project which is compiled into the primary project must be held to the same standard as the primary project. Others may be held to a lower standard if they have lower levels of adoption or are not intended for general use.
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: 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.
Ensure that the project uses at least one automated test suite for the source code repository which clearly documents when and how tests are run.
Requirement: The project MUST use at least one automated test suite for the source code repository.
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: The 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: 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.
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: The project's version control system MUST require at least one non-author approval of changes before merging into the release or primary branch.
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.
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: The project documentation MUST provide 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.
BPB: B-B-1, B-S-7, B-S-8
CRA: 1.2a, 1.2b
SSDF: PO.1, PO.2, PO3.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: 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.
BPB: B-B-10, B-S-7
CRA: 1.2a, 1.2b
SSDF: PW1.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: 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.
Requirement: 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.
BPB: B-S-8, B-W-8, S-G-1
CRA: 1.1, 1.2j, 1.2k, 2.2
SSDF: PO5.1, PW1.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, 307-242, 660-867
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.
Ensure that the project clearly communicates the threshold for remediation of SCA findings, including vulnerabilities and license issues in software dependencies.
Requirement: 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.
BPB: Q-B-12, Q-S-9, S-B-14, S-B-15, A-B-3, A-B-8
CRA: 1.2a, 1.2b, 1.2c, 2.1, 2.2, 2.3
SSDF: PO.4, PW1.2, PW8.1, RV2.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.3.2
OCRE: 124-564, 832-555, 611-158, 207-435, 088-377
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: 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: 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 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: S-B-14, S-B-15, A-B-3, A-B-8
CRA: 1.2a, 1.2c, 2.2, 2.3
SSDF: PW8.1
CSF: GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08
OC: 4.1.5
OCRE: 486-813, 833-442, 611-158, 207-435, 088-377
Establish a process for reporting and addressing vulnerabilities in the project, ensuring that security issues are handled promptly and transparently.
Requirement: The project documentation MUST include a policy for coordinated vulnerability reporting, 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 reporting. Include a method for reporting vulnerabilities. Set expectations for the 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.3, 2.6, 2.7, 2.8
SSDF: RV1.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
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: The project MUST publish contacts and process for reporting vulnerabilities.
Recommendation: Create a security.md (or similarly-named) file that contains security contacts for the project and provide project's process for handling vulnerabilities in the project or dependencies.
BPB: B-S-8
CRA: 2.5
SSDF: RV1.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
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: The project MUST provide a means for reporting security vulnerabilities privately to the security contacts within the project.
Recommendation: Enable private bug reporting through VCS or other infrastructure.
Consumers of the project must be informed about known vulnerabilities found within the project.
Requirement: The project 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.
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.
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 hierchical, machine-readable format.
References:
https://www.opencre.org/
https://zeljkoobrenovic.github.io/opencre-explorer/
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.
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 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 infrastrucutre 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.
This baseline was created by community leaders from across the Linux Foundation, including: