1# Security Release Process
2
3Emissary-ingress is a large, growing community comprising maintainers, volunteers, and users.
4The Emissary community has adopted this security disclosure and response policy to ensure we
5responsibly handle critical issues.
6
7This disclosure process draws heavily from that of the Envoy Proxy -- many thanks!
8
9## Emissary Security Team (EMST)
10
11Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this
12process is to reduce the total time users are vulnerable to publicly known exploits.
13
14The Emissary Security Team (EMST) is responsible for organizing the entire response including internal
15communication and external disclosure but will need help from relevant developers to successfully
16run this process.
17
18The initial Emissary Security Team will consist of all [maintainers](MAINTAINERS.md), with communications
19initially handled via email to [secalert@datawire.io](mailto:secalert@datawire.io). In the future,
20we may change the membership of the EMST, or the communication mechanism.
21
22## Private Disclosure Process
23
24The Emissary community asks that all suspected vulnerabilities be privately and responsibly disclosed
25via email to [secalert@datawire.io](mailto:secalert@datawire.io).
26
27## Public Disclosure Processes
28
29If you know of a publicly disclosed security vulnerability please IMMEDIATELY email
30[secalert@datawire.io](mailto:secalert@datawire.io) to inform the Emissary Security Team (EMST)
31about the vulnerability so they may start the patch, release, and communication process.
32
33If possible the EMST will ask the person making the public report if the issue can be handled via a
34private disclosure process (for example if the full exploit details have not yet been published). If
35the reporter denies the request for private disclosure, the EMST will move swiftly with the fix and
36release process. In extreme cases GitHub can be asked to delete the issue but this generally isn't
37necessary and is unlikely to make a public disclosure less damaging.
38
39## Patch, Release, and Public Communication
40
41For each vulnerability a member of the Emissary Security Team (EMST) will volunteer to lead
42coordination with the "Fix Team" and is responsible for sending disclosure emails to the rest of
43the community. This lead will be referred to as the "Fix Lead."
44
45The role of Fix Lead should rotate round-robin across the EMST.
46
47Note that, at present, it is likely that the Fix Team and the EMST are identical (all maintainers).
48The EMST may decide to bring in additional contributors for added expertise depending on the area
49of the code that contains the vulnerability.
50
51All of the timelines below are suggestions and assume a private disclosure. The Fix Lead drives the
52schedule using their best judgment based on severity and development time. If the Fix Lead is
53dealing with a public disclosure all timelines become ASAP (assuming the vulnerability has a CVSS
54score >= 4; see below). If the fix relies on another upstream project's disclosure timeline, that
55will adjust the process as well. We will work with the upstream project to fit their timeline and
56best protect our users.
57
58### Released versions and the `master` branch
59
60If the vulnerability affects a supported version (typically the _most recent_ minor release, e.g.
611.13), then the full security release process described in this document will be activated. A
62patch release will be created (e.g. 1.13.10) with the fix, and the fix will also be made on
63`master`.
64
65If a vulnerability affects only `master`, the fix will be incorporated into the next release.
66Security vulnerabilities that warrant action per this process will be considered release
67blockers.
68
69If a security vulnerability affects only unsupported versions but not `master` or a supported
70version, no new release will be created. The vulnerability will be described as a GitHub issue,
71and a CVE will be filed if warranted by severity.
72
73### Confidentiality, integrity and availability
74
75We consider vulnerabilities leading to the compromise of data confidentiality or integrity to be
76our highest priority concerns. Availability, in particular in areas relating to DoS and resource
77exhaustion, is also a serious security concern for Emissary operators, given Emissary's common
78placement at the edge.
79
80In general, we will fix well-known resource consumption issues (e.g. high CPU or memory usage) in
81the open, using our normal process for bugfixes. We will activate the security process for
82disclosures that appear to present a significantly higher risk profile than simple "usage", for
83example:
84
85* A "query of death", where a single client query can crash Emissary entirely.
86* Highly asymmetric resource exhaustion attacks, where very little traffic can cause resource
87 exhaustion, e.g. that delivered by a single client.
88
89Note that while we generally consider the installation mechanisms provided by the Emissary-ingress
90project (our published Helm charts and manifests) "safe", there is no way to guarantee that the
91published installation mechanisms will always work in any specific setting. Ultimately, Emissary
92operators need to understand the impact of their own configurations, especially in larger
93installations.
94
95### Fix Team Organization
96
97These steps should be completed within the first 24 hours of disclosure.
98
99- The Fix Lead will work quickly to identify relevant engineers from the affected projects and
100 packages and CC those engineers into the disclosure thread. These selected developers are the
101 Fix Team.
102- Work toward the fix will take place in private "security repos". The Fix Lead is responsible
103 for arranging for the Fix Team to have access to the private security repos (cf GitHub's
104 documentation on [duplicating a repository](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/duplicating-a-repository).)
105
106### Fix Development Process
107
108These steps should be completed within the 1-7 days of Disclosure.
109
110- The Fix Lead and the Fix Team will create a
111 [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS
112 Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the
113 calculated CVSS; it is better to move quickly than to spend time making the CVSS perfect.
114- The Fix Team will work per the usual [Emissary Development Process](DEVELOPING.md), including
115 fix branches, PRs, reviews, etc.
116- The Fix Team will notify the Fix Lead that work on the fix branch is complete once the fix is
117 present in the relevant release branch(es) in the private security repo.
118
119If the CVSS score is under 4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5))
120the Fix Team can decide to slow the release process down in the face of holidays, developer
121bandwidth, etc. These decisions must be discussed on the secalert mailing list.
122
123### Fix Disclosure Process
124
125With the fix development underway, the Fix Lead needs to come up with an overall communication plan
126for the wider community. This Disclosure process should begin after the Fix Team has developed a fix
127or mitigation so that a realistic timeline can be communicated to users.
128
129**Disclosure of Forthcoming Fix to Users** (Completed within 1-7 days of Disclosure)
130
131- The Fix Lead will announce in `#emissary` and `#general` on the [Emissary Slack](https://a8r.io/slack)
132 informing users that a security vulnerability has been disclosed and that a fix will be made
133 available at a specific date and time in the future via this list. This time is the Release Date.
134- The Fix Lead will include any mitigating steps users can take until a fix is available.
135
136The communication to users should be actionable. They should know when to block time to apply
137patches, understand exact mitigation steps, etc.
138
139**Fix Release Day** (Completed within 1-21 days of Disclosure)
140
141- The Fix Lead will PR the fix from the private security repo into [the Emissary repo](https://github.com/emissary-ingress/emissary).
142- Maintainers will merge this PR as quickly as possible. Changes shouldn't be made to the commits even
143 for a typo in the CHANGELOG as this will change the git SHA of the commits leading to confusion and
144 potentially conflicts as the fix is cherry-picked around branches.
145- The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation)
146 and include the CVSS and release details.
147- The Fix Lead will announce in `#emissary` and `#general` on the [Emissary Slack](https://a8r.io/slack)
148 stating the new releases, the CVE number, and the relevant merged PRs to get wide distribution and
149 user action. As much as possible this message should be actionable and include links on how to apply
150 the fix to user's environments; this can include links to external distributor documentation.
151- The Fix Lead will remove the Fix Team from the private security repo.
152
153### Retrospective
154
155These steps should be completed 1-3 days after the Release Date. The retrospective process
156[should be blameless](https://landing.google.com/sre/book/chapters/postmortem-culture.html).
157
158- The Fix Lead will send a retrospective of the process to [secalert@datawire.io](mailto:secalert@datawire.io)
159 and to `#emissary-dev` on the [Emissary Slack](https://a8r.io/slack), giving details on everyone
160 involved, the timeline of the process, links to PRs that introduced the issue (if relevant),
161 and any critiques of the response and release process.
162- Maintainers and Fix Team are also encouraged to send their own feedback on the process to
163 [secalert@datawire.io](mailto:secalert@datawire.io), or to discuss it in `#emissary-dev`
164 on the [Emissary Slack](https://a8r.io/slack). Honest critique is the only way we will
165 improve as a community.
View as plain text