Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: SECURITY_RELEASE_PROCESS.md

Emissary-ingress is a large, growing community comprising maintainers, volunteers, and users. The Emissary community has adopted this security disclosure and response policy to ensure we responsibly handle critical issues. This disclosure process draws heavily from that of the Envoy Proxy -- many thanks! 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 Emissary Security Team (EMST) is responsible for organizing the entire response including internal communication and external disclosure but will need help from relevant developers to successfully run this process. The initial Emissary Security Team will consist of all , with communications initially handled via email to . In the future, we may change the membership of the EMST, or the communication mechanism. The Emissary community asks that all suspected vulnerabilities be privately and responsibly disclosed via email to . If you know of a publicly disclosed security vulnerability please IMMEDIATELY email to inform the Emissary Security Team (EMST) about the vulnerability so they may start the patch, release, and communication process. If possible the EMST will ask the person making the public report if the issue can be handled via a private disclosure process (for example if the full exploit details have not yet been published). If the reporter denies the request for private disclosure, the EMST will move swiftly with the fix and release process. In extreme cases GitHub can be asked to delete the issue but this generally isn't necessary and is unlikely to make a public disclosure less damaging. For each vulnerability a member of the Emissary Security Team (EMST) will volunteer to lead coordination with the "Fix Team" and is responsible for sending disclosure emails to the rest of the community. This lead will be referred to as the "Fix Lead." The role of Fix Lead should rotate round-robin across the EMST. Note that, at present, it is likely that the Fix Team and the EMST are identical (all maintainers). The EMST may decide to bring in additional contributors for added expertise depending on the area of the code that contains the vulnerability. All of the timelines below are suggestions and assume a private disclosure. The Fix Lead drives the schedule using their best judgment based on severity and development time. If the Fix Lead is dealing with a public disclosure all timelines become ASAP (assuming the vulnerability has a CVSS score >= 4; see below). If the fix relies on another upstream project's disclosure timeline, that will adjust the process as well. We will work with the upstream project to fit their timeline and best protect our

If the vulnerability affects a supported version (typically the most recent minor release, e.g. 1.13), then the full security release process described in this document will be activated. A patch release will be created (e.g. 1.13.10) with the fix, and the fix will also be made on `master`. If a vulnerability affects only `master`, the fix will be incorporated into the next release. Security vulnerabilities that warrant action per this process will be considered release blockers. If a security vulnerability affects only unsupported versions but not `master` or a supported version, no new release will be created. The vulnerability will be described as a GitHub issue, and a CVE will be filed if warranted by severity. We consider vulnerabilities leading to the compromise of data confidentiality or integrity to be our highest priority concerns. Availability, in particular in areas relating to DoS and resource exhaustion, is also a serious security concern for Emissary operators, given Emissary's common placement at the edge. In general, we will fix well-known resource consumption issues (e.g. high CPU or memory usage) in the open, using our normal process for bugfixes. We will activate the security process for disclosures that appear to present a significantly higher risk profile than simple "usage", for example: A "query of death", where a single client query can crash Emissary entirely. Highly asymmetric resource exhaustion attacks, where very little traffic can cause resource exhaustion, e.g. that delivered by a single client. Note that while we generally consider the installation mechanisms provided by the Emissary-ingress project (our published Helm charts and manifests) "safe", there is no way to guarantee that the published installation mechanisms will always work in any specific setting. Ultimately, Emissary operators need to understand the impact of their own configurations, especially in larger installations. These steps should be completed within the first 24 hours of disclosure. The Fix Lead will work quickly to identify relevant engineers from the affected projects and packages and CC those engineers into the disclosure thread. These selected developers are the Fix Team. Work toward the fix will take place in private "security repos". The Fix Lead is responsible for arranging for the Fix Team to have access to the private security repos (cf GitHub's documentation on .) These steps should be completed within the 1-7 days of Disclosure. The Fix Lead and the Fix Team will create a using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the calculated CVSS; it is better to move quickly than to spend time making the CVSS perfect. The Fix Team will work per the usual , including fix branches, PRs, reviews,

The Fix Team will notify the Fix Lead that work on the fix branch is complete once the fix is present in the relevant release branch(es) in the private security repo. If the CVSS score is under 4.0 () 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 secalert mailing list. 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. Disclosure of Forthcoming Fix to Users (Completed within 1-7 days of Disclosure) The Fix Lead will announce in `#emissary` and `#general` on the informing users that a security vulnerability has been disclosed and that a fix will be made available at a specific date and time in the future via this list. This time is the Release Date. The Fix Lead will include any mitigating steps users can take until a fix is available. The communication to users should be actionable. They should know when to block time to apply patches, understand exact mitigation steps, etc. Fix Release Day (Completed within 1-21 days of Disclosure) The Fix Lead will PR the fix from the private security repo into . Maintainers will merge this PR as quickly as possible. Changes shouldn't be made to the commits even for a typo in the CHANGELOG as this will change the git SHA of the commits leading to confusion and potentially conflicts as the fix is cherry-picked around branches. The Fix Lead will request a CVE from and include the CVSS and release details. The Fix Lead will announce in `#emissary` and `#general` on the stating the new releases, the CVE number, and the relevant merged PRs to get wide distribution and user action. As much as possible this message should be actionable and include links on how to apply the fix to user's environments; this can include links to external distributor documentation. The Fix Lead will remove the Fix Team from the private security repo. These steps should be completed 1-3 days after the Release Date. The retrospective process . The Fix Lead will send a retrospective of the process to and to `#emissary-dev` on the , giving details on everyone involved, the timeline of the process, links to PRs that introduced the issue (if relevant), and any critiques of the response and release process. Maintainers and Fix Team are also encouraged to send their own feedback on the process to , or to discuss it in `#emissary-dev` on the . Honest critique is the only way we will improve as a community.