forked from rook/rook
This commit updates the readme and docs with the new Rook mailing lists hosted by the CNCF: * cncf-rook-info@lists.cncf.io * cncf-rook-security@lists.cncf.io * cncf-rook-distributors-announce@lists.cncf.io Signed-off-by: Jared Watts <jbw976@gmail.com>
213 lines
11 KiB
Markdown
213 lines
11 KiB
Markdown
# Security Release Process
|
|
|
|
Rook is a large growing community of storage providers, contributors, and users. The Rook community
|
|
has adopted this security disclosure and response policy to ensure we responsibly handle critical
|
|
issues.
|
|
|
|
This policy is adapted from the policies of the following CNCF projects:
|
|
|
|
* [Envoy](https://github.com/envoyproxy/envoy)
|
|
* [CoreDNS](https://github.com/coredns/coredns)
|
|
|
|
The Rook community credits and appreciates the example and security best practices that they have
|
|
published openly.
|
|
|
|
## Security Audit
|
|
|
|
A third party security audit was performed in December 2019 by [Trail of
|
|
Bits](https://www.trailofbits.com/). The full security report has been published and is [available for
|
|
download](https://drive.google.com/file/d/1rOwrwYmBUpLUm6W5J5rhXvdVit818hWJ/view?usp=sharing).
|
|
|
|
## Product Security Team (PST)
|
|
|
|
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 Product Security Team (PST) is responsible for organizing the entire response including internal
|
|
communication and external disclosure.
|
|
|
|
The initial Product Security Team will consist of the set of maintainers that volunteered. Every
|
|
beta or stable storage provider **MUST** have a representative on the PST.
|
|
|
|
### Mailing lists
|
|
|
|
* [cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io): for any security concerns. Received by Product
|
|
Security Team members, and used by this Team to discuss security issues and fixes.
|
|
* [cncf-rook-distributors-announce@lists.cncf.io](mailto:cncf-rook-distributors-announce@lists.cncf.io): for
|
|
early private information on Security patch releases. See below how Rook distributors can apply
|
|
for this list.
|
|
|
|
## Disclosures
|
|
|
|
### Private Disclosure Processes
|
|
|
|
If you find a security vulnerability or any security related issues, please **DO NOT** file a public
|
|
issue. **Do not** create a Github issue. Instead, send your report privately to
|
|
[cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io). Security reports are greatly appreciated and we will
|
|
publicly thank you for it.
|
|
|
|
Please provide as much information as possible, so we can react quickly. For instance, that could
|
|
include:
|
|
|
|
* Description of the location and potential impact of the vulnerability
|
|
* A detailed description of the steps required to reproduce the vulnerability (POC scripts,
|
|
screenshots, and logs are all helpful to us)
|
|
* Whatever else you think we might need to identify the source of this vulnerability, and possibly
|
|
even a suggested fix for the vulnerability as well
|
|
|
|
### Public Disclosure Processes
|
|
|
|
If you know of a publicly disclosed security vulnerability please **IMMEDIATELY** email
|
|
[cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io) to inform the Product Security Team (PST) about the
|
|
vulnerability so we start the patch, release, and communication process.
|
|
|
|
If possible the PST 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 PST 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
|
|
|
|
For each vulnerability a member of the PST 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 PST.
|
|
|
|
Note that given the current size of the Rook community it is likely that the PST is the same as the
|
|
"Fix team." The PST 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. If the Team is dealing
|
|
with a Public Disclosure all timelines become ASAP. 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.
|
|
|
|
### 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.
|
|
* The Fix Lead will get the Fix Team access to private security repos to develop the fix.
|
|
|
|
### 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](https://www.first.org/cvss/specification-document) 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 making the CVSS perfect.
|
|
* The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs
|
|
on all commits in the private repo from one or more maintainers.
|
|
|
|
If the CVSS score is under 4.0 ([a low severity
|
|
score](https://www.first.org/cvss/specification-document#i5)) 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 [cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io) mailing list.
|
|
|
|
### Fix Disclosure Process
|
|
|
|
With the Fix Development underway the Rook Security Team needs to come up with an overall
|
|
communication plan for the wider community. This Disclosure process should begin after the 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 create a GitHub issue in Rook project to inform users that a security
|
|
vulnerability has been disclosed and that a fix will be made available, with an estimation of the
|
|
Release Date. It 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.
|
|
|
|
**Optional Fix Disclosure to Private Distributors List** (Completed within 1-14 days of Disclosure):
|
|
|
|
* The Fix Lead will make a determination with the help of the Fix Team if an issue is critical
|
|
enough to require early disclosure to distributors. Generally this Private Distributor Disclosure
|
|
process should be reserved for remotely exploitable or privilege escalation issues. Otherwise,
|
|
this process can be skipped.
|
|
* The Fix Lead will email the patches to cncf-rook-distributors-announce@lists.cncf.io so distributors
|
|
can prepare their own release to be available to users on the day of the issue's announcement.
|
|
Distributors should read about the [Private Distributor List](#private-distributor-list) to find
|
|
out the requirements for being added to this list.
|
|
* **What if a distributor breaks embargo?** The PST will assess the damage and may make the call to
|
|
release earlier or continue with the plan. When in doubt push forward and go public ASAP.
|
|
|
|
**Fix Release Day** (Completed within 1-21 days of Disclosure)
|
|
|
|
* The Fix Team will selectively choose all needed commits from the Master branch in order to create
|
|
a new release on top of the current last version released.
|
|
* Release process will be as usual.
|
|
* The Fix Lead will request a CVE from
|
|
[DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) and include the CVSS and
|
|
release details.
|
|
* The Fix Lead will inform all users, devs and integrators, now that everything is public,
|
|
announcing the new releases, the CVE number, and the relevant merged PRs to get wide distribution
|
|
and user action. As much as possible this email should be actionable and include links on how to
|
|
apply the fix to user's environments; this can include links to external distributor
|
|
documentation.
|
|
|
|
## Private Distributor List
|
|
|
|
This list is intended to be used primarily to provide actionable information to multiple distributor
|
|
projects at once. This list is not intended for individuals to find out about security issues.
|
|
|
|
### Embargo Policy
|
|
|
|
The information members receive on cncf-rook-distributors-announce@lists.cncf.io must not be made public,
|
|
shared, nor even hinted at anywhere beyond the need-to-know within your specific team except with
|
|
the list's explicit approval. This holds true until the public disclosure date/time that was agreed
|
|
upon by the list. Members of the list and others may not use the information for anything other than
|
|
getting the issue fixed for your respective distribution's users.
|
|
|
|
Before any information from the list is shared with respective members of your team required to fix
|
|
said issue, they must agree to the same terms and only find out information on a need-to-know basis.
|
|
|
|
In the unfortunate event you share the information beyond what is allowed by this policy, you _must_
|
|
urgently inform the [cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io) mailing list of exactly what
|
|
information leaked and to whom.
|
|
|
|
If you continue to leak information and break the policy outlined here, you will be removed from the
|
|
list.
|
|
|
|
### Contributing Back
|
|
|
|
This is a team effort. As a member of the list you must carry some water. This could be in the form
|
|
of the following:
|
|
|
|
#### Technical
|
|
|
|
* Review and/or test the proposed patches and point out potential issues with them (such as
|
|
incomplete fixes for the originally reported issues, additional issues you might notice, and newly
|
|
introduced bugs), and inform the list of the work done even if no issues were encountered.
|
|
|
|
#### Administrative
|
|
|
|
* Help draft emails to the public disclosure mailing list.
|
|
* Help with release notes.
|
|
|
|
### Membership Criteria
|
|
|
|
To be eligible for the cncf-rook-distributors-announce@lists.cncf.io mailing list, your distribution
|
|
should:
|
|
|
|
1. Be an active distributor of Rook.
|
|
2. Have a user base not limited to your own organization.
|
|
3. Have a publicly verifiable track record up to present day of fixing security issues.
|
|
4. Not be a downstream or rebuild of another distributor.
|
|
5. Be a participant and active contributor in the community.
|
|
6. Accept the [Embargo Policy](#embargo-policy) that is outlined above.
|
|
7. Have someone already on the list vouch for the person requesting membership on behalf of your
|
|
distribution.
|
|
|
|
### Requesting to Join
|
|
|
|
New membership requests are sent to [cncf-rook-security@lists.cncf.io](mailto:cncf-rook-security@lists.cncf.io).
|
|
|
|
In the body of your request please specify how you qualify and fulfill each criterion listed in
|
|
[Membership Criteria](#membership-criteria).
|