diff --git a/docs/release_notes.md b/docs/release_notes.md index 2114f0ad..af2f1316 100644 --- a/docs/release_notes.md +++ b/docs/release_notes.md @@ -44,6 +44,8 @@ ### Modified controls * [OSPS-LE-03.01](versions/2026-08-28#osps-le-0301) now also accepts a `LICENSES/` directory as a license location +* [OSPS-GV-03.01](versions/2026-08-28#osps-gv-0301) now also accepts clearly stating that public contributions are not accepted +* The "While active" qualifier was removed from all control requirement texts ### Removed controls diff --git a/docs/versions/2026-08-28-checklist.md b/docs/versions/2026-08-28-checklist.md index 34101c1d..4e40fc5e 100644 --- a/docs/versions/2026-08-28-checklist.md +++ b/docs/versions/2026-08-28-checklist.md @@ -13,19 +13,19 @@ - [ ] **OSPS-BR-07.01**: The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system. - [ ] **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, LICENSES/ directory, 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-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, or clearly state that public contributions are not accepted +- [ ] **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-02.02**: The license for the released software assets 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 the corresponding repository's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory. +- [ ] **OSPS-LE-03.02**: 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**: 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**: Projects with multiple repositories MUST document a list of codebases that are part of the project. -- [ ] **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-QA-05.01**: The version control system MUST NOT contain generated executable artifacts. +- [ ] **OSPS-QA-05.02**: The version control system MUST NOT contain unreviewable binary artifacts. +- [ ] **OSPS-VM-02.01**: The project documentation MUST contain security contacts. ## Level 2 @@ -36,18 +36,18 @@ - [ ] **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-DO-07.01**: The project documentation MUST include instructions on how to build the software, including required libraries, frameworks, SDKs, and 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-GV-01.01**: The project documentation MUST include a list of project members with access to sensitive resources. +- [ ] **OSPS-GV-01.02**: The project documentation MUST include descriptions of 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-LE-01.01**: 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-VM-01.01**: The project documentation MUST include a policy for coordinated vulnerability disclosure (CVD), with a clear timeframe for response. +- [ ] **OSPS-VM-03.01**: The project documentation MUST provide a means for private vulnerability reporting directly to the security contacts within the project. +- [ ] **OSPS-VM-04.01**: The project documentation MUST publicly publish data about discovered vulnerabilities. ## Level 3 @@ -59,16 +59,16 @@ - [ ] **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 collaborators are reviewed prior to granting escalated permissions to sensitive resources. +- [ ] **OSPS-GV-04.01**: The project documentation MUST have a policy that code collaborators 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-06.02**: The project documentation MUST clearly document when and how tests are run. +- [ ] **OSPS-QA-06.03**: The project 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 human 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. +- [ ] **OSPS-VM-04.02**: 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**: 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**: The project documentation MUST include a policy to address SCA violations prior to any release. +- [ ] **OSPS-VM-05.03**: 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**: The project documentation MUST include a policy that defines a threshold for remediation of SAST findings. +- [ ] **OSPS-VM-06.02**: 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. diff --git a/docs/versions/2026-08-28.md b/docs/versions/2026-08-28.md index 4c8ec939..c903ba06 100644 --- a/docs/versions/2026-08-28.md +++ b/docs/versions/2026-08-28.md @@ -92,28 +92,28 @@ include [user][User] guides for all basic functionality. **[OSPS-DO-02.01](#osps-do-0201)**: When the [project][Project] has made a [release][Release], the [project][Project] documentation MUST include a guide for reporting [defects][Defect]. -**[OSPS-GV-02.01](#osps-gv-0201)**: While active, the [project][Project] MUST have one or more mechanisms for public +**[OSPS-GV-02.01](#osps-gv-0201)**: The [project][Project] MUST have one or more mechanisms for public discussions about proposed [changes][Change] and usage obstacles. -**[OSPS-GV-03.01](#osps-gv-0301)**: While active, the [project][Project] documentation MUST include an explanation -of the contribution process. +**[OSPS-GV-03.01](#osps-gv-0301)**: The [project][Project] documentation MUST include an explanation of the +contribution process, or clearly state that public contributions are not accepted -**[OSPS-LE-02.01](#osps-le-0201)**: While active, the [license][License] for the source [code][Code] MUST meet the OSI Open +**[OSPS-LE-02.01](#osps-le-0201)**: The [license][License] for the source [code][Code] MUST meet the OSI Open Source Definition or the FSF Free Software Definition. -**[OSPS-LE-02.02](#osps-le-0202)**: While active, the [license][License] for the [released software assets][Released Software Asset] MUST meet +**[OSPS-LE-02.02](#osps-le-0202)**: The [license][License] for the [released software assets][Released Software Asset] MUST meet the OSI Open Source Definition or the FSF Free Software Definition. -**[OSPS-LE-03.01](#osps-le-0301)**: While active, the [license][License] for the source [code][Code] MUST be maintained in +**[OSPS-LE-03.01](#osps-le-0301)**: The [license][License] for the source [code][Code] MUST be maintained in the corresponding [repository][Repository]'s [LICENSE][License] file, COPYING file, [LICENSES][License]/ directory, or [LICENSE][License]/ directory. -**[OSPS-LE-03.02](#osps-le-0302)**: While active, the [license][License] for the [released software assets][Released Software Asset] MUST be +**[OSPS-LE-03.02](#osps-le-0302)**: The [license][License] for the [released software assets][Released Software Asset] MUST be included in the released source [code][Code], or in a [LICENSE][License] file, COPYING file, or [LICENSE][License]/ directory alongside the corresponding [release][Release] assets. -**[OSPS-QA-01.01](#osps-qa-0101)**: While active, the [project][Project]'s source [code][Code] [repository][Repository] MUST be publicly +**[OSPS-QA-01.01](#osps-qa-0101)**: The [project][Project]'s source [code][Code] [repository][Repository] MUST be publicly readable at a static URL. **[OSPS-QA-01.02](#osps-qa-0102)**: The [version control system][Version Control System] MUST contain a publicly readable record of @@ -127,13 +127,13 @@ language dependencies. **[OSPS-QA-04.01](#osps-qa-0401)**: [Projects][Project] with multiple [repositories][Repository] MUST document a list of codebases that are part of the [project][Project]. -**[OSPS-QA-05.01](#osps-qa-0501)**: While active, the [version control system][Version Control System] MUST NOT contain generated +**[OSPS-QA-05.01](#osps-qa-0501)**: The [version control system][Version Control System] MUST NOT contain generated executable artifacts. -**[OSPS-QA-05.02](#osps-qa-0502)**: While active, the [version control system][Version Control System] MUST NOT contain unreviewable +**[OSPS-QA-05.02](#osps-qa-0502)**: The [version control system][Version Control System] MUST NOT contain unreviewable binary artifacts. -**[OSPS-VM-02.01](#osps-vm-0201)**: While active, the [project][Project] documentation MUST contain +**[OSPS-VM-02.01](#osps-vm-0201)**: The [project][Project] documentation MUST contain security contacts. @@ -165,16 +165,16 @@ its dependencies. include instructions on how to build the software, including required libraries, frameworks, SDKs, and dependencies. -**[OSPS-GV-01.01](#osps-gv-0101)**: While active, the [project][Project] documentation MUST include a list of -[project][Project] members with access to [sensitive resources][Sensitive Resource]. +**[OSPS-GV-01.01](#osps-gv-0101)**: The [project][Project] documentation MUST include a list of [project][Project] members with +access to [sensitive resources][Sensitive Resource]. -**[OSPS-GV-01.02](#osps-gv-0102)**: While active, the [project][Project] documentation MUST include descriptions of -the roles and responsibilities for members of the [project][Project]. +**[OSPS-GV-01.02](#osps-gv-0102)**: The [project][Project] documentation MUST include descriptions of the roles and +responsibilities for members of the [project][Project] -**[OSPS-GV-03.02](#osps-gv-0302)**: While active, the [project][Project] documentation MUST include a guide for [code][Code] +**[OSPS-GV-03.02](#osps-gv-0302)**: The [project][Project] documentation MUST include a guide for [code][Code] [contributors][Contributor] that includes requirements for acceptable contributions. -**[OSPS-LE-01.01](#osps-le-0101)**: While active, the [version control system][Version Control System] MUST require all [code][Code] +**[OSPS-LE-01.01](#osps-le-0101)**: The [version control system][Version Control System] MUST require all [code][Code] [contributors][Contributor] to assert that they are legally authorized to make the associated contributions on every [commit][Commit]. @@ -197,15 +197,15 @@ include descriptions of all external software interfaces of the security assessment to understand the most likely and impactful potential security problems that could occur within the software. -**[OSPS-VM-01.01](#osps-vm-0101)**: While active, the [project][Project] documentation MUST +**[OSPS-VM-01.01](#osps-vm-0101)**: The [project][Project] documentation MUST include a policy for [coordinated vulnerability disclosure][Coordinated Vulnerability Disclosure] ([CVD][Coordinated Vulnerability Disclosure]), with a clear timeframe for response. -**[OSPS-VM-03.01](#osps-vm-0301)**: While active, the [project][Project] documentation MUST +**[OSPS-VM-03.01](#osps-vm-0301)**: The [project][Project] documentation MUST provide a means for [private vulnerability reporting][Private Vulnerability Reporting] directly to the security contacts within the [project][Project]. -**[OSPS-VM-04.01](#osps-vm-0401)**: While active, the [project][Project] documentation MUST +**[OSPS-VM-04.01](#osps-vm-0401)**: The [project][Project] documentation MUST publicly publish data about discovered vulnerabilities. @@ -240,7 +240,7 @@ support for each [release][Release]. provide a descriptive statement when [releases][Release] or versions will no longer receive security updates. -**[OSPS-GV-04.01](#osps-gv-0401)**: While active, the [project][Project] documentation MUST have a policy that [code][Code] +**[OSPS-GV-04.01](#osps-gv-0401)**: The [project][Project] documentation MUST have a policy that [code][Code] [collaborators][Collaborator] are reviewed prior to granting escalated permissions to [sensitive resources][Sensitive Resource]. @@ -251,10 +251,10 @@ assets MUST be delivered with a [software bill of materials][Software Bill of Ma [repositories][Repository], all [subprojects][Subproject] MUST enforce security requirements that are as strict or stricter than the primary codebase. -**[OSPS-QA-06.02](#osps-qa-0602)**: While active, [project][Project]'s documentation MUST clearly document when and +**[OSPS-QA-06.02](#osps-qa-0602)**: The [project][Project] documentation MUST clearly document when and how tests are run. -**[OSPS-QA-06.03](#osps-qa-0603)**: While active, the [project][Project]'s documentation MUST include a policy that +**[OSPS-QA-06.03](#osps-qa-0603)**: The [project][Project] documentation MUST include a policy that all major [changes][Change] to the software produced by the [project][Project] should add or update tests of the functionality in an [automated test suite][Automated Test Suite]. @@ -267,28 +267,28 @@ modeling and [attack surface analysis][Attack Surface Analysis] to understand an attacks on critical [code][Code] paths, functions, and interactions within the system. -**[OSPS-VM-04.02](#osps-vm-0402)**: While active, any vulnerabilities in the +**[OSPS-VM-04.02](#osps-vm-0402)**: Any vulnerabilities in the software components not affecting the [project][Project] MUST be accounted for in a VEX document, augmenting the vulnerability report with non-exploitability details. -**[OSPS-VM-05.01](#osps-vm-0501)**: While active, the [project][Project] documentation MUST include a policy that +**[OSPS-VM-05.01](#osps-vm-0501)**: The [project][Project] documentation MUST include a policy that defines a threshold for remediation of [SCA][Software Composition Analysis] findings related to vulnerabilities and [licenses][License]. -**[OSPS-VM-05.02](#osps-vm-0502)**: While active, the [project][Project] documentation MUST include a policy to +**[OSPS-VM-05.02](#osps-vm-0502)**: The [project][Project] documentation MUST include a policy to address [SCA][Software Composition Analysis] violations prior to any [release][Release]. -**[OSPS-VM-05.03](#osps-vm-0503)**: While active, all [changes][Change] to the [project][Project]'s codebase MUST be +**[OSPS-VM-05.03](#osps-vm-0503)**: All [changes][Change] to the [project][Project]'s codebase MUST be automatically evaluated against a documented policy for malicious dependencies and [known vulnerabilities][Known Vulnerabilities] in dependencies, then blocked in the event of violations, except when declared and suppressed as non-exploitable. -**[OSPS-VM-06.01](#osps-vm-0601)**: While active, the [project][Project] documentation MUST include a policy that +**[OSPS-VM-06.01](#osps-vm-0601)**: The [project][Project] documentation MUST include a policy that defines a threshold for remediation of SAST findings. -**[OSPS-VM-06.02](#osps-vm-0602)**: While active, all [changes][Change] to the [project][Project]'s codebase MUST be +**[OSPS-VM-06.02](#osps-vm-0602)**: All [changes][Change] to the [project][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. @@ -873,7 +873,7 @@ supply chain compromise is not disclosed, compromised, or misused. 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, +the project documentation is comprehensive, accurate, and up-to-date, enabling users to understand the project's features and functionality, maintenance, support, security and release practices. @@ -1193,7 +1193,7 @@ on the project and what areas of authority they may have. #### OSPS-GV-01.01 -**Requirement:** While active, the [project][Project] documentation MUST include a list of [project][Project] members with access to [sensitive resources][Sensitive Resource]. +**Requirement:** The [project][Project] documentation MUST include a list of [project][Project] members with access to [sensitive resources][Sensitive Resource]. **Recommendation:** Document project participants and their roles through such artifacts as members.md, governance.md, maintainers.md, or similar file within @@ -1209,7 +1209,7 @@ of maintainers, or more complex depending on the project's governance. #### OSPS-GV-01.02 -**Requirement:** While active, the [project][Project] documentation MUST include descriptions of the roles and responsibilities for members of the [project][Project]. +**Requirement:** The [project][Project] documentation MUST include descriptions of the roles and responsibilities for members of the [project][Project] **Recommendation:** Document project participants and their roles through such artifacts as members.md, governance.md, maintainers.md, or similar file within @@ -1245,7 +1245,7 @@ changes or usage challenges. #### OSPS-GV-02.01 -**Requirement:** While active, the [project][Project] MUST have one or more mechanisms for public discussions about proposed [changes][Change] and usage obstacles. +**Requirement:** The [project][Project] MUST have one or more mechanisms for public discussions about proposed [changes][Change] and usage obstacles. **Recommendation:** Establish one or more mechanisms for public discussions within the project, such as mailing lists, instant messaging, or issue trackers, @@ -1281,7 +1281,7 @@ required to submit changes or enhancements to the project's codebase. #### OSPS-GV-03.01 -**Requirement:** While active, the [project][Project] documentation MUST include an explanation of the contribution process. +**Requirement:** The [project][Project] documentation MUST include an explanation of the contribution process, or clearly state that public contributions are not accepted **Recommendation:** Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the contribution process including the steps for submitting changes, and @@ -1296,7 +1296,7 @@ engaging with the project maintainers. #### OSPS-GV-03.02 -**Requirement:** While active, the [project][Project] documentation MUST include a guide for [code][Code] [contributors][Contributor] that includes requirements for acceptable contributions. +**Requirement:** The [project][Project] documentation MUST include a guide for [code][Code] [contributors][Contributor] that includes requirements for acceptable contributions. **Recommendation:** Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project documentation to outline the requirements for acceptable @@ -1337,7 +1337,7 @@ the risk of unauthorized access or misuse. #### OSPS-GV-04.01 -**Requirement:** While active, the [project][Project] documentation MUST have a policy that [code][Code] [collaborators][Collaborator] are reviewed prior to granting escalated permissions to [sensitive resources][Sensitive Resource]. +**Requirement:** The [project][Project] documentation MUST have a policy that [code][Code] [collaborators][Collaborator] are reviewed prior to granting escalated permissions to [sensitive resources][Sensitive Resource]. **Recommendation:** Publish an enforceable policy in the project documentation that requires code collaborators to be reviewed and approved before being @@ -1392,7 +1392,7 @@ the risk of intellectual property disputes against the project. #### OSPS-LE-01.01 -**Requirement:** While active, the [version control system][Version Control System] MUST require all [code][Code] [contributors][Contributor] to assert that they are legally authorized to make the associated contributions on every [commit][Commit]. +**Requirement:** The [version control system][Version Control System] MUST require all [code][Code] [contributors][Contributor] to assert that they are legally authorized to make the associated contributions on every [commit][Commit]. **Recommendation:** Include a DCO in the project's repository, requiring code contributors to assert that they are legally authorized to commit the @@ -1435,7 +1435,7 @@ how the code can be used and shared by others. #### OSPS-LE-02.01 -**Requirement:** While active, the [license][License] for the source [code][Code] MUST meet the OSI Open Source Definition or the FSF Free Software Definition. +**Requirement:** The [license][License] for the source [code][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 @@ -1454,7 +1454,7 @@ this control if there are no other encumbrances such as patents. #### OSPS-LE-02.02 -**Requirement:** While active, the [license][License] for the [released software assets][Released Software Asset] MUST meet the OSI Open Source Definition or the FSF Free Software Definition. +**Requirement:** The [license][License] for the [released software assets][Released Software Asset] 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), @@ -1498,7 +1498,7 @@ and contributors how each can be used and shared. #### OSPS-LE-03.01 -**Requirement:** While active, the [license][License] for the source [code][Code] MUST be maintained in the corresponding [repository][Repository]'s [LICENSE][License] file, COPYING file, [LICENSES][License]/ directory, or [LICENSE][License]/ directory. +**Requirement:** The [license][License] for the source [code][Code] MUST be maintained in the corresponding [repository][Repository]'s [LICENSE][License] file, COPYING file, [LICENSES][License]/ directory, or [LICENSE][License]/ directory. **Recommendation:** Include the project's source code license in the project's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory @@ -1516,7 +1516,7 @@ includes the license file. #### OSPS-LE-03.02 -**Requirement:** While active, the [license][License] for the [released software assets][Released Software Asset] MUST be included in the released source [code][Code], or in a [LICENSE][License] file, COPYING file, or [LICENSE][License]/ directory alongside the corresponding [release][Release] assets. +**Requirement:** The [license][License] for the [released software assets][Released Software Asset] MUST be included in the released source [code][Code], or in a [LICENSE][License] file, COPYING file, or [LICENSE][License]/ directory alongside the corresponding [release][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 @@ -1571,7 +1571,7 @@ promoting transparency and collaboration within the project community. #### OSPS-QA-01.01 -**Requirement:** While active, the [project][Project]'s source [code][Code] [repository][Repository] MUST be publicly readable at a static URL. +**Requirement:** The [project][Project]'s source [code][Code] [repository][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 @@ -1787,7 +1787,7 @@ necessary files are stored in the repository. #### OSPS-QA-05.01 -**Requirement:** While active, the [version control system][Version Control System] MUST NOT contain generated executable artifacts. +**Requirement:** The [version control system][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 @@ -1804,7 +1804,7 @@ fetched during a specific well-documented pipeline step. #### OSPS-QA-05.02 -**Requirement:** While active, the [version control system][Version Control System] MUST NOT contain unreviewable binary artifacts. +**Requirement:** The [version control system][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 @@ -1861,7 +1861,7 @@ end-to-end tests. #### OSPS-QA-06.02 -**Requirement:** While active, [project][Project]'s documentation MUST clearly document when and how tests are run. +**Requirement:** The [project][Project] 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. @@ -1875,7 +1875,7 @@ interpret the results. #### OSPS-QA-06.03 -**Requirement:** While active, the [project][Project]'s documentation MUST include a policy that all major [changes][Change] to the software produced by the [project][Project] should add or update tests of the functionality in an [automated test suite][Automated Test Suite]. +**Requirement:** The [project][Project] documentation MUST include a policy that all major [changes][Change] to the software produced by the [project][Project] should add or update tests of the functionality in an [automated test suite][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 @@ -2119,7 +2119,7 @@ transparently. #### OSPS-VM-01.01 -**Requirement:** While active, the [project][Project] documentation MUST include a policy for [coordinated vulnerability disclosure][Coordinated Vulnerability Disclosure] ([CVD][Coordinated Vulnerability Disclosure]), with a clear timeframe for response. +**Requirement:** The [project][Project] documentation MUST include a policy for [coordinated vulnerability disclosure][Coordinated Vulnerability Disclosure] ([CVD][Coordinated Vulnerability Disclosure]), 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 @@ -2163,7 +2163,7 @@ they should follow. #### OSPS-VM-02.01 -**Requirement:** While active, the [project][Project] documentation MUST contain security contacts. +**Requirement:** The [project][Project] documentation MUST contain security contacts. **Recommendation:** Create a security.md (or similarly-named) file that contains security contacts for the project. @@ -2204,7 +2204,7 @@ remediations to protect users of the project. #### OSPS-VM-03.01 -**Requirement:** While active, the [project][Project] documentation MUST provide a means for [private vulnerability reporting][Private Vulnerability Reporting] directly to the security contacts within the [project][Project]. +**Requirement:** The [project][Project] documentation MUST provide a means for [private vulnerability reporting][Private Vulnerability Reporting] directly to the security contacts within the [project][Project]. **Recommendation:** Provide a means for security researchers to report vulnerabilities privately to the project. This may be a dedicated email address, a @@ -2241,7 +2241,7 @@ vulnerabilities found within the project. #### OSPS-VM-04.01 -**Requirement:** While active, the [project][Project] documentation MUST publicly publish data about discovered vulnerabilities. +**Requirement:** The [project][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. @@ -2257,7 +2257,7 @@ instructions for mitigation or remediation. #### OSPS-VM-04.02 -**Requirement:** While active, any vulnerabilities in the software components not affecting the [project][Project] MUST be accounted for in a VEX document, augmenting the vulnerability report with non-exploitability details. +**Requirement:** Any vulnerabilities in the software components not affecting the [project][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 @@ -2296,7 +2296,7 @@ shipping insecure software. #### OSPS-VM-05.01 -**Requirement:** While active, the [project][Project] documentation MUST include a policy that defines a threshold for remediation of [SCA][Software Composition Analysis] findings related to vulnerabilities and [licenses][License]. +**Requirement:** The [project][Project] documentation MUST include a policy that defines a threshold for remediation of [SCA][Software Composition Analysis] findings related to vulnerabilities and [licenses][License]. **Recommendation:** Document a policy in the project that defines a threshold for remediation of SCA findings related to vulnerabilities and licenses. @@ -2310,7 +2310,7 @@ these findings. #### OSPS-VM-05.02 -**Requirement:** While active, the [project][Project] documentation MUST include a policy to address [SCA][Software Composition Analysis] violations prior to any [release][Release]. +**Requirement:** The [project][Project] documentation MUST include a policy to address [SCA][Software Composition Analysis] violations prior to any [release][Release]. **Recommendation:** Document a policy in the project to address applicable Software Composition Analysis results before any release, and add status checks @@ -2323,7 +2323,7 @@ that verify compliance with that policy prior to release. #### OSPS-VM-05.03 -**Requirement:** While active, all [changes][Change] to the [project][Project]'s codebase MUST be automatically evaluated against a documented policy for malicious dependencies and [known vulnerabilities][Known Vulnerabilities] in dependencies, then blocked in the event of violations, except when declared and suppressed as non-exploitable. +**Requirement:** All [changes][Change] to the [project][Project]'s codebase MUST be automatically evaluated against a documented policy for malicious dependencies and [known vulnerabilities][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 @@ -2365,7 +2365,7 @@ insecure software. #### OSPS-VM-06.01 -**Requirement:** While active, the [project][Project] documentation MUST include a policy that defines a threshold for remediation of SAST findings. +**Requirement:** The [project][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. @@ -2379,7 +2379,7 @@ these findings. #### OSPS-VM-06.02 -**Requirement:** While active, all [changes][Change] to the [project][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. +**Requirement:** All [changes][Change] to the [project][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