Proposed Baseline Maintenance Process

[SecurityCRob]

As we start implementing the "1.1" baseline criteria with our pilot projects, we should spend some time thinking about how we will update and maintain the baseline criteria going forward. I propose the following process (to be added as md file in repo once tex is agreed upon):

1.) Normal text fixes to the criteria will be accepted via PR 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, Control Mappings, and Scorecard/Insights values. At least two project maintainers must review and approve these changes.
2.) 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 annually by the Baseline project maintainers. 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.
3.) Any changes to the Baseline will be reflected within the Compliance Matrix, with new requirements flagged where the Baseline Criteria are appropriate.
4.) Downstream stakeholders will be notified via the project's mailing list on the changes and updates.

[mlieberman85]

This seems mostly in line with how we do it in SLSA. I think for number 2 we can make it clear that you're bound to a version of the baseline with the expectation that you align yourself to the latest on a yearly cadence?

Everything else seems straightforward.

[funnelfiasco]

This all seems reasonable to me, but for number 2 we might want to have a more frequent cadence for a while. A baseline that's constantly changing isn't much of a baseline, but I expect that real-world adoption will turn up things that we need to address. So maybe a quarterly review cadence (with the understanding that some quarters there will be nothing to review) would be better?

[mlieberman85]

Sounds like a good idea. I think this might be just what we have to do for some of these early adopters and then can switch later on once we have some continual monitoring and easy tooling in place or something.

[evankanderson]

To what extent do we want to hold defining specific versions of the requirements on tooling to verify those requirements? I worry about running too far ahead of what we can scale -- i.e. OSPS-DO-03 as writ feels difficult to verify even with modern LLM powers.

[mlieberman85]

I think some of these are OK to do something like "manually audit documentation once a year" or something as way of verifying. Again, I think this is the sort of thing LF/OpenSSF will have to provide help to the communities on as some of the smaller projects will just not be able to do a significant set of manual checks in a scalable way.

[evankanderson]

I think some of these are OK to do something like "manually audit documentation once a year" or something as way of verifying. Again, I think this is the sort of thing LF/OpenSSF will have to provide help to the communities on as some of the smaller projects will just not be able to do a significant set of manual checks in a scalable way.

I would convert "manually audit documentation once a year" to "documentation has been updated in the last year", and suggest that projects include a "last audited on" date in the file. Then we have a recorded change in the documentation which we can use to drive automation.

[funnelfiasco]

#116 (and #176 which fixes it) implement this mostly. There's one outstanding thing that I think we need to do and that's to document the actual steps for making a new release. I'll open that as a PR for an issue template.

[funnelfiasco]

Issue template created as #178