Skip to content

Latest commit

 

History

History
147 lines (123 loc) · 7.84 KB

responding.md

File metadata and controls

147 lines (123 loc) · 7.84 KB
Raw

Vulnerability Disclosure Response Policy

The project follows the following process when responding to vulnerabilities raised via the Security Disclosure Process.

Product Security Taskforce Membership

The subset of maintainers who are subscribed to the security@knative.team email address form the Product Security Taskforce. This group will be responsible for fixing vulnerabilities and managing the disclosure process.

The Product Security Taskforce is distinct from the embargo list: it is not necessary (or helpful) to join the PST in order to receive early notice of vulnerabilities. The PST is intentionally small to avoid inadvertent disclosures of vulnerabilities (while being large enough to spread the work of responding to vulnerabilities) and should be composed of those who will actively work on the fix and disclosure process.

Anyone who is an Approver, Lead or Steering Committee Member in a Knative Project, or who is an employee of a member of the Embargo list working in a security-focused or knative-focused role may apply to be a member of this group. The application is approved or rejected by the Steering Committee.

Identifying a Fix Lead

The PST Fix Lead Role is responsible for initially responding to vulnerabilities sent to security@knative.team, and for coordinating and managing the response with the rest of the PST.

We use a rota system to assign the default PST Lead role. All members of the PST are expected to sign up to the rota. Regardless of the rota, another member of the PST may volunteer to be the PST lead for a particular vulnerability. This may be appropriate, for example, when the vulnerability is in a particular area of the code that PST member is familiar with, or when the rota-ed PST lead is already handing another vulnerability. To avoid any confusion, if the PST Lead role is transferred, positive hand-off should be performed ("you are the PST Lead for X", "Ok, I am the PST Lead for X", "Great, you are the PST lead for X!").

Organising the Fix Team

The Fix Lead will quickly identify relevant engineers from the affected projects/areas/working groups and the PST and add those engineers to the security disclosure / email thread. This group becomes the Fix Team for the vulnerability. To prevent accidental disclosure and to maximize efficiency of response, the Fix Team should be the minimal size required for efficient response.

Note: Given the current size of the project it is likely that in many cases the Fix Team will be the entire PST, possibly with an additional engineer or engineers for the affected area if the PST does not have relevant expertise itself.

If the Fix Team decides the disclosure is in fact a vulnerability which should be fixed, the Fix Lead will create a Github Security Advisory and provide the Fix Team access to a private branch to develop the fix.

Developing a Fix and Managing Disclosures

Within 1-7 Days of Disclosure

Vulnerabilities are evaluated based on the Knative Threat Model.

  1. The Fix Team will create a CVSS using the CVSS calculator. The Fix Lead makes the final call on the calculated CVSS; it is better to move quickly than making the CVSS perfect.
  2. If the Fix Team determines this is not a vulnerability based on the Knative Threat Model, the discloser is notified and the process ends. (Note that in all cases it is important to inform the reporter that the disclosure has been seen and is being addressed as quickly as possible).
  3. Otherwise, the Fix Lead creates a private branch for development of the Fix, and a Github Security Advisory to coordinate the disclosure.
  4. The Fix Lead responds to the reporter to let them know the work has begun to address the vulnerability. If appropriate, and if the reporter is willing, the reporter is added to the Security Advisory and can help to develop the fix. The reporter may also wish to help with writing the CVE entry. They should in all cases be asked if they would like credit for identifying the vulnerability in the CVE and disclosure.
  5. The Fix Team urgently develops a fix or mitigation so that a realistic timeline can be communicated to users.
  6. The Fix Lead completes the Github Security Advisory and requests a CVE from Github.
  7. If the CVSS score is below 4.0, the Fix Team may - after appropriate discussion and based on developer bandwidth, public holidays etc - decide to slow down the release process.
  8. The fact that a vulnerability has been disclosed and a fix will be released is communicated by the Fix Lead (working with the Fix Team) to the knative-security-announce mailing list with an exact date and time planned for the disclosure. If the optional embargoed disclosure step will be followed (see next section), this date must be three weeks from when the disclosure is released to the embargo list.
  9. This email should be actionable: it should be clear when users should block time to apply patches, what mitigations are available (if appropriate), etc.

Optional, Within 1-14 Days of Disclosure (Private, Embargoed Disclosure)

  1. If, in the judgement of the Fix Lead, a private disclosure is warranted, the Embargo List is emailed with details of the fix (including any proposed patch/mitigation and actionable instructions) and the date it will be publicly disclosed and released.
  2. If this is the case, the Public Disclosure should not be released until at least three weeks after this notification is sent, to give vendors time to prepare to release the patch. In exceptional circumstances this may be extended to four weeks to account for significant public holidays etc.
  3. Note: This step is optional and should be reserved for significant vulnerabilities that warrant this treatment. In general these are vulnerabilities that could lead to remotely exploitable or privilege escalation issues.
  4. In the unlikely event that a member of the PST list breaks embargo, or if the exploit otherwise becomes public early, the PST Lead will decide whether to accelerate the schedule for public disclosure and release of the fix. When in doubt push forward and go public ASAP.

Within 1-28 Days of Disclosure (Fix Release Day)

  1. The Fix Lead cherry-picks the fix on to the main branch and all relevant release branches and creates PRs.
  2. Maintainers should approve this PR as quickly as possible (it should already have been reviewed on the private branch).
  3. If necessary, Release jobs should be manually triggered to ensure a release is available as quickly as possible.
  4. The Issue should be disclosed to the knative-security-annnounce mailing list, the knative-users mailing list, the knative-dev mailing list and the embargo list including relevant PRs, mitigations and the release numbers containing the fix.
  5. The Fix Lead removes any permissions from private branches granted for the purposes of the Fix.

Retrospective

  1. A blameless retrospective should be conducted 1-3 days after the release.
  2. The Fix Lead will send a retrospective of the process to knative-dev 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.
  3. Maintainers and Fix Team are also encouraged to send their own feedback on the process to knative-dev. Honest critique is the only way we are going to get good at this as a community.

References

This document borrows heavily and gratefully from the Envoy Vulnerability Response Process and the Google OSS Vulnerability Guide.