Open Source Project Security Baseline
This pages tracks the implementation status of Open Source Project Security Baseline by OpenSSF.
Level 1
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
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.
The MAINTAINERS.md guideline outlines contributor roles for the OpenBao GitHub organization and its repositories. Existing members onboard new contributors through a voting process if candidates meet the described requirements, or if the Technical Steering Committee (TSC) grants an exception to these requirements.
Once approved, the project files a JIRA ticket with LF staff, linking to the results of the vote and noting the corresponding teams for the GitHub users. LF staff's organization owners invite and assign these contributors to one or more GitHub teams. The CODEOWNERS file then specifies fine-grained permissions and responsibilities at the repository level.
Organization owners are managed through their GitHub Enterprise identities, and the responsible Linux Foundation bodies govern them.
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-03.01
When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels.
OSPS-DO-01.01
Requirement: When the project has made a release, the project documentation MUST include user guides for all basic functionality.
OpenBao publishes its documentation, including release notes, at the OpenBao documentation site. The documentation also highlights potentially dangerous or destructive operations.
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
Requirement: While active, the project documentation MUST include an explanation of the contribution process.
The CONTRIBUTING.md file details the contribution process, license policies, and contribution rights, and is also referenced on the Contributing page.
OSPS-LE-02.01
Requirement: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
The source code is released under Mozilla Public License 2.0 (see LICENSE) which is approved by the Open Source Initiative (OSI) and meets the FSF Free Software Definition (see Free Software Directory).
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
Requirement: While active, the project's source code repository MUST be publicly readable at a static URL.
OpenBao's source code repositories are hosted in the public OpenBao GitHub organization. The main openbao/openbao repository is accessible via HTTPS and SSH.
OSPS-QA-01.02
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.
All changes are tracked in Git repositories hosted in the public OpenBao GitHub organization. While pull requests can be squashed, authorship is retained and all commits must be signed off with an appropriate DCO as outlined on the Contributing page.
OSPS-QA-02.01
Requirement: When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies.
Dependencies are tracked in language-specific files such as go.mod whenever possible.
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
Requirement: While active, the version control system MUST NOT contain generated executable artifacts.
Artifacts, such as executables, binaries, or similar blobs, belong in designated artifact stores, such as GitHub Packages.
OSPS-VM-02.01
Requirement: While active, the project documentation MUST contain security contacts.
Security issues can be reported via the private mailing list, which is referenced in SECURITY.md.