diff --git a/.github/ISSUE_TEMPLATE/distributors-application.md b/.github/ISSUE_TEMPLATE/distributors-application.md new file mode 100644 index 0000000..2d73498 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/distributors-application.md @@ -0,0 +1,32 @@ +--- +name: Private Disclosure Notification Request +title: Private disclosure notification request for +about: Apply for Volcano private distributor notifications +--- + +_See [Private distributor notifications](https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md#request-to-join) for additional request details._ + +## **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. **Have an actively monitored security email alias for Volcano security notifications.** + + +### 2. **Serve users outside your own organization, such as users of a Volcano distribution, product, or hosted service.** + + +### 3. **Show a public track record of fixing security issues, such as advisories, CVE fixes, or release notes.** + + +### 4. **Confirm that your distribution is independently maintained and is not only a rebuild of another distribution.** + + +### 5. **Show participation in the Volcano community, such as issues, pull requests, testing, release communication, or community discussion.** + + +### 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), such as by reviewing fixes, testing patches, or helping with release communication.** + + +### 8. **Have someone already trusted by the Volcano community vouch for the person requesting membership on behalf of your distribution, if requested by the Security Team.** diff --git a/PST.md b/PST.md deleted file mode 100644 index 65ff372..0000000 --- a/PST.md +++ /dev/null @@ -1,24 +0,0 @@ -# PST -## Introduction -The Product Security Team (PST) is the team responsible for organizing the entire response including internal communication -and external disclosure about project security. - -## Member - -| Maintainer | GitHub ID | Affiliation | -| -------------------- | ------------------------------------------------------- | ----------- | -| Klaus Ma | [k82cn](https://github.com/k82cn) | Huawei | -| Kevin Wang | [kevin-wangzefeng](https://github.com/kevin-wangzefeng) | Huawei | -| Thor-wl | [Thor-wl](https://github.com/Thor-wl) | Huawei | -| William-wang | [william-wang](https://github.com/william-wang) | Huawei | -| Liang Tang | [shinytang6](https://github.com/shinytang6) | Baidu | - -## Responsibility -* Check the safety status of the project irregularly -* Handle community safety feedback timely, give advice to PST and take measures to deal with the security issue -* Maintain the normal operation of community safety infrastructure - -## How to join in PST -Anyone who are making contribution to Volcano community more than two months continuously and interested in working for -Volcano security issues can submit a PR and add your name to the member list above. If you get agreements(approve/lgtm) -from at least two maintainers, you will be admitted into the PST. \ No newline at end of file diff --git a/SECURITY.md b/SECURITY.md index 3d33675..62d678a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,181 +1,12 @@ -# Security Release Process +# Security Policy -The Volcano project has adopted this security disclosures and response policy -to ensure responsible handling of critical issues. +The Volcano security policy and vulnerability response process are maintained by the Volcano Security Team. +Please use the current Security Team documents: -## Product Security Team (PST) +- Report a vulnerability: [security-team/SECURITY.md](security-team/SECURITY.md#report-a-vulnerability) +- Security release process: [security-team/security-release-process.md](security-team/security-release-process.md) +- Security Team and mailing lists: [security-team/security-groups.md](security-team/security-groups.md) +- Private distributor notifications: [security-team/private-distributors-list.md](security-team/private-distributors-list.md) -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)](https://github.com/volcano-sh/community/blob/master/PST.md) is responsible for organizing the entire response including internal communication and external disclosure. - -The initial Product Security Team will consist of all maintainers in the private [volcano-security](volcano-sig-security@googlegroups.com) list. In the future we may decide to have a subset of maintainers work on security response given that this process is time consuming. - - -## 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 [volcano-sig-security@googlegroups.com](volcano-sig-security@googlegroups.com). -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 compressed packet captures are all helpful to us) -- Whatever else you think we might need to identify the source of this vulnerability - -### Public Disclosure Processes - -If you know of a publicly disclosed security vulnerability please IMMEDIATELY email [volcano-sig-security@googlegroups.com](volcano-sig-security@googlegroups.com) -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 Volcano 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 volcano-security mailing list. - -### Fix Disclosure Process - -With the Fix Development underway the Volcano 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 Volcano 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 volcano-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 volcano-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 volcano-sig-security@googlegroups.com mailing list of exactly what information leaked and to whom. A retrospective will take place after the leak so we can assess how to prevent making the same mistake in the future. - -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 volcano-distributors-announce@lists.cncf.io mailing list, your -distribution should: - -1. Be an active distributor of Volcano. -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 volcano-sig-security@googlegroups.com. - -In the body of your request please specify how you qualify and fulfill each -criterion listed in [Membership Criteria](#membership-criteria). +Do not file public GitHub issues for suspected security vulnerabilities. Report them privately to [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com). diff --git a/compliance.md b/compliance.md index 749d7ff..4502922 100644 --- a/compliance.md +++ b/compliance.md @@ -528,7 +528,7 @@ See [license-lint](https://github.com/volcano-sh/volcano/tree/master/config/lice ### Expectations -License compliance matters are the responsibility of the [PST](https://github.com/volcano-sh/community/blob/master/PST.md) team. They should be responsible for license selection, review and compliance risk avoidance. They should take corresponding responsibilities to ensure that the licenses introduced by the community comply with open source compliance specifications, and make timely corrections when there are compliance risks. For example, for contagious licenses such as GPL licenses, relevant open source obligations should be fully fulfilled in open source software compliance projects, SBOM and source code should be provided in projects, and they should also consider alternative license options to avoid legal risks .Characters who do not comply with the above behavior can be removed and re-elected. +License compliance matters are handled by the community maintainers and compliance reviewers listed above, with security-sensitive compliance risks coordinated with the [Security Team](https://github.com/volcano-sh/community/blob/master/security-team/security-groups.md#the-security-team) when needed. They should be responsible for license selection, review and compliance risk avoidance. They should take corresponding responsibilities to ensure that the licenses introduced by the community comply with open source compliance specifications, and make timely corrections when there are compliance risks. For example, for contagious licenses such as GPL licenses, relevant open source obligations should be fully fulfilled in open source software compliance projects, SBOM and source code should be provided in projects, and they should also consider alternative license options to avoid legal risks. Contributors who do not comply with the above behavior can be removed and re-elected. ## Contact @@ -537,4 +537,3 @@ If you have any questions about open source license compliance, please contact u [Volcano Slack Channel](https://cloud-native.slack.com/archives/C011GJDQS0N) | [Join](https://slack.cncf.io/) [Mailing List](https://groups.google.com/forum/#!forum/volcano-sh) - diff --git a/security-team/README.md b/security-team/README.md new file mode 100644 index 0000000..d63bbc4 --- /dev/null +++ b/security-team/README.md @@ -0,0 +1,18 @@ +# Security Team + +The Volcano Security Team is responsible for receiving, triaging, and coordinating the response to reports of security issues in Volcano projects. + +## Contact + +- Private security mailing list: [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com) +- Community issues: [volcano-sh/community issues](https://github.com/volcano-sh/community/issues) + +Suspected vulnerabilities must not be reported through public GitHub issues. Please follow the private reporting process in [SECURITY.md](SECURITY.md#report-a-vulnerability). + +## Security Process + +The Volcano security policy is documented in [SECURITY.md](SECURITY.md), including the vulnerability reporting process and supported version policy. Vulnerability response and disclosure are handled through the [security release process](security-release-process.md). + +Security Team membership and security mailing lists are maintained in [security-groups.md](security-groups.md). Private distributor notifications are documented in [private-distributors-list.md](private-distributors-list.md). Repository and security response access controls are documented in [access-control.md](access-control.md). + +Security assessment material is maintained under [assessments](assessments), including the [security self-assessment](assessments/self-assessment.md). diff --git a/security-team/SECURITY.md b/security-team/SECURITY.md new file mode 100644 index 0000000..77f07b7 --- /dev/null +++ b/security-team/SECURITY.md @@ -0,0 +1,66 @@ +# Security Policy + +## Report a Vulnerability + +Please keep suspected vulnerability information confidential until the Volcano Security Team completes triage and coordinates disclosure. + +To report a vulnerability, please contact the Security Team by sending an email to [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com). + +Please include enough information for the Security Team to understand and reproduce the issue. Useful reports include: + +- A description of the vulnerability and the affected Volcano component. +- The affected Volcano version, Kubernetes version, and deployment configuration. +- Steps to reproduce the issue, including proof-of-concept code, logs, screenshots, or packet captures when available. +- The expected impact, including whether the issue affects confidentiality, integrity, availability, privilege boundaries, or multi-tenant isolation. +- Any known mitigations or workarounds. + +The Security Team will review incoming reports and respond as soon as practical. If you do not receive a response in a reasonable time, please contact a Security Team member listed in [security-groups.md](security-groups.md#the-security-team) to confirm receipt. + +### When to Report a Vulnerability + +- You believe you have discovered a potential security vulnerability in Volcano. +- You are unsure whether an issue has security impact on Volcano. + +### When Not to Report a Vulnerability + +- You need help tuning Volcano components for security. +- You need help applying security-related updates. +- The issue is not security related. + +If you discover a vulnerability in another project that Volcano depends on, and that project has its own vulnerability reporting and disclosure process, please report it directly to that project. + +## Security Release Process + +The Volcano community handles reported vulnerabilities according to this [procedure](security-release-process.md). The following flowchart shows the vulnerability handling process. + +![Vulnerability handling process](./images/vulnerability-handling-process.svg) + +## Security Communications and Lists + +Security Team membership and security mailing lists are maintained in [security-groups.md](./security-groups.md). Information about private distributor notifications, including the embargo policy and membership criteria, is documented in [private-distributors-list.md](./private-distributors-list.md). + +## Access Control and Assessments + +The Volcano project documents repository and security response access controls in [access-control.md](./access-control.md). + +The Security Team maintains security assessment material in [assessments](./assessments), including the [security self-assessment](./assessments/self-assessment.md). + +Volcano completed a third-party security audit with Ada Logics and OSTIF in collaboration with the CNCF in 2025. The published report is linked from the [security assessments](./assessments/README.md#third-party-security-review). + +## 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. The project considers whether a dependency is actively maintained, maintained by trustworthy maintainers, and licensed in a way that does not affect 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 dependency. + +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. diff --git a/security-team/access-control.md b/security-team/access-control.md new file mode 100644 index 0000000..6fb8fda --- /dev/null +++ b/security-team/access-control.md @@ -0,0 +1,50 @@ +# Access Control + +This document describes the access control rules used by the Volcano project to protect project repositories, release-related assets, and security response work. These rules apply to normal project operations and security response work. + +## GitHub Organization Access + +Access to Volcano GitHub repositories is granted according to the community roles documented in [community-membership.md](../community-membership.md). + +Privileged access is granted only when it is required for the contributor's current project responsibilities. Access should be scoped to the relevant repository, package, or communication channel instead of granted broadly across the organization. + +Accounts with write, maintain, administration, package publishing, or security response access must have two-factor authentication enabled. + +## Repository Permissions + +Repository permissions follow least privilege. Contributors should receive the minimum access required to perform their current role, and elevated access should be limited to the repositories or packages where it is needed. + +Changes to privileged access follow the membership and maintainer processes documented by the community. Access should be removed or reduced when a contributor changes role, steps down, or no longer needs the access. + +## Branch Protection and Merge Control + +Normal code and documentation changes are submitted through GitHub pull requests. Direct pushes to protected branches should be restricted to project maintenance cases where a pull request is not practical. + +Important branches should be protected by GitHub branch protection rules or rulesets. The required controls may vary by repository, but protected branches should require review and successful project checks before merge. + +Contributions are subject to DCO verification. Project checks, including tests, linting, image or manifest checks, and security scans, may be required according to the configuration of each repository. + +Repository administrators and maintainers should avoid bypassing branch protection except for exceptional project maintenance needs. When bypass is used, the change should still be visible in the repository history and follow normal project review where practical. + +## Account and Credential Controls + +Privileged GitHub accounts must use two-factor authentication. Access tokens, deploy keys, automation credentials, and package publishing credentials should be limited to the access required for their purpose. + +Credentials used for automation or release work should be rotated or revoked when they are no longer needed, when ownership changes, or when there is reason to believe they may have been exposed. + +## Security Response Access + +Private vulnerability reports are handled through the Volcano security mailing list and are shared only with the Security Team and contributors required to investigate, fix, or release the issue. + +Embargoed vulnerability information is handled on a need-to-know basis: + +- Security reports are discussed in private channels until public disclosure. +- Fix teams are limited to the maintainers and contributors needed to develop and review the remediation. +- Private distributors must follow the embargo policy documented in [private-distributors-list.md](private-distributors-list.md). +- Any unintended disclosure of embargoed information must be reported to the Security Team immediately. + +## Access Changes + +Repository and security response access should be updated when contributors change roles, step down, or no longer need the access required for their previous responsibilities. + +Security Team membership is maintained in [security-groups.md](security-groups.md#the-security-team). Private distributor notification membership is maintained according to [private-distributors-list.md](private-distributors-list.md). diff --git a/security-team/assessments/README.md b/security-team/assessments/README.md new file mode 100644 index 0000000..a547ee4 --- /dev/null +++ b/security-team/assessments/README.md @@ -0,0 +1,18 @@ +# Security Assessments + +This directory contains security assessment material for the Volcano project. + +## Documents + +- [Security self-assessment](self-assessment.md) + +## Third-Party Security Review + +Volcano completed a third-party security audit with Ada Logics and OSTIF in collaboration with the CNCF in 2025. + +- Local report: [ada-logics-volcano-security-audit-2025.pdf](ada-logics-volcano-security-audit-2025.pdf) +- Upstream report: [Volcano.sh Security Audit, Ada Logics and OSTIF, 14 May 2025](https://ostif.org/wp-content/uploads/2025/06/ada-logics-volcano-security-audit-2025-1.pdf) + +The report includes threat modelling, manual auditing, fuzzing work, and the findings identified during the audit. Published findings are tracked in the report with their remediation status. + +Future third-party review reports, remediation plans, and follow-up tracking should be linked from this page. Findings that cannot be disclosed immediately should be handled through the private vulnerability response process and published only after the Security Team determines that disclosure is appropriate. diff --git a/security-team/assessments/ada-logics-volcano-security-audit-2025.pdf b/security-team/assessments/ada-logics-volcano-security-audit-2025.pdf new file mode 100644 index 0000000..f62b6da Binary files /dev/null and b/security-team/assessments/ada-logics-volcano-security-audit-2025.pdf differ diff --git a/security-team/assessments/self-assessment.md b/security-team/assessments/self-assessment.md new file mode 100644 index 0000000..1bf2f10 --- /dev/null +++ b/security-team/assessments/self-assessment.md @@ -0,0 +1,285 @@ +# Volcano Self-Assessment + +This self-assessment builds on the Volcano security assessment prepared during the CNCF TAG Security Pals process and updates it for the current Volcano community security process. + +The self-assessment is the initial document for Volcano to describe the security of the project, identify gaps in security documentation or practice, and prepare security documentation for users and reviewers. + +## Table of Contents + +- [Metadata](#metadata) + - [Security Links](#security-links) +- [Overview](#overview) + - [Background](#background) + - [Actors](#actors) + - [Actions](#actions) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Self-Assessment Use](#self-assessment-use) +- [Security Functions and Features](#security-functions-and-features) +- [Project Compliance](#project-compliance) +- [Secure Development Practices](#secure-development-practices) +- [Security Issue Resolution](#security-issue-resolution) +- [Appendix](#appendix) + - [Third-Party Security Audit](#third-party-security-audit) + - [Known Issues Over Time](#known-issues-over-time) + - [Badges](#badges) + - [Follow-Up Items](#follow-up-items) + +## Metadata + +| | | +| ----------------- | --------------------------------------------------------------- | +| Assessment Stage | Complete | +| Software | https://github.com/volcano-sh/volcano | +| Security Provider | No | +| Languages | Go, Shell, Makefile, Dockerfile, Python, Go Template | +| SBOM | Volcano does not currently document SBOM publication on release | + +### Security Links + +| Document | URL | +| -------- | --- | +| Security Policy | https://github.com/volcano-sh/community/blob/master/security-team/SECURITY.md | +| Security Release Process | https://github.com/volcano-sh/community/blob/master/security-team/security-release-process.md | +| Security Team | https://github.com/volcano-sh/community/blob/master/security-team/security-groups.md#the-security-team | +| Access Control | https://github.com/volcano-sh/community/blob/master/security-team/access-control.md | +| Private Distributor Notifications | https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md | +| Third-Party Security Audit | https://github.com/volcano-sh/community/blob/master/security-team/assessments/ada-logics-volcano-security-audit-2025.pdf | + +## Overview + +[Volcano](https://volcano.sh/) is a cloud native unified scheduling platform for Kubernetes. It originated as a batch scheduling system and now supports converged scheduling for general-purpose workloads and AI computing at scale. + +Volcano supports workloads such as batch training, inference, AI Agent, HPC, big data, and heterogeneous accelerator workloads. It integrates with common computing frameworks and platforms such as Ray, Spark, TensorFlow, PyTorch, Flink, Argo, MindSpore, Kubeflow, and PaddlePaddle. + +### Background + +Volcano provides workload-aware scheduling and resource management for converged computing environments. It supports workloads that require gang scheduling, queueing, fair sharing, preemption, resource reservation, topology awareness, heterogeneous accelerator scheduling, and lifecycle management across multiple pods. + +Volcano addresses this by adding workload-aware APIs and scheduling capabilities on top of Kubernetes. The core project includes custom resources such as Jobs, PodGroups, Queues, NodeShards, and HyperNodes. It also includes controllers that reconcile those resources, admission webhooks that validate and mutate related objects, and schedulers that make workload placement decisions. + +The Volcano architecture includes native Ray framework support, agent scheduling for latency-sensitive AI Agent workloads, dynamic node scheduling shards across multiple scheduling paths, Volcano Global for multi-cluster scheduling, and node-side resource management through `vc-agent`. + +The following diagram shows the main components and interactions in a Volcano deployment. It is an assessment diagram and not a complete deployment reference. + +![Volcano architecture](volcano-architecture.png) + +### Actors + +The main actors in the Volcano project are: + +- **Users:** Individuals or systems that submit and manage workloads through Kubernetes APIs. +- **Kubernetes API Server:** The API server stores Kubernetes and Volcano resources and enforces Kubernetes authentication and authorization. +- **Kubernetes Nodes:** Nodes run the pods scheduled by Volcano and may run node-side Volcano components. +- **Volcano Scheduler:** The scheduler makes batch and gang scheduling decisions for AI, big data, and HPC workloads. +- **Agent Scheduler:** The agent scheduler handles latency-sensitive AI Agent workloads when enabled. +- **Volcano Controller Manager:** The controller manager reconciles Volcano resources and manages workload lifecycle. +- **Volcano Admission:** The admission component validates and mutates Volcano-related resources before they are persisted. +- **Volcano Agent:** `vc-agent` is an optional node-side component that provides node-level scheduling, colocation, and QoS management. +- **Integrated Systems:** Batch frameworks and platform tools that submit workloads to Volcano, such as Ray, Spark, TensorFlow, PyTorch, Flink, Argo, Kubeflow, and related AI or data processing systems. + +These actors are separated primarily by Kubernetes API boundaries, Kubernetes RBAC, service accounts, namespaces, admission webhook configuration, and node boundaries. Volcano does not provide a separate project API server. Volcano components communicate through the Kubernetes API server and run as separate Kubernetes workloads or node-side agents depending on the component. + +### Actions + +#### Workload Submission + +Users and integrated systems submit workloads to Volcano through Kubernetes APIs. This includes creating Volcano Jobs, PodGroups, Queues, and related Kubernetes resources. Framework integrations such as Ray, Spark, Flink, Kubeflow, and other platform systems use the same Kubernetes API path when they submit or manage Volcano workloads. + +Involved Actors: + +- Users +- Integrated Systems +- Kubernetes API Server +- Volcano Admission + +Security Checks and System Actions: + +- Kubernetes authenticates and authorizes the request according to cluster configuration. +- Kubernetes and Volcano resource schemas validate the submitted objects. +- Volcano admission validates or mutates Volcano-related resources before they are persisted. +- Volcano handles workload specifications and scheduling metadata in this path. Application payload data remains in the workload or external systems. +- Security issues in integrations are triaged with the relevant maintainers when they affect Volcano behavior or Volcano-managed resources. + +#### Resource Reconciliation + +The Volcano controller manager watches Volcano resources and reconciles their desired and observed state. It updates status, manages workload lifecycle, and coordinates related Kubernetes resources. + +Involved Actors: + +- Kubernetes API Server +- Volcano Controller Manager +- Kubernetes Nodes + +Security Checks and System Actions: + +- Controllers operate through Kubernetes APIs and use Kubernetes service account permissions. +- Controllers update Volcano-managed resources and related Kubernetes resources through Kubernetes APIs. +- Kubernetes ownership, namespace, and authorization boundaries apply to resources managed by Volcano. + +#### Scheduling and Placement + +The Volcano scheduler watches pending workloads and cluster state through the Kubernetes API server. It evaluates queues, PodGroups, scheduling actions, scheduling plugins, priorities, resource requests, and node state before writing scheduling decisions back through Kubernetes APIs. + +When agent scheduling is enabled, latency-sensitive AI Agent workloads may be scheduled through the agent scheduler. The agent scheduler uses Kubernetes state and assigned node shards to make placement decisions alongside the main scheduling path. + +Involved Actors: + +- Kubernetes API Server +- Volcano Scheduler +- Agent Scheduler +- Kubernetes Nodes + +Security Checks and System Actions: + +- Scheduling decisions are made from Kubernetes and Volcano resource state. +- Queue policy, priority, preemption, reclamation, topology, and resource constraints affect placement decisions. +- NodeShard configuration and scheduler configuration control how scheduling paths are assigned and how they interact. +- The scheduler does not grant workload permissions or bypass Kubernetes admission and authorization decisions. + +#### Node-Side Resource Management + +When `vc-agent` features are deployed, node-side resource management becomes part of the Volcano deployment. The agent runs on nodes and provides node-level scheduling, workload colocation, and QoS controls. + +Involved Actors: + +- Volcano Agent +- Kubernetes Nodes + +Security Checks and System Actions: + +- `vc-agent` runs with the service account and host access configured for the enabled feature. +- The agent's service account, host access, and deployment privileges define the node-side access boundary. +- Node-side resource controls remain part of the cluster's node security boundary. + +### Goals + +Volcano's security goals are: + +- Efficient and fair scheduling for converged general-purpose, AI, big data, HPC, and high-performance workloads on Kubernetes. +- Secure handling of Volcano resources through Kubernetes authentication, authorization, admission, and controller reconciliation. +- Correct scheduling behavior that does not let one authorized user interfere with other users outside the cluster's authorization model. +- A private process for reporting, triaging, fixing, and disclosing vulnerabilities. +- Clear security ownership through the Volcano Security Team. + +### Non-Goals + +Volcano does not replace Kubernetes authentication, authorization, admission control, network policy, or workload isolation. Volcano also does not secure arbitrary user workload code, provide a security boundary between containers beyond Kubernetes controls, or guarantee the security of external systems integrated with Volcano. + +## Self-Assessment Use + +This self-assessment is maintained by the Volcano community to describe the project's security model and security practices. It is not a third-party audit and should not be read as an independent attestation of Volcano's security health. + +The document is intended to help Volcano users understand where security documentation is maintained, how security issues are handled, and which parts of the project are security relevant. It also provides CNCF TAG Security and CNCF reviewers with a structured overview of Volcano's security posture. + +## Security Functions and Features + +The following items are the primary security impact areas for Volcano changes and are useful starting points for threat modeling. + +**Critical** + +- **Workload API integrity:** Volcano resources such as Jobs, PodGroups, Queues, NodeShards, and HyperNodes define the scheduling intent that Volcano acts on. A flaw in their validation or interpretation can change workload ownership, queue behavior, resource allocation, or lifecycle state. +- **Admission invariants:** Volcano admission is a control point before Volcano-related objects are persisted. It protects scheduler and controller assumptions by validating or mutating requests that affect workload semantics. +- **Scheduling decision integrity:** Volcano's scheduler is the core decision point for placement, fairness, preemption, reclamation, topology, and resource sharing. Defects in this path can let one workload consume resources outside the intended scheduling policy or reduce availability for other workloads. +- **Controller reconciliation integrity:** Volcano controllers turn desired state into Kubernetes resources and status updates. Reconciliation must preserve resource ownership, namespace boundaries, and lifecycle semantics for Volcano-managed workloads. +- **Kubernetes API integration:** Volcano relies on the Kubernetes API server as its API and storage boundary. Kubernetes authentication, authorization, admission, and service account behavior are part of the security boundary for every Volcano component. + +**Security Relevant** + +- **Service accounts and RBAC:** Volcano components use Kubernetes service accounts and RBAC permissions. These permissions affect which Kubernetes and Volcano resources each component can read or update. +- **Webhook TLS and admission configuration:** Admission behavior depends on Kubernetes webhook configuration, service routing, and TLS setup. Misconfiguration can disable validation or change how requests reach the admission component. +- **Scheduler and queue configuration:** Actions, tiers, plugins, queue policy, priority, preemption, reclamation, topology, and node sharding configuration affect fairness, isolation, and availability. +- **Agent scheduling and node-side components:** Agent scheduling, NodeShards, `vc-agent`, device plugins, and heterogeneous resources are security relevant when enabled because they affect node assignment, node-side privileges, and resource visibility. +- **Logging and monitoring:** Logs and metrics provide visibility into scheduling decisions, controller behavior, component health, and unexpected state changes. +- **Release artifacts:** Users consume Volcano releases, images, manifests, and charts. Release integrity and dependency hygiene are part of the project's security posture. + +## Project Compliance + +**Open Source License Compliance** + +Volcano is released under the Apache License 2.0. Source code contributions to the project must comply with this license. License compliance guidance is documented in [compliance.md](../../compliance.md). + +## Secure Development Practices + +Volcano maintains an [OpenSSF Best Practices](https://www.bestpractices.dev/en/projects/3012) project page. + +### Development Pipeline + +All source code is maintained in [GitHub](https://github.com/volcano-sh/volcano), and changes are reviewed before merge. + +- All source code is publicly available in GitHub. +- Code changes are submitted through pull requests. +- Pull requests are reviewed according to the repository's configured review and branch protection rules. +- Contributors are required to sign off commits through DCO. +- Automated checks, including CodeQL and project tests, are used in the Volcano repository development workflow. +- Access control for project repositories and security response work is documented in [access-control.md](../access-control.md). + +### Communication Channels + +* **Internal** + + Team members communicate with each other through GitHub issues, pull requests, community meetings, the [Volcano Slack channel](https://cloud-native.slack.com/archives/C011GJDQS0N), and mailing lists. + +* **Inbound** + + Users and prospective users communicate with the team through GitHub issues, the [Volcano Slack channel](https://cloud-native.slack.com/archives/C011GJDQS0N), and the [Volcano mailing list](https://groups.google.com/forum/#!forum/volcano-sh). + + Suspected vulnerabilities are reported privately to [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com). + +* **Outbound** + + The project communicates with users through release notes, GitHub Security Advisories, mailing lists, the project website, and blog posts. Private distributor notifications may be used when advance private disclosure is needed for a security release. + +### Ecosystem + +Volcano is part of the Kubernetes and CNCF ecosystem. It is used for AI, machine learning, Ray, big data, HPC, inference, AI Agent, and other workloads that need advanced scheduling and resource management capabilities on Kubernetes. + +Related Volcano repositories and subprojects extend the ecosystem into adjacent scheduling and AI infrastructure use cases, including Kthena, AgentCube, Volcano Global, APIs, device plugins, dashboard, Helm charts, website, and resource exporter. Security-sensitive issues in these repositories should be routed through the Volcano Security Team unless a repository documents a separate process. + +## Security Issue Resolution + +### Responsible Disclosure Process + +Suspected vulnerabilities should be reported privately to the Security Team at [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com). Reporters should not create public GitHub issues for suspected vulnerabilities. + +The reporting process is documented in [SECURITY.md](../SECURITY.md#report-a-vulnerability). + +### Vulnerability Response Process + +The Security Team coordinates vulnerability intake, triage, remediation, disclosure, and release communication. The response process is documented in [security-release-process.md](../security-release-process.md). + +### Incident Response + +Security release and public communication steps are documented in [security-release-process.md](../security-release-process.md#patch-release-and-public-communication). Advance private disclosure to distributors is governed by [private-distributors-list.md](../private-distributors-list.md). + +## Appendix + +### Third-Party Security Audit + +Volcano completed a third-party security audit with Ada Logics and OSTIF in collaboration with the CNCF in 2025. + +The audit was carried out in March and April 2025, covered the `volcano-sh/volcano` repository, and included threat modelling, manual auditing, and fuzzing. The report lists ten findings and marks all ten as fixed. The audit did not cover every repository under the Volcano organization. + +Local report: [ada-logics-volcano-security-audit-2025.pdf](ada-logics-volcano-security-audit-2025.pdf) + +Upstream report: [Volcano.sh Security Audit, Ada Logics and OSTIF, 14 May 2025](https://ostif.org/wp-content/uploads/2025/06/ada-logics-volcano-security-audit-2025-1.pdf) + +### Known Issues Over Time + +Published security advisories are available from the [volcano-sh/volcano GitHub Security Advisories page](https://github.com/volcano-sh/volcano/security/advisories). + +### Badges + +- [OpenSSF Best Practices](https://www.bestpractices.dev/en/projects/3012) +- [Go Report Card](https://goreportcard.com/report/github.com/volcano-sh/volcano) + +The OpenSSF Best Practices badge should remain part of the project's regular security documentation review. + +### Follow-Up Items + +- Document SBOM generation or publication if Volcano starts publishing SBOMs for releases. +- Keep OpenSSF Best Practices badge status current. +- Continue reviewing RBAC permissions for Volcano components against the principle of least privilege. +- Continue reviewing release artifact integrity, image publishing, and signing practices. +- Keep dependency update and vulnerability scanning practices documented. +- Review whether subprojects such as Kthena, AgentCube, and Volcano Global require their own security assessment material or additional scope in this document. diff --git a/security-team/assessments/volcano-architecture.png b/security-team/assessments/volcano-architecture.png new file mode 100644 index 0000000..d340752 Binary files /dev/null and b/security-team/assessments/volcano-architecture.png differ diff --git a/security-team/comms-templates/non-vuln-response.md b/security-team/comms-templates/non-vuln-response.md new file mode 100644 index 0000000..135d1ba --- /dev/null +++ b/security-team/comms-templates/non-vuln-response.md @@ -0,0 +1,13 @@ +# Non-Vulnerability Response Template + +Thank you for your message. + +This report does not appear to describe a security vulnerability or security incident in Volcano. Please use one of the public project channels instead: + +- GitHub issues: https://github.com/volcano-sh/volcano/issues/new/choose +- Volcano Slack channel: https://cloud-native.slack.com/archives/C011GJDQS0N +- Volcano mailing list: https://groups.google.com/forum/#!forum/volcano-sh + +Regards, + +The Volcano Security Team diff --git a/security-team/comms-templates/private-distributor-notification-email.md b/security-team/comms-templates/private-distributor-notification-email.md new file mode 100644 index 0000000..57fa294 --- /dev/null +++ b/security-team/comms-templates/private-distributor-notification-email.md @@ -0,0 +1,45 @@ +# Private Distributor Notification Email Template + +Use this email template when selected private distributors receive advance notification of a pending security release. + +To: `` + +Subject: `[EMBARGOED] Volcano security notification: ` + +This message is embargoed until ``. + +The Volcano Security Team is preparing a security release for ``. + +## Summary + +- CVE or advisory ID: `` +- Severity: `` +- Affected versions: `` +- Planned fixed versions: `` +- Planned public disclosure: `` +- Impact: `` + +## Mitigation + +`` + +## Fix Information + +- Patch or pull request: `` +- Release candidate or artifact: `` +- Testing requested: `` + +## Embargo Handling + +Please share this information only with people in your organization who need it to prepare a fix or update. Do not disclose, hint at, or discuss this issue publicly before the public disclosure time without explicit approval from the Volcano Security Team. + +If this information is accidentally disclosed, contact [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com) as soon as possible with details about what was disclosed and to whom. + +## References + +- Private distributor notifications policy: https://github.com/volcano-sh/community/blob/master/security-team/private-distributors-list.md +- Security release process: https://github.com/volcano-sh/community/blob/master/security-team/security-release-process.md + +Regards, + +`` on behalf of the Volcano Security Team diff --git a/security-team/comms-templates/private-distributor-notification-request.md b/security-team/comms-templates/private-distributor-notification-request.md new file mode 100644 index 0000000..6b6acee --- /dev/null +++ b/security-team/comms-templates/private-distributor-notification-request.md @@ -0,0 +1,35 @@ +# Private Distributor Notification Request Email Template + +Subject: Request to join Volcano private distributor notifications + +To: volcano-security@googlegroups.com + +I am requesting membership in Volcano private distributor notifications on behalf of: + +- Distribution name: +- Organization: +- Requester name: +- Requester email: +- Security contact email: + +## Membership Criteria + +1. Actively monitored security email alias for Volcano: + +2. Users outside our own organization, such as users of a Volcano distribution, product, or hosted service: + +3. Public track record of fixing security issues, such as advisories, CVE fixes, or release notes: + +4. Confirmation that this distribution is independently maintained and is not only a rebuild of another distribution: + +5. Participation in the Volcano community, such as issues, pull requests, testing, release communication, or community discussion: + +6. Acceptance of the embargo policy: + +7. Willingness to contribute back, such as by reviewing fixes, testing patches, or helping with release communication: + +8. Existing trusted Volcano community participant who can vouch for this request, if requested by the Security Team: + +## Additional Information + + diff --git a/security-team/comms-templates/vulnerability-acknowledge-email.md b/security-team/comms-templates/vulnerability-acknowledge-email.md new file mode 100644 index 0000000..aeb0c62 --- /dev/null +++ b/security-team/comms-templates/vulnerability-acknowledge-email.md @@ -0,0 +1,23 @@ +# Vulnerability Acknowledgement Email Template + +Use this email template to acknowledge a suspected vulnerability report. + +To: `` + +Subject: `Volcano vulnerability report received: ` + +Hello ``, + +Thank you for reporting this issue to the Volcano Security Team. + +We have received your report about `` and will review it through the Volcano security response process: + +https://github.com/volcano-sh/community/blob/master/security-team/SECURITY.md + +Please keep the details of the report private while the issue is being assessed and coordinated. If you have additional reproduction details, logs, affected versions, suggested mitigations, or other context, please reply to this thread. + +We will follow up as soon as practical. + +Regards, + +`` on behalf of the Volcano Security Team diff --git a/security-team/comms-templates/vulnerability-announcement-email.md b/security-team/comms-templates/vulnerability-announcement-email.md new file mode 100644 index 0000000..12ea95a --- /dev/null +++ b/security-team/comms-templates/vulnerability-announcement-email.md @@ -0,0 +1,51 @@ +# Vulnerability Announcement Email Template + +Use this email template for public disclosure of a Volcano security vulnerability. The announcement should be concise and actionable. Detailed technical discussion can be linked from the GitHub Security Advisory or the tracking issue. + +To: `volcano-sh@googlegroups.com` + +Subject: `[Security Advisory] : ` + +Hello Volcano Community, + +The Volcano Security Team is announcing a security fix for ``. + +## Summary + +- CVE or advisory ID: `` +- Severity: `` +- Affected versions: `` +- Fixed versions: `` +- Impact: `` + +## Am I Vulnerable? + +`` + +## Mitigation + +`` + +## Fixed Versions + +Users should upgrade to one of the following versions: + +- `` + +## Detection + +`` + +## References + +- GitHub Security Advisory: `` +- Release notes: `` +- Fix PRs or commits: `` + +## Credits + +The Volcano Security Team thanks `` for responsibly reporting this issue. + +Regards, + +`` on behalf of the Volcano Security Team diff --git a/security-team/comms-templates/vulnerability-announcement-issue.md b/security-team/comms-templates/vulnerability-announcement-issue.md new file mode 100644 index 0000000..fef574e --- /dev/null +++ b/security-team/comms-templates/vulnerability-announcement-issue.md @@ -0,0 +1,33 @@ +# Vulnerability Announcement Issue Template + +Title: CVE-YYYY-NNNN: + +## Summary + +The Volcano Security Team is announcing a security fix for . + +- CVE: CVE-YYYY-NNNN +- Severity: +- Affected versions: +- Fixed versions: +- Impact: + +## Mitigation + + + +## Fixed Versions + +Users should upgrade to one of the following versions: + +- + +## References + +- Security advisory: +- Release notes: +- Fix PRs: + +## Credits + +The Volcano Security Team thanks for responsibly reporting this issue. diff --git a/security-team/images/vulnerability-handling-process.svg b/security-team/images/vulnerability-handling-process.svg new file mode 100644 index 0000000..f6fe273 --- /dev/null +++ b/security-team/images/vulnerability-handling-process.svg @@ -0,0 +1,91 @@ + + Vulnerability handling process showing reporting, validation, remediation, restricted disclosure, and public disclosure. + + + + + + + + Disclosure scope + + + + + + The security team + The security team, fix contributors + Downstreams Vendors + Public + + + Receive suspected + vulnerabilities + + + Vulnerability + validation & + assessment + + + Remediation solutions + development + + + Vulnerability + remediation review + + + Describe + Vulnerability impact + + + Launch CVE + procedures + + + Get assigned + CVE + + + Restricted + disclosure + + + Remediation info + release + + + Release a + security advisory + + + + + + + + + + + + + + + + Vulnerability reporting + Vulnerability confirming + Vulnerability remediation + Restricted disclosure + Public disclosure + Vulnerability status + 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..f7d76b8 --- /dev/null +++ b/security-team/private-distributors-list.md @@ -0,0 +1,46 @@ +## Private Distributor Notifications + +Private distributor notifications provide advance, actionable information to selected Volcano distributors when early coordination is needed for a security release. This process is not intended for general security announcements or individual notification requests. + +The Volcano project does not publish a private distributor recipient list. The Security Team maintains the recipient information privately and uses it only for coordinated security disclosure. + +Advance notifications may use the [private distributor notification email template](./comms-templates/private-distributor-notification-email.md). + +### Embargo Policy + +Recipients of private distributor notifications must share the information only within their teams, on a need-to-know basis, to get the related issue fixed in their distribution. The information must not be made public, shared, nor even hinted at otherwise, except with the Security Team's explicit approval. This holds true until the public disclosure date and time agreed by the Security Team. + +Before any information 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 removal from private distributor notifications. + +### Contributing Back + +This is a cooperative process. Private distributors are expected to review or test proposed patches when asked, point out potential issues such as incomplete fixes or newly introduced bugs, and report useful feedback to the Security Team. + +### Membership + +Membership is managed by the Security Team. Requests are reviewed against the criteria below. Accepted contacts are recorded privately by the Security Team rather than published in this repository. + +### Membership Criteria + +Private distributor notifications are for distributors that need to prepare fixes or notices for their users before a vulnerability is publicly disclosed. If Volcano is used only inside one organization, that organization can follow the public advisory and fixed release instead of joining this list. + +To be eligible for private distributor notifications, your distribution should: + +1. Have an actively monitored security email alias for Volcano security notifications. +2. Serve users outside your own organization, such as users of a Volcano distribution, product, or hosted service. +3. Show a public track record of fixing security issues, such as advisories, CVE fixes, or release notes. +4. Be independently maintained and not only a rebuild of another distribution. +5. Show participation in the Volcano community, such as issues, pull requests, testing, release communication, or community discussion. +6. Accept the Embargo Policy that is outlined above. +7. Be willing to contribute back, such as by reviewing fixes, testing patches, or helping with release communication. +8. Be vouched for by an existing trusted Volcano community participant when requested by the Security Team. + +**Removal**: If your distribution stops meeting one or more of these criteria after joining, it may be removed from private distributor notifications. + +### Request to Join + +Send a request to [volcano-security@googlegroups.com](mailto:volcano-security@googlegroups.com), filling in the criteria template in [the request email template](./comms-templates/private-distributor-notification-request.md). diff --git a/security-team/security-groups.md b/security-team/security-groups.md new file mode 100644 index 0000000..70f889a --- /dev/null +++ b/security-team/security-groups.md @@ -0,0 +1,20 @@ +## Volcano security mailing lists + +The Volcano Security Team maintains the private vulnerability reporting channel and coordinates private distributor notifications when advance disclosure is required. + +### The Security Team + +Email: + +volcano-security@googlegroups.com + +Owners: + +- Zefeng Wang([@kevin-wangzefeng](https://github.com/kevin-wangzefeng)), [wangzefeng@huawei.com](mailto:wangzefeng@huawei.com) + +Members: + +- Zefeng Wang([@kevin-wangzefeng](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) +- Zhonghu Xu([@hzxuzhonghu](https://github.com/hzxuzhonghu)), [xuzhonghu@huawei.com](mailto:xuzhonghu@huawei.com) diff --git a/security-team/security-release-process.md b/security-team/security-release-process.md new file mode 100644 index 0000000..09263bd --- /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 an undisclosed vulnerability](#process-an-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 Distributor Notifications](#private-distributor-notifications) + + +## 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. Security Team membership is managed in [security-groups.md](security-groups.md#the-security-team). + +### The Security Team Membership + +#### Joining + +New potential members to the Security Team will first fill a minimum 3 month rotation in the [Associate](#associate) role. These individuals will be nominated by maintainers or current Security Team members. + +#### Stepping Down + +Members may step down at any time. + +#### 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 because of reporter request, a low CVSS score, or a design issue that requires long-term refactoring. +- Assist in process improvements, bug bounty administration, audits, or other non-disclosure activities. + +## Process an undisclosed vulnerability + +The Volcano Community asks that all suspected vulnerabilities be privately and responsibly disclosed through the [vulnerability reporting process](SECURITY.md#report-a-vulnerability). + +If the vulnerability is accepted, the Security Team will determine its remediation priority and develop remediations, including mitigations, patches, fixed versions, and other risk-reduction steps, by following the [vulnerability handling process](#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. Reported vulnerabilities are handled according to this procedure. + +![Vulnerability handling process](./images/vulnerability-handling-process.svg) + +## 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. The Security Team 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 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, the Security Team will determine its remediation priority and develop remediations, including mitigations, patches, fixed versions, and other risk-reduction steps. + +The Security Team will start the CVE process to obtain a CVSS score and CVE ID when applicable. The CVSS v3 standard 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 fix development underway, the Security Team needs to create 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 timelines below. + +**Advance Vulnerability Disclosure to Private Distributors** + +- Private distributors may receive advance notification of vulnerabilities that are assigned a CVE when early coordination is needed. The notification will include information that can be reasonably provided at the time, such as patches or links to PRs, proofs of concept or reproduction instructions, known mitigations, and timelines for public disclosure. Distributors should read about [private distributor notifications](#private-distributor-notifications) to find out the requirements for being included in this process. +- **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: +- Private distributors may be notified 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/vulnerability-announcement-email.md)) to Volcano communication channels + - 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 Distributor Notifications + +This process is used to provide actionable information to selected distribution vendors when advance coordination is needed. + +See the [private distributor notifications doc](private-distributors-list.md) for more information.