Skip to content

Latest commit

 

History

History
88 lines (57 loc) · 6.86 KB

P4-grpc-cve-process.md

File metadata and controls

88 lines (57 loc) · 6.86 KB
Raw

gRPC CVE Process

Abstract

This gRFC proposes the CVE (Common Vulnerabilities and Exposure) process for gRPC. It is heavily adopted and influenced by similar processes that are in place for other Cloud Native Computing Foundation (CNCF) projects such as Kubernetes and Envoy.

Proposal

This proposal defines the Common Vulnerabilities and Exposure (CVE) process for gRPC. It is heavily adopted and influenced by similar processes that are in place for Kubernetes and Envoy.

Why do we need a CVE Process?

gRPC is an RPC library with a 6 week release cycle that is in use by major companies, products and services today. The impact of a vulnerability can therefore have large economic, privacy and security implications.

A CVE disclosure process allows people to responsibly disclose these issues, and for the gRPC team to proactively address the issues and manage the communication around the disclosure.

Disclosures

Private Disclosure Process

The gRPC Community asks that all suspected vulnerabilities be privately and responsibly disclosed via the Private Disclosure process described below:

To make a report, email the private [email protected] list with the security details and the details expected for all gRPC bug reports.

When should I report a vulnerability

  • You think you have discovered a potential security vulnerability in gRPC
  • You are unsure how a vulnerability affects gRPC
  • You think you discovered a vulnerability in another project that gRPC depends on.

When should I not report a vulnerability

  • You need help tuning gRPC security
  • You need help applying security related updates
  • Your issue is not security related

Security Vulnerability Response

Each report is acknowledged and analyzed by Product Security Team (PST) members within 3 working days.

Any vulnerability information shared with PST stays within the gRPC project and will not be disseminated to other projects unless it is necessary to get the issue fixed.

As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.

Public Disclosure Timing

A public disclosure date is negotiated by the gRPC PST and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it’s already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 14-20 days. The gRPC product security team holds the final say when setting a disclosure date.

Public Disclosure Process

If you know a publicly disclosed vulnerability, please IMMEDIATELY email [email protected] to inform PST about the vulnerability, so that we may start a patch release and communication process.

Patch, Release, and Public Communication

For each vulnerability, a member of the PST will volunteer to lead the coordination in fixing, releasing and communicating on the disclosure to the rest of the community. This lead is referred to as the Fix Lead.

  • The fix lead will make an initial determination on whether the issue could be a vulnerability. At this stage they may go back to the reporter for more information.
  • The fix lead will work to identify relevant engineers (the Fix Team) and CC them onto the disclosure thread for further triage of the issue. This should be completed within the first 24 hours of Disclosure.
  • The triage of the issue would involve, at first, to reproduce and/or evaluate the report to see whether this is a real vulnerability.
  • The fix will be worked on privately, and will land once there are approvals on the commits, and it has been fully validated to address the issue.

Fix Development Process

These steps should be completed within the 1-14 days of Disclosure.

  • The Fix Lead and the Fix Team will create a CVSS using the CVSS Calculator. They will also determine the effect and severity of the bug. The Fix Lead makes the final call on the calculated risk; it is better to move quickly than make the perfect assessment.
  • The Fix Lead will request a CVE from MITRE and include the CVSS and release details.
  • Once the fix is identified and validated, it will be committed to the master branch. The fix will then be backported to all supported branches.
  • Based on the severity of the vulnerability, the team will determine whether to backport it further, to normally unsupported versions.
  • If the CVSS score is under 4.0 (a low severity score) or the assessed risk is low the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. These decisions must be discussed on the [email protected] mailing list.
  • The Fix Lead will determine if the ongoing regular release should be delayed in order to include the fix for the known CVE.

Fix Disclosure Process

With the Fix Development underway the Fix Lead needs to come up with an overall communication plan for the wider community. This Disclosure process should begin after the Fix Team has developed a Fix or mitigation so that a realistic timeline can be communicated to users.

Once the fix lands, and is backported to all requisite release branches, the Fix Lead shall announce new releases, the CVE number, severity, impact and the location of the release binaries to get wide distribution and user action. As much as possible this announcement should be actionable, and include any mitigating steps users can take prior to upgrading to a fixed version. The announcement shall at least be sent to

  • [email protected]. These announcements will be prefixed with a subject [Security CVE-nnn], where nnn is the assigned CVE number.

Retrospective

These steps should be completed 1-3 days after the Release Date. The retrospective process should be blameless.

The Fix Lead will send a retrospective of the process to [email protected] including details on everyone involved, the timeline of the process, links to relevant PRs that introduced the issue, if relevant, and any critiques of the response and release process.

The Fix Team are also encouraged to send their own feedback on the process to [email protected]. Honest critique is the only way we are going to get good at this as a community.