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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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:
Control applies to:
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:
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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".
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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 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. A CLA also satisfies this requirement. Some version control systems, such as GitHub, may include this in the platform terms of service.
It is understood that projects with a lengthy history prior to adopting OSPS Baseline may not be able to retroactively enforce this requirement.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
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.
Control applies to:
Controls within this document may map to the following external frameworks:
| ID | Title | Version | Description |
|---|---|---|---|
| BPB | OpenSSF Best Practices Badge | 2024 | The Open Source Security Foundation (OpenSSF) Best Practices Badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify, at no cost, by using this web application to explain how they follow each best practice. The OpenSSF Best Practices Badge is inspired by the many badges available to projects on GitHub. Consumers of the badge can quickly assess which FLOSS projects are following best practices and, as a result, are more likely to produce higher-quality secure software. |
| CSF | NIST Cybersecurity Framework | 2 | The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks. It offers a taxonomy of high level cybersecurity outcomes that can be used by any organization — regardless of its size, sector, or maturity — to better understand, assess, prioritize, and communicate its cybersecurity efforts. The CSF does not prescribe how outcomes should be achieved. Rather, it links to online resources that provide additional guidance on practices and controls that could be used to achieve those outcomes. |
| CRA | Cyber Resilience Act | 20.11.2024 | Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with EEA relevance) |
| SSDF | Secure Software Development Framework | 1.1 | The Secure Software Development Framework (SSDF) is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode. Few software development life cycle (SDLC) models explicitly address software security in detail, so practices like those in the SSDF need to be added to and integrated with each SDLC implementation. Following the SSDF practices should help software producers reduce the number of vulnerabilities in released software, reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and address the root causes of vulnerabilities to prevent recurrences. Also, because the SSDF provides a common language for describing secure software development practices, software producers and acquirers can use it to foster their communications for procurement processes and other management activities. |
| OC | ISO/IEC 18974 | 1.0 - 2023-12 | ISO/IEC 18974 helps organizations check open source for known security vulnerability issues like CVEs, GitHub dependency alerts or package manager alerts. ISO/IEC 18974 identifies: The key places to have security processes, How to assign roles and responsibilities, And how to ensure sustainability of the processes. ISO/IEC 18974 is lightweight, easy to read and is supported by our global community with free reference material and conformance resources. |
| OCRE | Open Cybersecurity Reference Architecture | 2024 | OpenCRE stands for Open Common Requirement enumeration. It is an interactive content linking platform for uniting security standards and guidelines. It offers easy and robust access to relevant information when designing, developing, testing and procuring secure software. |
| SLSA | Supply Chain Levels for Software Artifacts | 1 | SLSA (pronounced "salsa") is a security framework from source to service, giving anyone working with software a common language for increasing levels of software security and supply chain integrity. It’s how you get from safe enough to being as resilient as possible, at any link in the chain. |
| PSSCRM | Proactive Software Supply Chain Risk Management Framework | 1 | The Proactive-Software Supply Chain Risk Management (P-SSCRM) Framework is designed to help you understand and plan a secure software supply chain risk management initiative. P-SSCRM was created through a process of understanding and analyzing real-world data from nine industry-leading software supply chain risk management initiatives as well as through the analysis and unification of ten government and industry documents, frameworks, and standards. Although individual methodologies and standards differ, many initiatives and standards share common ground. P-SSCRM describes this common ground and presents a model for understanding, quantifying, and developing a secure software supply chain risk management program and determining where your organization’s existing efforts stand when contrasted with other real-world software supply chain risk management initiatives. |
| SAMM | OWASP Software Assurance Maturity Model | 2 | The mission of OWASP Software Assurance Maturity Model (SAMM) is to be the prime maturity model for software assurance that provides an effective and measurable way for all types of organizations to analyze and improve their software security posture. OWASP SAMM supports the complete software lifecycle, including development and acquisition, and is technology and process agnostic. It is intentionally built to be evolutive and risk-driven in nature. |
| PCIDSS | Payment Card Industry Data Security Standard | 4.0.1 | PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB, MasterCard and Visa Inc. The PCI Data Security Standard (PCI DSS) applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational system components included in or connected to cardholder data. If you accept or process payment cards, PCI DSS applies to you. |
| 800-161 | NIST Special Publication 800-161 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations | r1-upd1 | This publication provides guidance to organizations on identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of their organizations. The publication integrates cybersecurity supply chain risk management (C-SCRM) into risk management activities by applying a multilevel, C-SCRM-specific approach, including guidance on the development of C-SCRM strategy implementation plans, C-SCRM policies, C-SCRM plans, and risk assessments for products and services. |
| UKSSCOP | United Kingdom National Cyber Security Centre Software Security Code of Practice | 2025-05-07 | The Software Code of Practice has been created by DSIT and the National Cyber Security Centre (NCSC), the UK’s technical authority for cyber security, and is co-sealed by the Canadian Centre for Cyber Security (CCCS). The Code reflects the government’s ongoing focus on codifying minimum standards for technology providers to reduce cyber risk. It is aimed at professionals who are responsible for overseeing the development of ‘commodity’ software, including technical, compliance, and risk experts. For those organisations that require a higher level of assurance in the resilience of their connected products and technology, consider using the NCSC’s Cyber Resilience Testing scheme. |
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.
A legal agreement used to assign some of a contributor's rights covered by copyright laws to a project. This is often used to enable a project to make future changes to a work's license without requiring the assent of every contributor.
Entities who commit code or documentation to the project. This includes both human and non-human actors and makes no distinctions based on their role within the project.
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 human or non-human entity with permissions to 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 assertion made by a contributor that they have the
legal right to make a specific contribution to a
project. This is often indicated by using the
--signoff option to git commit.
References:
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.
Provides guidance to organizations on identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of their organizations.
References:
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/
PCI DSS provides a baseline of technical and operational requirements designed to protect payment account data.
References:
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:
A holistic framework that an organization can use to proactively mitigate software supply chain risk through guided adoption of tasks; and that supports assessment, scoring, and comparison against industry peers, standards, and guidelines. The P-SSCRM contextualizes and quantifies the tasks contained across multiple standards and frameworks to those carried out by various kinds of organizations.
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.
A maturity model for software assurance that provides an effective and measurable way for all types of organizations to analyze and improve their software security posture. OWASP SAMM supports the complete software lifecycle, including development and acquisition, and is technology and process agnostic. It is intentionally built to be evolutive and risk-driven in nature.
References:
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 human making use of project resources, such as the software, documentation, or other community resources. This includes both end-users and contributors.
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: