Security Release Process

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!

Emissary Security Team (EMST)

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 maintainers, with communications initially handled via email to [email protected]. In the future, we may change the membership of the EMST, or the communication mechanism.

Private Disclosure Process

The Emissary community asks that all suspected vulnerabilities be privately and responsibly disclosed via email to [email protected].

Public Disclosure Processes

If you know of a publicly disclosed security vulnerability please IMMEDIATELY email [email protected] 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.

Patch, Release, and Public Communication

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 users.

Released versions and the master branch

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.

Confidentiality, integrity and availability

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.

Fix Team Organization

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 duplicating a repository.)

Fix Development Process

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

• The Fix Lead and 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 to spend time making the CVSS perfect.
• The Fix Team will work per the usual Emissary Development Process, including fix branches, PRs, reviews, etc.
• 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 (a low severity score) 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.

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.

Disclosure of Forthcoming Fix to Users (Completed within 1-7 days of Disclosure)

• The Fix Lead will announce in #emissary and #general on the Emissary Slack 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 the Emissary repo.
• 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 DWF and include the CVSS and release details.
• The Fix Lead will announce in #emissary and #general on the Emissary Slack 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.

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] and to #emissary-dev on the Emissary Slack, 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 [email protected], or to discuss it in #emissary-dev on the Emissary Slack. Honest critique is the only way we will improve as a community.