diff --git a/.github/ISSUE_TEMPLATE/distributors-application.md b/.github/ISSUE_TEMPLATE/distributors-application.md new file mode 100644 index 0000000..ecf094e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/distributors-application.md @@ -0,0 +1,32 @@ +--- +name: Distributors Application +title: Distributors Application for +about: Apply for membership of volcano-distributors-announce@lists.cncf.io +--- + +_See [Private distributors list](https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md#request-to-join) for additional places the request could be posted._ + +## **Please answer the following questions and provide supporting evidence for meeting the [membership criteria](https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md#membership-criteria).** + +### 1. **Actively monitored security email alias for our project:** + + +### 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 distribution.** + + +### 5. **Be a participant and active contributor in the community.** + + +### 6. **Accept the [Embargo Policy](https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md#embargo-policy).** + + +### 7. **Be willing to [contribute back](https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md#contributing-back).** + + +### 8. **Have someone already on the list vouch for the person requesting membership on behalf of your distribution.** diff --git a/security-team/SECURITY.md b/security-team/SECURITY.md new file mode 100644 index 0000000..8bf00ab --- /dev/null +++ b/security-team/SECURITY.md @@ -0,0 +1,45 @@ +# Security Policy + +## Report a Vulnerability + +We sincerely request you to keep the vulnerability information confidential and responsibly disclose the vulnerabilities. + +To report a vulnerability, please contact the Security Team by sending an email to [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com). + +For full details on the reporting process, including what to include in your report, our response timeline, and specific reporting scenarios, please refer to the complete procedure: +- **[Procedure: Report a Vulnerability](./report-a-vulnerability.md)** + +## Security Release Process + +The Volcano community will strictly handle the reporting vulnerability according to this [procedure](security-release-process.md). The following flowchart shows the vulnerability handling process. + + + +## Security Communications and Lists + +The Volcano Security Team manages several communication channels for security-related matters. + +- **Security Team Membership:** A list of current security team members and their responsibilities is managed in [security-groups.md](./security-groups.md). +- **Private Distributors List:** For information on how Volcano distributors or vendors can apply to join our private disclosure list, including the embargo policy and membership criteria, please see the [private-distributors-list.md](./private-distributors-list.md). + +## Supported Versions + +Volcano versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following [Semantic Versioning](https://semver.org/) terminology. + +The Volcano project maintains release branches for the most recent three minor releases. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. + +Our typical release cadence for minor versions is every 4 months, while patch releases are issued every 1-2 months. Critical bug fixes may cause a more immediate patch release outside of the normal cadence. We also aim to not make releases during major holiday periods. + +See the [Volcano releases page](https://github.com/volcano-sh/volcano/releases) for information on supported versions of Volcano. + +## Dependencies Policy + +Dependencies are evaluated before being introduced to ensure they: + +1) are actively maintained +2) are maintained by trustworthy maintainers +3) are licensed in a way not to impact the Volcano license based on [the CNCF license allowlist](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md). + +These evaluations vary from dependency to dependencies. + +Dependencies are also scheduled for removal if the project has been deprecated or if the project is no longer maintained. Additionally based on license changes we replace dependencies as necessary. \ No newline at end of file diff --git a/security-team/images/Vulnerability-handling-process.PNG b/security-team/images/Vulnerability-handling-process.PNG new file mode 100644 index 0000000..6ababfe Binary files /dev/null and b/security-team/images/Vulnerability-handling-process.PNG differ diff --git a/security-team/images/vulnerability-process-timeline.PNG b/security-team/images/vulnerability-process-timeline.PNG new file mode 100644 index 0000000..381299e Binary files /dev/null and b/security-team/images/vulnerability-process-timeline.PNG differ diff --git a/security-team/private-distributors-list.md b/security-team/private-distributors-list.md new file mode 100644 index 0000000..afdaf8d --- /dev/null +++ b/security-team/private-distributors-list.md @@ -0,0 +1,46 @@ +## Private Distributors List + +This list is used to provide actionable information to multiple distribution vendors at once. This list is not intended for individuals to find out about security issues. + +### Embargo Policy + +Members of the security [volcano-distributors-announce@lists.cncf.io](mailto:volcano-distributors-announce@lists.cncf.io) mailing list must share list information only within their teams, on a need-to-know basis to get the related issue fixed in their distribution. The information members and others receive from the list must not be made public, shared, nor even hinted at otherwise, except with the list's explicit approval. This holds true until the public disclosure date/time that was agreed upon by the list. + +Before any information from the list is shared with respective members of your team required to fix an 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 Security Team](mailto:volcano-security@googlegroups.com) of exactly what information leaked and to whom, as well as the steps that will be taken to prevent future leaks. + +Repeated offenses may lead to the removal from the distributors 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: + +- 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. + +### Membership + +Group membership is managed [here](security-groups.md), under the `Distributors announce` section. + +### Membership Criteria + +To be eligible for the [volcano-distributors-announce@lists.cncf.io](mailto:volcano-distributors-announce@lists.cncf.io) mailing list, your distribution should: + +1. Have an actively monitored security email alias for our project. +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 distribution. +5. Be a participant and active contributor in the Volcano community. +6. Accept the Embargo Policy that is outlined above. +7. Be willing to contribute back. +8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution. + +**Removal**: If your distribution stops meeting one or more of these criteria after joining the list then you will be unsubscribed. + +### Request to Join + +File an issue [here](https://github.com/volcano-sh/community/issues/new?template=distributors-application.md), or send an [email](comms-templates/join-announcement-email-list.md), filling in the criteria template. \ No newline at end of file diff --git a/security-team/report-a-vulnerability.md b/security-team/report-a-vulnerability.md new file mode 100644 index 0000000..b673b80 --- /dev/null +++ b/security-team/report-a-vulnerability.md @@ -0,0 +1,20 @@ +## Report a Vulnerability + +We sincerely request you to keep the vulnerability information confidential and responsibly disclose the vulnerabilities. + +To report a vulnerability, please contact the [Security Team](mailto:volcano-security@googlegroups.com). You can email the Security Team with the security details and the format follows [Volcano bug reports](https://github.com/volcano-sh/volcano/blob/master/.github/ISSUE_TEMPLATE/bug_report.yaml). + +The team will help diagnose the severity of the issue and determine how to address the issue. The reporter(s) can expect a response within 2 business day acknowledging the issue was received. If a response is not received within 2 business day, please reach out to any Security Team member (listed [here](security-groups.md), under the `The Security Team` section) directly to confirm receipt of the issue. We’ll try to keep you informed about our progress throughout the process. + +### When Should I Report a Vulnerability? + +- You think you discovered a potential security vulnerability in Volcano +- You are unsure how a vulnerability affects Volcano + +### When Should I NOT Report a Vulnerability? + +- You need help tuning Volcano components for security +- You need help applying security related updates +- Your issue is not security related + +If you think you discovered a vulnerability in another project that Volcano depends on, and that project has their own vulnerability reporting and disclosure process, please report it directly there. \ No newline at end of file diff --git a/security-team/security-groups.md b/security-team/security-groups.md new file mode 100644 index 0000000..3cd3ac8 --- /dev/null +++ b/security-team/security-groups.md @@ -0,0 +1,30 @@ +## Volcano security mailing lists + +File an issue [here](https://github.com/volcano-sh/community/issues/new?template=distributors-application.md), filling in the criteria template to join [volcano-distributors-announce@lists.cncf.io](mailto:volcano-distributors-announce@lists.cncf.io). + +### Distributors announce + +Email: + +volcano-distributors-announce@lists.cncf.io + +Maintained by [Security Team](#the-security-team). + +Members(Please keep the below list sorted in ascending order): + + +### The Security Team + +Email: + +volcano-security@googlegroups.com + +Owners: + +- Zefeng Wang([@Kevin Wang](https://github.com/kevin-wangzefeng)), [wangzefeng@huawei.com](mailto:wangzefeng@huawei.com) + +Members: + +- Zefeng Wang([@Kevin Wang](https://github.com/kevin-wangzefeng)), [wangzefeng@huawei.com](mailto:wangzefeng@huawei.com) +- Xuzheng Chang([@Monokaix](https://github.com/Monokaix)), [changxuzheng@huawei.com](mailto:changxuzheng@huawei.com) +- Zicong Chen([@JesseStutler](https://github.com/JesseStutler)), [chenzicong4@huawei.com](mailto:chenzicong4@huawei.com) \ No newline at end of file diff --git a/security-team/security-release-process.md b/security-team/security-release-process.md new file mode 100644 index 0000000..b4496c9 --- /dev/null +++ b/security-team/security-release-process.md @@ -0,0 +1,131 @@ +# Security Release Process + +Volcano has always attached great importance to vulnerability management in development and maintenance. The Volcano community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues. + + + +- [The Security Team](#the-security-team) + - [The Security Team Membership](#the-security-team-membership) + - [Joining](#joining) + - [Stepping Down](#stepping-down) + - [Responsibilities](#responsibilities) + - [Associate](#associate) +- [Process a undisclosed vulnerability](#process-a-undisclosed-vulnerability) +- [Process a publicly disclosed Vulnerability](#process-a-publicly-disclosed-vulnerability) +- [Vulnerability handling process](#vulnerability-handling-process) +- [Patch, Release, and Public Communication](#patch-release-and-public-communication) + - [Fix Development Process](#fix-development-process) + - [Fix Disclosure Process](#fix-disclosure-process) +- [Private Distributors List](#private-distributors-list) + + +## The Security Team + +Security is of the highest importance and security vulnerabilities should be handled quickly and sometimes privately. + +The Security Team is responsible for organizing the entire response including internal communication and external disclosure but will need help from relevant developers and release managers to successfully run this process. The Security Team membership is managed [here](security-groups.md), under the `The Security Team` section. + +### The Security Team Membership + +#### Joining + +New potential members to the security team will first fill a minimum of a 3 month rotation in the [Associate](#Associate) role. These individuals will be nominated by individuals on maintainers. + +#### Stepping Down + +Members may step down at anytime. + +#### Responsibilities + +- Members should remain active and responsive. +- Longer leaves of absence should be discussed on a case-by-case basis, and may include an associate temporarily onboarding. +- Members of a role should remove any other members that have not communicated a leave of absence and either cannot be reached for more than 2 months or are not fulfilling their documented responsibilities for more than 2 months. This may be done through a super-majority vote of members. + +##### Associate + +A role for those wishing to join the security team. + +Their rotation will involve the following: + +- lead disclosures that are publicly disclosed or explicitly designated as low sensitivity (often done because of reporter request, a low CVSS score, or design issue that requires long-term refactoring). +- assisting in process improvements, bug bounty administration, audits, or other non-disclosure activities + +## Process a undisclosed vulnerability + +The Volcano Community asks that all suspected vulnerabilities be privately and responsibly disclosed via a recommended way available at [here](report-a-vulnerability.md). + +If the vulnerability is accepted, its remediation priority, and develop remediations (including mitigations, patches/versions, and other risk mitigations) will be determined follow the procedure at [here](#vulnerability-handling-process). + +## Process a publicly disclosed vulnerability + +If you know of a publicly disclosed security vulnerability please IMMEDIATELY email [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com) to inform the Security Team about the vulnerability so they may start the patch, release, and communication process. + +If possible the Security Team will ask the person making the public report if the issue can be handled via a private disclosure process. If the reporter denies the request, the Security Team will move swiftly with the fix and release process. + +## Vulnerability handling process + +The following flowchart shows the vulnerability handling process. we will strictly handle the reporting vulnerability according to this procedure. + + + +## Patch, Release, and Public Communication + +All of the timelines below are suggestions and assume a Private Disclosure. + +The Security Team drives the schedule using their best judgment based on severity, development time, and release manager feedback. 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. + +The following is a timeline of a vulnerability process. + + + +### Fix Development Process + +This part should be completed within the 1-7 days of Disclosure. + +After receiving any suspected vulnerability, the Security Team will discuss the issue with the reporter(s) and Volcano's security advisors to analyze/validate the vulnerability, assess its severity based on its actual impact on Volcano. + +If the vulnerability is accepted, its remediation priority, and develop remediations (including mitigations, patches/versions, and other risk mitigations) will be determined. + +The Security Team will launch a CVE procedures to get a CVSS score and CVE ID. The CVSS v3 adopted by the Volcano community assesses the impact of a vulnerability. + +If the CVSS score is under ~4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5)) or the assessed risk is low the Security Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. + +If the CVSS score is under ~7.0 (a medium severity score), the Security Team may choose to carry out the fix semi-publicly. This means that PRs are made directly in the public volcano-sh/volcano repo, while restricting discussion of the security aspects to private channels. The Security Team will make the determination whether there would be user harm in handling the fix publicly that outweighs the benefits of open engagement with the community. + +Critical and High severity vulnerability fixes will typically receive an out-of-band release. Medium and Low severity vulnerability fixes will be released as part of the next Volcano [patch release](https://github.com/volcano-sh/volcano/releases). + +Note: CVSS is convenient but imperfect. Ultimately, the Security Team has discretion on classifying the severity of a vulnerability. + +### Fix Disclosure Process + +With the Fix Development underway the Security Team needs to come up with an overall communication plan for the wider community. This Disclosure process should begin after the Security Team has developed a Fix or mitigation so that a realistic timeline can be communicated to users. Emergency releases for critical and high severity issues or fixes for issues already made public may affect the below timelines for how quickly or far in advance notifications will occur. + +**Advance Vulnerability Disclosure to Private Distributors List** (Completed within 1-4 weeks prior to public disclosure): + +- The [Private Distributors List](#private-distributors-list) will be given advance notification of any vulnerability that is assigned a CVE, at least 7 days before the planned public disclosure date. The notification will include all information that can be reasonably provided at the time of the notification. This may include patches or links to PRs, proofs of concept or instructions to reproduce the vulnerability, known mitigations, and timelines for public disclosure. Distributors should read about the [Private Distributors List](#private-distributors-list) to find out the requirements for being added to this list. +- **What if a vendor breaks embargo?** The Security Team will assess the damage and will make the call to release earlier or continue with the plan. When in doubt push forward and go public ASAP. + +**Fix Release Day** + +Release process: +- The Security Team will cherry-pick the patches onto the master branch and all relevant release branches. +- The Release Managers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits at this point, to prevent potential conflicts with the patches sent to distributors, and conflicts as the fix is cherry-picked around branches. +- The Release Managers will ensure all the binaries are built, publicly available, and functional. + +Communications process: +- The [Private Distributors List](#private-distributors-list) will be notified at least 24 hours in advance of a pending release containing security vulnerability fixes with the public messaging, date, and time of the announcement. +- The Security Team will announce the new releases, the CVE number, severity, and impact, and the + location of the binaries to get wide distribution and user action. As much as possible this + announcement should be actionable, and include any mitigating steps users can take prior to + upgrading to a fixed version. The announcement will be sent via the following channels: + - General announcement email ([template](comms-templates/distributors-announcement-email.md)) to multiple Volcano lists + - Tracking issue opened in https://github.com/volcano-sh/volcano/issues ([template](comms-templates/vulnerability-announcement-issue.md)) and prefixed with the associated CVE ID (if applicable) + - [GitHub Security Advisories](https://github.com/volcano-sh/volcano/security/advisories) of Volcano + - [Patch release](https://github.com/volcano-sh/volcano/releases), will have the fix details included in the patch release notes. Any public announcement sent for these fixes will link to the release notes. + +## Private Distributors List + +This list is used to provide actionable information to multiple distribution vendors at once. + +See the [private distributor list doc](private-distributors-list.md) for more information. \ No newline at end of file