From 2cafab0564fdac5b8e32ffab9be9d0fecb042902 Mon Sep 17 00:00:00 2001 From: Carter Socha <43380952+cartersocha@users.noreply.github.com> Date: Sat, 16 Dec 2023 15:29:24 -0800 Subject: [PATCH] add security incident response process (#3675) --- content/en/docs/security/security-response.md | 128 ++++++++++++++++++ static/refcache.json | 12 ++ 2 files changed, 140 insertions(+) create mode 100644 content/en/docs/security/security-response.md diff --git a/content/en/docs/security/security-response.md b/content/en/docs/security/security-response.md new file mode 100644 index 000000000000..bb380bf11d25 --- /dev/null +++ b/content/en/docs/security/security-response.md @@ -0,0 +1,128 @@ +--- +title: Community Incident Response Guidelines +weight: 102 +--- + +Security vulnerabilities should be handled quickly and sometimes privately. The +primary goal of this process is to reduce the total time users are vulnerable to +publicly known exploits. + +The +[OpenTelemetry Technical Committee (OTel TC)](https://github.com/open-telemetry/community/blob/main/tech-committee-charter.md) +and relevant repository maintainers, supported by tooling provided by the +[SIG Security](https://github.com/open-telemetry/sig-security), are responsible +for responding to the incident organizing the entire response including internal +communication and external disclosure. + +## Supported Versions + +The OTel project provides community support only for the last overall minor +version: bug fixes are released either as part of the next minor version or as +an on-demand patch version. Independent of which version is next, all patch +versions are cumulative, meaning that they represent the state of our `main` +branch at the moment of the release. For instance, if the latest version is +0.10.0, bug fixes are released either as part of 0.11.0 or 0.10.1. + +Security fixes are given priority and might be enough to cause a new version to +be released. Each repository is entitled to establish their own complementary +processes. SIG Security in conjunction with the TC can advise in case +clarifications are required. + +## Disclosures + +### Private Disclosure Processes + +In order for the vulnerability reports to reach maintainers as soon as possible, +the preferred way is to use the `Report a vulnerability` button on the +`Security` tab in the respective GitHub repository. It creates a private +communication channel between the reporter and the maintainers. + +If you are absolutely unable to or have strong reasons not to use GitHub +reporting workflow, please reach out to the Technical Committee using +[cncf-opentelemetry-tc@lists.cncf.io](mailto:cncf-opentelemetry-tc@lists.cncf.io) +and we will provide instruction on how to report the vulnerability using an +encrypted message, if desired. + +### Public Disclosure Processes + +If you know of a publicly disclosed security vulnerability please IMMEDIATELY +email +[cncf-opentelemetry-tc@lists.cncf.io](mailto:cncf-opentelemetry-tc@lists.cncf.io) +to inform the Security Response Committee (SRC) about the vulnerability so they +may start the patch, release, and communication process. Please include any +relevant information about current public exploitations of this vulnerability if +known to help with scoring and prioritization. + +The TC should receive the message and re-direct it to the relevant repository +maintainers for ownership. If possible the repository maintainers will engage +and ask the person making the public report if the issue can be handled via a +private disclosure process. If the reporter denies the request, the repository +maintainers will move swiftly with the fix and release process. In extreme cases +you can ask GitHub to delete the issue but this generally isn't necessary and is +unlikely to make a public disclosure less damaging. + +## Patch, Release, and Public Communication + +### Fix Team Organization + +The Fix Team is made up of the relevant repository maintainers. + +### TC Role + +- A member of the TC will need to review the proposed CVSS score and severity + from the Fix Team +- Acknowledge when a proposed fix is completed + +### Fix Development Process + +All of the timelines below are suggestions that assume a Private Disclosure and +that the report is accepted as valid. + +#### Initial Incident Response + +- The TC is notified of an incident and the relevant repository maintainers are + added automatically using a Zapier workflow as the Fix Team to the issue. +- The Fix Team acknowledges the incident to the reporter, asks for further + details if necessary, and begins mitigation planning. +- The Fix Team confirms with the reporter if the incident is valid and requires + a fix. +- The Fix Team creates a temporary private branch to start work on the fix. +- The Fix Team will create a + [CVSS](https://www.first.org/cvss/specification-document) Base score using the + [CVSS Calculator](https://www.first.org/cvss/calculator/3.1) and ping the TC + GitHub team, `@open-telemetry/technical-committee` for confirmation. +- The Fix Team will request a CVE from GitHub and follow up with the reporter. +- The Fix Team publishes the CVE to the GitHub Security Advisory Database for + user notification. + +#### Incident Mitigation + +The incident mitigation timeline depends on the severity of the incident and +repository release cadence. + +- The Fix Team will ping + [@open-telemetry/technical-committee](https://github.com/orgs/open-telemetry/teams/technical-committee) + to alert them that work on the fix branch is complete once there are LGTMs on + all commits in the temporary private fork created for the GitHub Security + Advisory. +- The updated version is released with the fix. +- The incident is published to the GitHub Security Advisory Database and + affected users are automatically notified using GitHub security alerts. + +### Fix Disclosure Process + +OTel relies on GitHub tooling to notify the affected repositories and publish a +security advisory. GitHub will publish the CVE to the CVE List, broadcast the +Security Advisory via the GitHub Advisory Database, and send security alerts to +all repositories that use the package and have alerts on. The CVE will also be +added to the [OTel website's CVE feed](../cve/). + +#### Fix Release Day + +The Fix Team as repository owners will release an updated version and optionally +notify their communities via Slack. + +## Severity + +The Fix Team evaluates vulnerability severity on a case-by-case basis, guided by +CVSS 3.1 and is subject to TC review. diff --git a/static/refcache.json b/static/refcache.json index 8ac6800dbc4c..cf1b0d8ab00e 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -3787,6 +3787,10 @@ "StatusCode": 200, "LastSeen": "2023-06-30T09:42:42.642961-04:00" }, + "https://github.com/orgs/open-telemetry/teams/technical-committee": { + "StatusCode": 200, + "LastSeen": "2023-12-16T12:14:31.82439-08:00" + }, "https://github.com/orishoshan": { "StatusCode": 200, "LastSeen": "2023-11-16T15:02:08.644309-05:00" @@ -6163,6 +6167,14 @@ "StatusCode": 200, "LastSeen": "2023-07-07T17:13:23.688913+02:00" }, + "https://www.first.org/cvss/calculator/3.1": { + "StatusCode": 200, + "LastSeen": "2023-12-13T15:40:04.523841-08:00" + }, + "https://www.first.org/cvss/specification-document": { + "StatusCode": 200, + "LastSeen": "2023-12-13T15:40:03.612009-08:00" + }, "https://www.flipt.io/docs/configuration/observability#tracing": { "StatusCode": 206, "LastSeen": "2023-10-05T19:46:12.968304+02:00"