vulnerability-reporting

# Vulnerability Response

The CloudWeGo community places a high emphasis on the security of our community editions. The CloudWeGo Security Committee is dedicated to receiving, investigating, and disclosing security breaches related to the CloudWeGo community. We actively encourage researchers and industry organizations to report any potential security vulnerabilities to our committee. Upon report, we pledge a prompt response, analysis, and resolution of the security concerns.

# Supported Versions

Our vulnerability response process mainly supports the latest versions of the CloudWeGo community's sub-projects. If you have not yet upgraded, please do so as soon as possible.

# Vulnerability Handling Process

Every security vulnerability is addressed by assigned team members who track, handle, and manage the repair and disclosure of vulnerabilities. The process coordinator, a member of the CloudWeGo Security Committee, is responsible for the tracking and promotion of vulnerability fixes and disclosures.

This image details the process involving vulnerability reporting, assessment, and disclosure.

# Vulnerability Report

If you identify a potential security vulnerability in any CloudWeGo release, we strongly encourage you to submit a vulnerability report to the CloudWeGo community. We look forward to your cooperation in responsibly resolving and disclosing the issue.

# Reporting Methods

The CloudWeGo security team can be informed of potential security vulnerabilities in CloudWeGo releases via email at（security@cloudwego.io）.

# Reporting Methods

For swift confirmation and verification of suspected vulnerabilities, we ask that your email includes the following:

• Basic information: This includes details on the vulnerability's affected modules, trigger conditions, and potential system failures after successful exploitation.

• Technical details: information on system configuration, location methods, exploit descriptions, proof-of-concept (POC), problem reproduction method, and steps.

• Suggested solutions for repair.

• Your organization and contact details.

• Your potential disclosure plans for vulnerabilities.

# Email Response Time

We will respond within 48 hours to suspected security vulnerabilities reported via email and provide feedback on the progress of vulnerability handling.

# Vulnerability Severity Assessment

CloudWeGo uses the industry-standard Common Vulnerability Scoring System (CVSS) for vulnerability assessments. Severity assessments categorize the difficulty of exploiting vulnerabilities and the potential impact on confidentiality, integrity, and availability after successful exploitation.

# Assessment Criteria

CloudWeGo uses CVSSv3 for vulnerability assessments. The assessments measure the impact of a vulnerability using different metrics such as:

• Attack vector (AV) - Indicates the "remoteness" of the attack and how to exploit this vulnerability.

• Attack complexity (AC) - Tells the difficulty of attack execution and the factors needed for a successful attack.

• User interaction (UI) - Determines whether the attack requires user participation.

• Privileges required (PR) - Records the level of user authentication required for a successful attack.

• Scope (S) - Determines whether the attacker can affect components with different permission levels.

• Confidentiality (C) - Measures the extent of the impact after the information is disclosed to unauthorized parties.

• Integrity (I) - Measures the extent of the impact after the information is tampered with.

• Availability (A) - Measures the extent to which users are affected when they need to access data or services.

# Assessment Principles

The assessment provides an insight into the severity of a vulnerability, not the risk. Every security vulnerability has multiple attack scenarios; the highest CVSS score scenario is used as the basis for the vulnerability assessment:

• The assessment must be based on the attack scenario and ensures that the attacker can cause an impact on the system's confidentiality, integrity, and availability in this scenario.

• When a security vulnerability has multiple attack scenarios, the one that causes the greatest impact, that is, the highest CVSS score, should be used as the basis.

• If a vulnerability exists in the library being invoked, it should be assessed after determining the attack scenario of the vulnerability based on the use of the library in the product.

• Security defects that cannot be triggered or do not affect CIA (Confidentiality/Integrity/Availability) are given a CVSS score of 0.

# Assessment Steps

When assessing vulnerabilities, you can proceed in the following steps:

• Set possible attack scenarios and score based on these scenarios.

• Determine the vulnerable component and the impact (affected) component.

• Choose the value of the basic assessment indicators: Provide a vulnerability impact evaluation by scoring the exploitable indicators (attack vectors/attack complexity/required privileges/user interaction/scope) and affected indicators (confidentiality/integrity/availability).

# Severity Classification

# Vulnerability Disclosure

To ensure the safety of CloudWeGo users, the community won't disclose, discuss, or confirm the security issues of any version before an investigation, security repairs, and the issuance of security notices is completed. Once the security vulnerability is rectified, the CloudWeGo community will release a security notice inclusive of the technical details of this vulnerability, the CVE number, CVSS security score, and severity rating. This will also include the versions affected by this vulnerability and the fixed versions.