Release version 2025-10-10 of the Baseline (#405)

Signed-off-by: Ben Cotton <ben@kusari.dev>

Author: funnelfiasco

docs/index.md

@@ -16,9 +16,9 @@ Previous versions are presented for historical reference.
 Downstream consumers of the OSPS Baseline should specify their compliance against a specific version.
 Only the version labeled as "current" should be used for new compliance efforts.
 
-* Current version: [v2025.02.25](versions/2025-02-25) (<a href="versions/2025-02-25-checklist.md">checklist</a>)
+* Current version: [v2025.10.10](versions/2025-10-10) (<a href="versions/2025-10-10-checklist.md">checklist</a>)
 * Previous versions:
-    * (none)
+    * [v2025.02.25](versions/2025-02-25) (<a href="versions/2025-02-25-checklist.md">checklist</a>)
 * [In-development version](versions/devel) (<a href="versions/devel-checklist.md">checklist</a>)
 
 Versions are managed according to the [Baseline maintenance process](maintenance).

docs/versions/2025-02-25.md

@@ -1,6 +1,3 @@
----
-nav-title: Current Version
----
 
 # Open Source Project Security Baseline
 

docs/versions/2025-10-10-checklist.md

@@ -0,0 +1,72 @@
+# OSPS Baseline checklist, version: 2025-10-10
+
+## Level 1
+
+- [ ] **OSPS-AC-01.01**: When a user attempts to read or modify a sensitive resource in the project's authoritative repository, 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-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, 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. 
+- [ ] **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. 
+
+## Level 2
+
+- [ ] **OSPS-AC-04.01**: When a CI/CD task is executed with no permissions specified, the CI/CD system MUST default the task's permissions to the lowest permissions granted 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. 
+
+## Level 3
+
+- [ ] **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-BR-07.02**: The project MUST define a policy for managing secrets and credentials used by the project. The policy should include guidelines for storing, accessing, and rotating secrets and credentials. 
+- [ ] **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 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-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.