SIG Security should advocate for projects to adopt a security reporting process. This could happen during security assessment where assessors can encourage teams to adopt a process if they don't have one.
As part of this advocacy SIG Security should define a best practices for vulnerability reporting that teams can adopt.
It may even make sense to have a centralised email address that vulnerabilities are reported to where SIG security members can work with project teams to handle and address the vulnerability in a responsible manner?
This will be particularly useful for smaller/emerging projects and larger/more established projects can switch to their own security reporting contact point at a later time if desired.
Defining a best practice/template process could be particularly impactful now when GitHub have just released a feature for defining a security policy: Adding a security policy to your repository
In the same vein it may make sense to try and advocate for (and perhaps centralise, see #170) reporting security vulnerabilities to distributors much as Envoy (and others) have a Private Distributors List
CI certainly encourages it:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#vulnerability_report_process
I also agree a best practices statement/opinion/example is useful!
But whether responsibility resides at the SIG, or is delegated down to each project could be argued both ways. I myself would argue against centralization both in terms of "quis custodiet ipsos
custodes?" (noted in #170), but more so that it encourages tossing the problem over the wall for others to deal with. I think table stakes for projects should be that they invest significant thought and planning in the response process, and make it an ongoing priority (which should inform upstream feature planning and issue prioritization processes.)
IMO its the responsibility of the project, i believe we ask about it in the proposed template changes from #176
That being said, recalling the vulnerabilities reporting presentations given for the k8s vulns, it certainly stands to reason that SIG-Security can provide a standard process to get teams started so when the vuln happens, their response time is faster, the communications more effective, etc. We could even just host it on the microsite @ultrasaurus was discussing.
Providing a recommended process (even a template GitHub security policy) would be a good outcome for this issue, the idea for a centralised reporting mechanism admittedly doesn't scale to a nascent volunteer group.
Great to see we're asking teams about this during assessment, the natural response from those that don't have a policy in place will be to ask SIG security for recommendations so this issue ties that up nicely.
clarified it in the pull request so its more explicit.
This issue has been automatically marked as inactive because it has not had recent activity.
With regards to the template work, I recently published a CVD guide for OSS and set of templates; there may be something here that's helpful. (Or all of it? Just fork and edit away?)
Thanks @annabellegoth2boss! Would be great if another volunteer from the community could review that and suggest next steps and whether it would meet our needs to reference or adopt and if there are gaps that need to be filled in.
Happy to help review here from the lens of:
Sounds like this is relevant to: https://github.com/cncf/tag-security/issues/554, perhaps there's something that can be worked out here
@lumjjb it's related for sure. Security pals increase awareness for Cncf projects and assist in completing the self assessment. The self assessment discusses a secure reporting/ vuln disclosure process. But it certainly does not prescribe one.