Add a maintenance process (#116)

* Add a maintenance process

Signed-off-by: Ben Cotton <[email protected]>

* Remove "Scorecard/Insights values" from allowed changes

Co-authored-by: Eddie Knight <[email protected]>
Signed-off-by: Ben Cotton <[email protected]>

* Update the examples to use our CalVer scheme

And also comment them out so that they aren't rendered until there are
actual things to put there.

Signed-off-by: Ben Cotton <[email protected]>

* Reflect new numbering system

Signed-off-by: Ben Cotton <[email protected]>

* Correct wording per #175

Co-authored-by: Eddie Knight <[email protected]>
Signed-off-by: Ben Cotton <[email protected]>

---------

Signed-off-by: Ben Cotton <[email protected]>
Signed-off-by: Ben Cotton <[email protected]>
Co-authored-by: Eddie Knight <[email protected]>

.github/workflows/test-build.yml

@@ -17,7 +17,7 @@ jobs:
         with:
             persist-credentials: false
       - name: Build content from yaml
-        run:  cd cmd && go run . compile --output ../docs/index.md
+        run:  cd cmd && go run . compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

.github/workflows/web-publish.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0
       - name: Build content from yaml
-        run:  cd cmd && go run . compile --output ../docs/index.md
+        run:  cd cmd && go run . compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

.gitignore

@@ -0,0 +1 @@
+docs/versions/devel.md

docs/index.md

@@ -0,0 +1,19 @@
+# Open Source Security Baseline
+
+The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to it's maturity level.
+It is maintained by the [OpenSSF Security Baseline SIG](https://github.com/ossf/security-baseline/blob/main/governance/MAINTAINERS.md) according to the [project governance documentation](https://github.com/ossf/security-baseline/blob/main/governance/GOVERNANCE.md).
+
+## Versions
+
+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.
+
+* [In-development version](docs/development)
+<!-- Leave this section out until there are historical and current versions to list.
+* Current version: [2025-04-01]()
+* Previous versions:
+    * (none)
+-->
+
+Versions are managed according to the [Baseline maintenance process](maintenance).

docs/maintenance.md

@@ -0,0 +1,22 @@
+# OSPS Baseline Maintenance Process
+
+* Normal text fixes to the criteria will be accepted via pull request and reviewed by the baseline project maintainers.
+Allowed changes are corrections to spelling/typos, grammar corrections, or enhancements to the supplementary text supporting the criteria, including: Objective, Implementation, and Control Mappings.
+At least two project maintainers must review and approve these changes.
+* Substantive changes to criteria, including changes to text that alters the originally stated meaning, new criteria proposals, or removal of criteria will be documented in GitHub PR(s) and reviewed regularly by the Baseline project maintainers for inclusion in the next release.
+These changes may reflect changes to global cybersecurity regulations and frameworks or changes in norms around application/project security practices.
+Any such substantive changes must be approved by a majority of the project's maintainers.
+* As appropriate, but at least annually, the Baseline project maintainers will evaluate the set of criteria and, if necessary, publish a new version of the Baseline.
+Previous versions of the Baseline will remain available, but are stable and not subject to change, except for minor changes to fix technical or typographic errors.
+* Any changes to the Baseline will be reflected within the Compliance Matrix, with new requirements flagged where the Baseline Criteria are appropriate.
+* Versions will follow a calendar-based identification system, using the `YYYY-MM-DD` format.
+* Downstream stakeholders will be notified via the project's mailing list on the changes and updates.
+
+## Identifiers
+
+* Identifiers for retired criteria MUST NOT be reused.
+Retired identifiers will remain in the source yaml files, clearly marked.
+* Substantial changes to the meaning of a criterion will be treated as a new criterion, resulting in a new identifier.
+Minor changes, including a change in level, between Baseline versions will not result in a new identifier.
+* The numeric portion of identifiers are assigned sequentially per category.
+Within a category, identifiers do not carry additional meaning.