Karmada has always attached great importance to vulnerability management in development and maintenance. The Karmada community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues.
- The Security Team
- Process a undisclosed vulnerability
- Process a publicly disclosed Vulnerability
- Vulnerability handling process
- Patch, Release, and Public Communication
- Private Distributors List
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, under the The Security Team section.
New potential members to the security team will first fill a minimum of a 3 month rotation in the Associate role. These individuals will be nominated by individuals on maintainers.
Members may step down at anytime.
- 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.
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
The Karmada Community asks that all suspected vulnerabilities be privately and responsibly disclosed via a recommended way available at here.
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.
If you know of a publicly disclosed security vulnerability please IMMEDIATELY email cncf-karmada-security@lists.cncf.io 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.
The following flowchart shows the vulnerability handling process. we will strictly handle the reporting vulnerability according to this procedure.
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.
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 Karmada's security advisors to analyze/validate the vulnerability, assess its severity based on its actual impact on Karmada.
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 Karmada community assesses the impact of a vulnerability.
If the CVSS score is under ~4.0 (a low severity score) 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 karmada-io/karmada 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 Karmada patch release.
Note: CVSS is convenient but imperfect. Ultimately, the Security Team has discretion on classifying the severity of a vulnerability.
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 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 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 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) to multiple Karmada lists
- Tracking issue opened in https://github.com/karmada-io/karmada/issues (template) and prefixed with the associated CVE ID (if applicable)
- GitHub Security Advisories of Karmada
- Patch release, will have the fix details included in the patch release notes. Any public announcement sent for these fixes will link to the release notes.
This list is used to provide actionable information to multiple distribution vendors at once.
See the private distributor list doc for more information.