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
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-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
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-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.