update security policy and contacts (#1580)

Signed-off-by: 守辰 <shouchen.zz@alibaba-inc.com>
This commit is contained in:
Zhen Zhang 2024-04-16 20:36:50 +08:00 committed by GitHub
parent 142458151b
commit 61d1b42028
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
8 changed files with 286 additions and 12 deletions

View File

@ -98,6 +98,10 @@ OpenKruise (官网: [https://openkruise.io](https://openkruise.io)) 是CNCF([Clo
- Bi-weekly Community Meeting (*English*): TODO
- [进入会议(zoom)](https://us02web.zoom.us/j/87059136652?pwd=NlI4UThFWXVRZkxIU0dtR1NINncrQT09)
## 安全
汇报安全漏洞请通过邮箱kubernetes-security@service.aliyun.com, 更多安全细节并参见[SECURITY.md](SECURITY.md)
## License
Kruise is licensed under the Apache License, Version 2.0. See [LICENSE](./LICENSE.md) for the full license text.

View File

@ -99,6 +99,9 @@ Active communication channels:
- Bi-weekly Community Meeting (*English*): TODO
- [Meeting Link(zoom)](https://us02web.zoom.us/j/87059136652?pwd=NlI4UThFWXVRZkxIU0dtR1NINncrQT09)
## Security
Please report vulnerabilities by email to kubernetes-security@service.aliyun.com. Also see our [SECURITY.md](SECURITY.md) file for details.
## License
Kruise is licensed under the Apache License, Version 2.0. See [LICENSE](./LICENSE.md) for the full license text.

View File

@ -9,9 +9,10 @@ Here's an overview:
| Version | Supported |
| ------- | ------------------- |
| 0.10.x | :white_check_mark: |
| 0.9.x | :white_check_mark: |
| < 0.9 | :x: |
| 1.16.x | :white_check_mark: |
| 1.15.x | :white_check_mark: |
| 1.14.x | :white_check_mark: |
| < 1.14 | :x: |
## Prevention
@ -26,16 +27,9 @@ Kruise maintainers are working to improve our prevention by adding additional me
We strive to ship secure software, but we need the community to help us find security breaches.
In case of a confirmed breach, reporters will get full credit and can be keep in the loop, if
preferred.
In case of a confirmed breach, reporters will get full credit and can be keep in the loop, if preferred.
### Private Disclosure Processes
We ask that all suspected vulnerabilities be privately and responsibly disclosed by [contacting our maintainers](mailto:cncf-openkruise-maintainers@lists.cncf.io).
### Public Disclosure Processes
If you know of a publicly disclosed security vulnerability please IMMEDIATELY email the [OpenKruise maintainers](mailto:cncf-openkruise-maintainers@lists.cncf.io) to inform about the vulnerability so they may start the patch, release, and communication process.
DO NOT CREATE AN ISSUE to report a security problem. Instead, please send an email to kubernetes-security@service.aliyun.com
### Compensation

10
SECURITY_CONTACTS.md Normal file
View File

@ -0,0 +1,10 @@
Defined below are the security persons of contact for this project. If you have questions regarding the triaging and handling of incoming problems, they may be contacted.
The following security contacts have agreed to abide by the Embargo Policy $LINK and will be removed and replaced if found to be in violation of that agreement.
DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, USE THE INSTRUCTIONS AT [SECURITY.md](SECURITY.md)
Security Contacts:
* [Zhen Zhang](mailto:shouchen.zz@alibaba-inc.com)
* [Mingshan Zhao](mailto:liheng.zms@alibaba-inc.com)

84
SECURITY_RESPONSE.md Normal file
View File

@ -0,0 +1,84 @@
# Incident response
This serves to define how potential security issues should be triaged, how
confirmation occurs, providing the notification, and issuing a security advisory
as well as patch/release.
## Triage
### Identify the problem
Triaging issues allows maintainers to focus resources on the most critically
impacting problems. Potential security risks should be evaluated against the
following information:
* Which component(s) of the project is impacted?
* What kind of problem is this?
* privilege escalation
* credential access
* code execution
* exfiltration
* lateral movement
* How complex is the problem?
* Is user interaction required?
* What privileges are required for this problem to occur?
* admin
* general
* What is the potential impact or consequence of the problem?
* Does an exploit exist?
Any potential problem that has an exploit, permits privilege escalation, is
simple, and does not require user interaction should be evaluated immediately.
[CVSS Version 3.1](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) can be
a helpful tool in evaluating the criticality of reported issues.
### Acknowledge receipt of the problem
Respond to the reporter and notify them that you have received and begun reviewing the problem. Remind them of the [embargo policy](https://github.com/cncf/tag-security/blob/231b87f371274b2d68def2c6a35a719210836191/project-resources/templates/embargo-policy.md), and provide them
information on who to contact/follow-up with if they have questions. Estimate when they can expect to receive an update. Create a calendar reminder to contact them again by that date to provide an update.
### Replicate the problem
Follow the instructions relayed in the problem. If the instructions are
insufficient, contact the reporter and ask for more information.
If the problem cannot be replicated, re-engage the reporter, let them know it
cannot be replicated, and work with them to find a remediation.
If the problem can be replicated, re-evaluate the criticality of the problem, and
begin working on a remediation. Begin a draft security advisory.
Notify the reporter you were able to replicate the problem and have begun working
on a fix. Remind them of the [embargo policy](https://github.com/cncf/tag-security/blob/231b87f371274b2d68def2c6a35a719210836191/project-resources/templates/embargo-policy.md). If necessary, notify them of an
extension (only for very complex problems where remediation cannot be issued
within the project's specified window).
#### Request a CVE number
If a CVE has already been provided, be sure to include it on the advisory. If
one has not yet been created, [GitHub functions as a CVE Numbering Authority](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories#cve-identification-numbers)
and allows you to request one as part of the security advisory process. Provide
all required information and as much optional information as we can. The CVE
number is shown as reserved with no further details until notified it has been
published.
## Notification
Once the problem has been replicated and a remediation is in place, notify
subscribed parties with a security bulletin (use [this template](https://github.com/cncf/tag-security/blob/231b87f371274b2d68def2c6a35a719210836191/project-resources/templates/embargo.md)) and the expected publishing date.
## Publish and release
Once a CVE number has been assigned, publish and release the updated
version/patch. Be sure to notify the CVE group when published so the CVE details
are searchable. Be sure to give credit to the reporter by *[editing the security
advisory](https://docs.github.com/en/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)*
as they took the time to notify and work with you on the problem!
### Issue a security advisory
Follow the instructions from [GitHub to publish the security advisory previously
drafted](https://docs.github.com/en/github/managing-security-vulnerabilities/publishing-a-security-advisory).
For more information on security advisories, please refer to the [GitHub
Article](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories).

30
embargo-policy.md Normal file
View File

@ -0,0 +1,30 @@
# Embargo Policy
This policy forbids members of this project's [security contacts](SECURITY_CONTACTS.md) and others
defined below from sharing information outside of the security contacts and this
listing without need-to-know and advance notice.
The information members and others receive from the list defined below must:
* not be made public,
* not be shared,
* not be hinted at
* must be kept confidential and close held
Except with the list's explicit approval. This holds true until the public
disclosure date/time that was agreed upon by the list.
If information is inadvertently shared beyond what is allowed by this policy,
you are REQUIRED to inform the security contacts of exactly what
information leaked and to whom. A retrospective will take place after the leak
so we can assess how to not make this mistake in the future.
Violation of this policy will result in the immediate removal and subsequent
replacement of you from this list or the Security Contacts.
## Disclosure Timeline
This project sustains 15 days disclosure timeline to ensure we provide a
quality, tested release. On some occasions, we may need to extend this timeline
due to complexity of the problem, lack of expertise available, or other reasons.
Submitters will be notified if an extension occurs.

60
embargo.md Normal file
View File

@ -0,0 +1,60 @@
# Notice of Embargo
This is an embargoed notification that a vulnerability has been discovered in
<!-- TODO: $PROJECT -->. This notice has been sent to subscribed distributors and service
providers in order to allow for timely patching. You are receiving this
notification as you have agreed to abide by the embargo policy (<!-- TODO: $LINK -->) on this
project. Do not forward this information to other parties without complying with
the instructions of the embargo policy.
## Summary
*2-3 sentences describing the vulnerability using technical details. This should
only contain enough information to be able to make a quick determination of what
the vulnerability is about.*
### CVE
#### $CVE-NUMBER
### Versions
#### $VERSION
### Severity - [low, medium, high, critical]
*Provide an attack scenario or other information to explain the risk associated.
Use details gathered from the triage.*
### Proof of Concept
*Provide exact code or command lines in order to offer usable, precise, and
repeatable methods for a subscriber to reproduce the problem and test fixes and
mitigations.*
### Remediation and Mitigation
*Provide information on the known remediation or planned patch. Be sure to list
when it will be available or links to where the patch will be available.*
### Additional information
*If you have additional information to provide, be sure to include it here.*
## Timeline
**Date reported:** DD MMM YYYY
**Date fixed:** DD MMM YYYY
**Date to be disclosed:** DD MMM YYYY
### Public disclosure date: $DATE $TIME $TIMEZONE
**Do not:**
* make this problem public,
* issue communications hinting at or regarding this,
* share this with others,
* issue public patches before the disclosure date
This list will be notified immediately if the disclosure date is at risk or
changes. Questions should be directed to the security contacts <!-- TODO: $LINK -->.

89
incident-response.md Normal file
View File

@ -0,0 +1,89 @@
# Incident response
This serves to define how potential security issues should be triaged, how
confirmation occurs, providing the notification, and issuing a security advisory
as well as patch/release.
## Triage
### Identify the problem
Triaging problems allows maintainers to focus resources on the most critically
impacting problems. Potential security problems should be evaluated against the
following information:
* Which component(s) of the project is impacted?
* What kind of problem is this?
* privilege escalation
* credential access
* code execution
* exfiltration
* lateral movement
* <!-- TODO: $CONTEXT_SPECIFIC_ISSUE -->
* How complex is the problem?
* Is user interaction required?
* What privileges are required for this problem to occur?
* admin
* general
* <!-- TODO: $CONTEXT_SPECIFIC_PRIVILEGE -->
* What is the potential impact or consequence of the problem?
* Does an exploit exist?
Any potential problem that has an exploit, permits privilege escalation, is
simple, and does not require user interaction should be evaluated immediately.
[CVSS Version 3.1](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) can be
a helpful tool in evaluating the criticality of reported problems.
### Acknowledge receipt of the problem
Respond to the reporter and notify them you have received the problem and have
begun reviewing it. Remind them of the embargo policy, and provide them
information on who to contact/follow-up with if they have questions. Estimate a
time frame that they can expect to receive an update on the problem. Create a
calendar reminder to contact them again by that date to provide an update.
### Replicate the problem
Follow the instructions relayed in the problem. If the instructions are
insufficient, contact the reporter and ask for more information.
If the problem cannot be replicated, re-engage the reporter, let them know it
cannot be replicated, and work with them to find a remediation.
If the problem can be replicated, re-evaluate the criticality of the problem, and
begin working on a remediation. Begin a draft security advisory.
Notify the reporter you were able to replicate the problem and have begun working
on a fix. Remind them of the embargo policy. If necessary, notify them of an
extension (only for very complex problems where remediation cannot be issued
within the project's specified window).
#### Request a CVE number
If a CVE has already been provided, be sure to include it on the advisory. If
one has not yet been created, [GitHub functions as a CVE Numbering Authority](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories#cve-identification-numbers)
and allows you to request one as part of the security advisory process. Provide
all required information and as much optional information as we can. The CVE
number is shown as reserved with no further details until notified it has been
published.
## Notification
Once the problem has been replicated and a remediation is in place, notify
subscribed parties with a security bulletin and the expected publishing date.
## Publish and release
Once a CVE number has been assigned, publish and release the updated
version/patch. Be sure to notify the CVE group when published so the CVE details
are searchable. Be sure to give credit to the reporter by *[editing the security
advisory](https://docs.github.com/en/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)*
as they took the time to notify and work with you on the problem!
### Issue a security advisory
Follow the instructions from [GitHub to publish the security advisory previously
drafted](https://docs.github.com/en/github/managing-security-vulnerabilities/publishing-a-security-advisory).
For more information on security advisories, please refer to the [GitHub
Article](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories).