Document a security issue reporting, response, and distribution process

[micahhausler]

Is your feature request related to a problem? Please describe.

This came up in the community call today so I'm filing an issue for public tracking.

Tinkerbell does not have a documented security issue reporting or response procedure, and this would be beneficial to developers, distributors, and users alike.

@markyjackson-taulia also brought up the security review required for CNCF, and that has some interaction here

Relates to tinkerbell/tink#373

Describe the solution you'd like

Kubernetes has a more developed process for handling security issues including a response team, a bug bounty program, and a distributor list. Other CNCF projects such as CoreDNS have adopted the parts of the Kubernetes process that worked best for them, and I think Tinkerbell could do something similar.

I don't want to be prescriptive and impose too much process, but here are a few things I think could help

• Document a method for reporting confirmed or suspected security issues in Tink and projects in the tinkerbell GitHub organization. This can likely be a private Google group or private CNCF group mailing list with core maintainers of the project. Given the likely low volume of reports, this will probably be sufficient for a long time.
• Add notices to the GitHub issue templates and READMEs for all projects referencing how to safely and privately report security issues
• Define a release process for addressing issues.
• Define a way to identify code owners for each project who can assist in developing a fix to a confirmed issue. Kubernetes uses a SECURITY_CONTACTS file in the root of each repository to help the PSC identify owners for a fix. Reusing the root OWNERS file may be sufficient.
• Define a process for requesting CVE IDs for issues. Kubernetes is now a CVE Numbering Authority (CNA) because we have enough valid reports that it made sense. It may make sense to partner with the Kubernetes PSC for assigning CVE IDs for confirmed issues when you do have one given your low volume. You would handle the issue and disclosure yourself, but maybe just request a CVE ID from the Kubernetes PSC. I'd recommend just requesting CVD IDs from Mitre until we need a block
• Allow distributors of a project to identify themselves as having an interest in advanced embargoed notice of a high or critical security issue and fix. Kubernetes has a documented process for this, and CoreDNS has a similar model

These do not all need to happen at the same time, but they roughly do need to occur in sequence. For example, adding notices to READMEs and issue templates depends on a reporting process, but coming up with a CVE ID process doesn't have to block getting a distributor list going.

/kind feature
/kind documentation

cc @markyjackson-taulia

[tstromberg]

Thank you for bringing this up. Is anyone up for helping us with this?