# [Draft] K8s SRC Vulnerability Triage Communication Enhancements **Notes**: From discussion with Sam Fowler! ## Phase 1 ### Summary Moving SECURITY_CONTACTS into OWNERS, under a new `security_contacts` field ### Motivation Make it easier to keep the security contacts up to date by having this information in one place - OWNERS file. It is also expected that this will help prevent the security_contacts information from getting stale. ### What changes are expected? #### Chairs and Tech Leads Please give your repo maintainers a heads up that this is coming soon. Please make them aware of embargo policies: https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy if they are not aware already. #### Maintainers You can expect one or more PRs that update the OWNERS file and remove SECURITY_CONTACTS file ### Implementation Notes - Assuming the `approvers` in OWNERS files will also be the default security contacts most times, we could make the new `security_contacts` field optional. This will also reduce manual burden of filling and maintaining, the `security_contacts` field with relevant names for most OWNERS - Plan is to utilize expertise from maintainers of this automation and get their thoughts on this update: https://github.com/kubernetes-sigs/maintainers ## Phase 2 ### Summary Use existing private SIG Leads mailing lists for private triage and discussions on reported vulnerabilities. ### Motivation OWNERS files don't support fields for email contacts, these private dedicated mailing lists could therefore be used to coordinate private/embargoed security issues without losing context as people rotate into different roles and in/out of the community. Many times SRC loses precious time in the following tasks for each vulnerability triage: * Find the person(s) who are familiar with the vulnerable code * Find the email address of the said person(s) * Ping them on slack to ask for email address if and when email address is unavailable or unresponsive * Get rerouted to different people because of stale SECURITY_CONTACTS info * Get rerouted midway of triage and fix when contributors change roles, employers and/or email addresses Using a SIG Leads mailing list, allows for continuation, consistency and single point of contact for any sub-project or code section for which a vulnerability is triaged. ### What changes are expected? #### Chairs and Tech Leads You will added to all embargoed communication for vulnerability triage that is related to sub-projects and sections of code that your SIG owns. You are encouraged to add relevant folks who are owners of that sub-project or piece of code, to reduce your direct involvement when possible. Please let us know how do you all feel about this additional responsibility especially when all of us are overwhelmed and trying to our best in this trying times. #### Maintainers Expect your SIG chairs to involve you in embargo discussions instead of these communications coming directly from SRC. ### Implementation Notes Then SRC would query the sigs.yaml file: https://kubernetes.slack.com/archives/C01672LSZL0/p1650062250754249 to find out which sub-project is owned by which SIG. The leads mailing list would then be the default recipient for any future vulnerability triage.