Update baseline.yaml - NEW - OSPS-DO-13 #115
Conversation
new proposed criteria around support statements Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Co-authored-by: Puerco <puerco@users.noreply.github.com> Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Co-authored-by: Eddie Knight <knight@linux.com> Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
to address feedback, will split out "EoS" statements into separate criteria Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Co-authored-by: Ben Cotton <bcotton@funnelfiasco.com> Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
| The project documentation MUST include a | ||
| descriptive statement about the scope and | ||
| duration of support. |
There was a problem hiding this comment.
For some projects, the scope of support is tied (for example) to specific versions. E.g. Knative has:
https://github.com/knative/community/blob/main/mechanics/RELEASE-SCHEDULE.md#upcoming-releases
Releases supported by community
Release Date EOL Min K8s Version Notes 1.16 2024-10-22 2025-04-22 1.29 1.15 2024-07-23 2025-01-21 1.28 No longer supported releases
Release Date EOL Min K8s Version Notes 1.14 2024-04-23 2024-10-22 1.28
Having a standard mechanism of communicating this would be great, but it seems like there's a gap here between "having a descriptive statement" and "users can find the descriptive statement".
I realize this is a level 1 expectation, but I'd really like to be able to verify these statements. Is the idea to use security insights here?
There was a problem hiding this comment.
I also don't see a standardized way to report EOL for a particular release branch, which seems like it's what people often actually need (I'm on 3.14 -- do I need to upgrade to 4.x, or will I get a 3.14.1?)
There was a problem hiding this comment.
Ah, this looks like it is in #117 .
There was a problem hiding this comment.
Yeah, support/lifecycle has always been challenging to ID. Each project handles it slightly differently. There are a few electronic means I'm aware of (Like OASIS's EoX) that could be explored, but there certainly is no STANDARD for this atm.
There was a problem hiding this comment.
yes, security insights could be a means to find this info
SecurityCRob
added
documentation
new proposed criteria around support statements