diff --git a/assets/js/security.js b/assets/js/security.js deleted file mode 100644 index aabe17468e0..00000000000 --- a/assets/js/security.js +++ /dev/null @@ -1,110 +0,0 @@ -/* -Copyright 2018 Google LLC - -Licensed under the Apache License, Version 2.0 (the "License"); -you may not use this file except in compliance with the License. -You may obtain a copy of the License at - - https://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. -*/ -(function($){ - $.safetyData = [{ - id: 1, - bulletin: 'CloudWeGo-SA-2022-1', - digest: 'Connection Leaking', - influence: ['kitex-v0.1.3'], - level: 'Low', - publish: '2022-01-13' - },{ - id: 2, - bulletin: 'CloudWeGo-SA-2022-2', - digest: 'Netpoll Panic', - influence: ['netpoll-v0.2.2', 'kitex-v0.3.0'], - level: 'Middle', - publish: '2022-05-09' - }]; -})(jQuery); - -(function($) { - 'use strict'; - function renderSafetyTable($, data) { - const $tbody = $('#bulletinTable > tbody'); - const isCN = location.href.indexOf('zh') > -1 ? '/zh' : ''; - let html = ''; - if (data.length === 0) { - $tbody.html('
| Bulletin | -Digest | -Level | -Influence | -Publish | -
|---|
- 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.
- -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.
- -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.
- -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.
-The CloudWeGo security team can be informed of potential security vulnerabilities in CloudWeGo releases via email at(security@cloudwego.io). -
-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.
We will respond within 48 hours to suspected security vulnerabilities reported via email and provide feedback on the progress of vulnerability handling.
- -- 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.
-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.
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.
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 Rating | -CVSS Score | -
|---|---|
| Critical | -9.0 - 10.0 | -
| High | -7.0 - 8.9 | -
| Medium | -4.0 - 6.9 | -
| Low | -0.1 - 3.9 | -
| None | -0.0 | -
- 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. -
-| 公告 | -摘要 | -严重级别 | -影响组件与版本 | -发布时间 | -
|---|
- CloudWeGo 社区非常重视社区版本的安全性,CloudWeGo 安全委员会负责接收、调查和披露 CloudWeGo 社区相关的安全漏洞。我们鼓励漏洞研究人员和行业组织主动将 CloudWeGo 社区的疑似安全漏洞报告给 CloudWeGo 社区安全委员会。我们会快速的响应、分析和解决上报的安全问题或安全漏洞。
-漏洞响应流程主要支持 CloudWeGo 社区各个子项目的最新版本,如果您还没有升级请尽快升级。
-每个一个安全漏洞都会有一个指定的人员进行跟踪和处理,协调员是 CloudWeGo 安全委员会的成员,他将负责跟踪和推动漏洞的修复和披露。漏洞端到端的处理流程如下图。
-
- 在这里我们主要介绍流程中漏洞上报、漏洞评估和漏洞披露这三部分内容。
-如果您认为 CloudWeGo 产品存在一个疑似安全漏洞,我们希望您将漏洞上报给 CloudWeGo 社区,并与我们配合以负责任的方式修复和披露该问题。
-您可以通过 email 将 CloudWeGo 产品的潜在安全漏洞发送到 CloudWeGo 安全团队邮箱(security@cloudwego.io)。 -
-为了便于快速的确认和验证疑似漏洞,请在漏洞上报邮件中包含但不限于以下内容:
-基本信息:包括漏洞影响的模块、漏洞的触发条件和成功利用后对系统的影响等。
技术细节:包括系统配置、定位方法、Exploit 的描述、POC、问题重现方法和步骤等。
修复方案建议。
上报者的组织和联系方式。
上报者可能的漏洞披露计划。
我们将在48小时内响应通过邮箱上报的疑似安全漏洞,并向上报者反馈漏洞处理的进展。
-- 业界普遍使用 CVSS 标准评估漏洞的严重性,CloudWeGo 在使用 CVSSv3 进行漏洞评估时,需要设定漏洞攻击场景,基于在该攻击场景下的实际影响进行评估。漏洞严重等级评估是指针对漏洞利用难易程度,以及利用后对机密性、完整性、可用性的影响进行评估,并生成一个评分值。
-CloudWeGo 社区采用 CVSS v3 对漏洞进行评估,CVSS V3 由通过对以下向量来评估一个漏洞的影响:
-攻击向量(AV)-表示攻击的“远程性”以及如何利用此漏洞。
攻击复杂性(AC)-讲述攻击执行的难度以及成功进行攻击需要哪些因素。
用户交互(UI)-确定攻击是否需要用户参与。
所需的权限(PR)-记录成功进行攻击所需的用户身份验证级别。
范围(S)-确定攻击者是否可以影响具有不同权限级别的组件。
机密性(C)-衡量信息泄露给非授权方后导致的影响程度。
完整性(I)-衡量信息被篡改后导致的影响程度。
可用性(A)-衡量用户在需要访问数据或服务时受影响的程度。
评估漏洞的严重等级,不是评估风险。
评估时必须基于攻击场景,且保证在该场景下,攻击者成功攻击后能对系统造成机密性、完整性、可用性影响。
当安全漏洞有多个攻击场景时,应以造成最大的影响,即 CVSS 评分最高的攻击场景为依据。
被嵌入调用的库存在漏洞,要根据该库在产品中的使用方式,确定漏洞的攻击场景后进行评估。
安全缺陷不能被触发或不影响 CIA(机密性/完整性/可用性),CVSS 评分为0分。
对漏洞进行评估时,可根据下述步骤进行操作:
-设定可能的攻击场景,基于攻击场景评分。
确定漏洞组件(Vulnerable Component)和受影响组件(Impact Component)。
选择基础评估指标的值:通过对可利用指标(攻击向量/攻击复杂度/所需权限/用户交互/范围)和受影响指标(机密性/完整性/可用性)给出漏洞影响评估。
| 严重等级(Severity Rating) | -CVSS 评分(Score) | -
|---|---|
| 致命(Critical) | -9.0 - 10.0 | -
| 高(High) | -7.0 - 8.9 | -
| 中(Medium) | -4.0 - 6.9 | -
| 低(Low) | -0.1 - 3.9 | -
| 无(None) | -0.0 | -
- 为了保护 CloudWeGo 用户的安全,在进行调查、修复和发布安全公告之前,CloudWeGo 社区不会公开披露、讨论或确认 CloudWeGo 产品的安全问题。安全漏洞修复后 CloudWeGo 社区会发布安全公告,安全公告内容包括该漏洞的技术细节、CVE编号、CVSS安全评分、严重性等级以及受到该漏洞影响的版本和修复版本等信息。 -
-