This document describes the security policy that applies to this repository.

Security updates for this repository will be applied the most recent major version and its minor versions.

For example, if 2.2.0 is the latest version:

However, if the repository has not made a stable release (e.g. the latest release is < v1.0.0) then only the latest minor version will be patched.

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.

We ask that all suspected vulnerabilities be privately and responsibly disclosed via the private disclosure process outlined above.

Fixes may be developed and tested by in a temporary private fork that is private from the general public if deemed necessary.

Vulnerabilities are disclosed publicly as GitHub Security Advisories.

A public disclosure date is negotiated with the report submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The time frame for disclosure is from immediate (especially if it's already publicly known) to several weeks. For a vulnerability with a straightforward mitigation, we expect the report date to disclosure date to be on the order of 14 days.

If you know of a publicly disclosed security vulnerability please IMMEDIATELY report the vulnerability so that the patch, release, and communication process can be started as early as possible.

If the reporter does not go through the private disclosure process, the fix, and release process will proceed as swiftly as possible. 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.

Once a fix is available, it will be released, the GitHub Security Advisory made public, and the fix release announced via project communication channels. Security releases will be clearly marked as a security release and include information on which vulnerabilities were fixed. As much as possible this announcement should be actionable, and include any mitigating steps users can take prior to upgrading to a fixed version.

Fixes will be applied in patch releases to all supported versions and all fixed vulnerabilities will be noted in the CHANGELOG.

Vulnerability severity is evaluated on a case-by-case basis, guided by CVSS 3.1.

We aim to reduce the number of security issues through several general security-conscious development practices including the use of unit-tests, end-to-end (e2e) tests, static, and dynamic analysis tools, and use of memory-safe languages.

We aim to fix issues discovered by analysis tools as quickly as possible. We prefer to add these tools to GitHub status checks on pull requests so that issues are never added to the code in the first place.

In general, we observe the following security-conscious practices during development (This is not an exhaustive list).

• Where possible, all pull requests are reviewed by at least one CODEOWNER that is not a pull request author.
• All unit and linter status checks must pass before a pull request is merged. See the status checks section of the Contributor Guide for more information.
• All releases include no known test or linter failures.
• We refrain from using memory-unsafe languages (e.g. C, C++) or memory-unsafe use of languages that are memory-safe by default (e.g. the Go unsafe package). Use of these modules is restricted by static analysis tools.

Vulnerabilities can be reported privately via GitHub's Security Advisories feature.

Please see Privately reporting a security vulnerability for more information on how to submit a vulnerability using GitHub's interface.