fix: regenerate v2026.08.28 pages with mid-cut baseline changes

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
 

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.