update security policy and contacts (#1580)

Signed-off-by: 守辰 <[email protected]>

README-zh_CN.md

@@ -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)
 
+## 安全
+
+汇报安全漏洞请通过邮箱[email protected], 更多安全细节并参见[SECURITY.md](SECURITY.md)
+
 ## License
 
 Kruise is licensed under the Apache License, Version 2.0. See [LICENSE](./LICENSE.md) for the full license text.

README.md

@@ -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 [email protected]. 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.

SECURITY.md

@@ -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:[email protected]).
-
-### Public Disclosure Processes
-
-If you know of a publicly disclosed security vulnerability please IMMEDIATELY email the [OpenKruise maintainers](mailto:[email protected]) 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 [email protected]
 
 ### Compensation
 

SECURITY_CONTACTS.md

@@ -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:[email protected])
+* [Mingshan Zhao](mailto:[email protected])
+

SECURITY_RESPONSE.md

@@ -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).

embargo-policy.md

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

embargo.md

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

incident-response.md

@@ -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).