What would you like to be added:
The Product Security Committee would like the ability to include details about security fixes in release notes just prior to release announcements going out.
Why is this needed:
There are situations where a vulnerability with a Medium or Low severity may be fixed semi-publicly (for example with a public PR but not mentioning the security implications). When the commit(s) are cherry-picked, they would not include any of the CVE/impact/other details in the release notes.
@justaugustus provided an example of how this could work:
- from k-security org (or some other private method) PSC files some yaml, maybe:
cve: CVE-57687939425739480235
description: Really bad SSRF in KCM
impact: low|medium|high|critical
mitre_link: https://blah
kubernetes_tracking: https://github.com/kubernetes/issues/87945258935
- that's reviewed and merged via some pipeline that PSC + Releng have visibility into
- post-submit scrapes these and copies them to a private releng staging bucket
- existing release notes tool is extended to look in that bucket during staging/release process
/cc @kubernetes/release-engineering
/cc @kubernetes/product-security-committee
What would you like to be added:
The Product Security Committee would like the ability to include details about security fixes in release notes just prior to release announcements going out.
Why is this needed:
There are situations where a vulnerability with a Medium or Low severity may be fixed semi-publicly (for example with a public PR but not mentioning the security implications). When the commit(s) are cherry-picked, they would not include any of the CVE/impact/other details in the release notes.
@justaugustus provided an example of how this could work:
/cc @kubernetes/release-engineering
/cc @kubernetes/product-security-committee