diff --git a/repository/openeuler.yaml b/repository/openeuler.yaml
index d84cc0405e49864a1a0c8a75aa9ec266c1c1210b..b172dded700403d4adcb916f1b05a908034b2f90 100644
--- a/repository/openeuler.yaml
+++ b/repository/openeuler.yaml
@@ -126,5 +126,10 @@ repositories:
   protected_branches:
   - master
   type: public
+- name: security-committee
+  description: "the Repository of Security Committee"
+  protected_branches:
+  - master
+  type: public
 
 
diff --git a/sig/sigs.yaml b/sig/sigs.yaml
index 702d6f6b8c0b3ba01dd75b00cb41ccf8dd26a4c2..15d1d5646c23976cad3675c627d4c90ffe7a3fb6 100644
--- a/sig/sigs.yaml
+++ b/sig/sigs.yaml
@@ -4049,3 +4049,7 @@ sigs:
   - src-openeuler/vcredist
   - src-openeuler/vdsm
   - src-openeuler/vdsm-jsonrpc-java
+- name: security-committee
+  repositories:
+  - openeuler/security-committee
+  - openeuler/security
diff --git a/zh/security-committee/OWNERS.yaml b/zh/security-committee/OWNERS.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..29530c9dcde58f6cf8ff712de07ef35e2d15c650
--- /dev/null
+++ b/zh/security-committee/OWNERS.yaml
@@ -0,0 +1,5 @@
+maintainers:
+  - liujingang09
+  - yangli69393
+  - yanxiaobing2020
+  - zhujianwei001
\ No newline at end of file
diff --git a/zh/security-committee/README.md b/zh/security-committee/README.md
index 8e6f3c70f57d7b422c6f30791671b30b3bc2a4fc..f1d6a339ef86c0188b1c3adf216a5be059da972d 100644
--- a/zh/security-committee/README.md
+++ b/zh/security-committee/README.md
@@ -1,40 +1,71 @@
 # 安全委员会
 
-openEuler安全委员会是负责接收和响应openEuler产品安全问题报告的机构。该机构的使命是通过以下方式为openEuler用户提供最安全的操作环境：
+本文档主要介绍安全委员会的职责、组织构成和运作方式，以及负责的相关流程。
 
-+ 通过打包程序修复和更新软件包
-+ 确定并帮助改善社区内的安全开发实践
-+ 回答社区中的软件安全性相关问题
+
+
+## 安全委员会（SC）使命
+
+openEuler安全委员会（SC）是负责接收和响应openEuler产品安全问题报告、提供社区安全指导，开展安全治理的组织。它的使命是：为openEuler用户提供最安全的产品和开发环境。
 
 
 
 ## 工作职责
 
-+ 协助漏洞修复：确保及时修补和发布已知漏洞。通过为软件包Maintainer们提供补丁帮助，帮助用户系统在成为攻击受害者之前进行漏洞修复，包括提供相关漏洞检测和修复工具。
++ 协助漏洞修复：确保及时修复已知漏洞。通过为软件包Maintainer们提供补丁帮助，帮助用户系统在成为攻击受害者之前进行漏洞修复，包括提供相关漏洞检测和修复工具。
 + 响应安全问题：响应上报的安全问题，跟踪安全问题的处理进展，并遵循安全问题披露策略对安全问题在社区内进行披露和公告。
-+ 安全编码规则：防止漏洞被首先写入是安全团队的目标。安全团队会努力创建文档或开发工具来帮助开发团队避免软件开发过程中的常见陷阱。安全团队还会尝试回答过程中遇到的任何问题。
++ 安全编码规则：普及安全编码知识是安全团队的目标。安全团队会努力创建文档或开发工具来帮助开发团队避免软件开发过程中的常见陷阱。安全团队还会尝试回答在开发和使用过程中遇到的任何问题。
 + 参与代码审核：安全团队希望能够通过代码审核帮助团队提前发现代码中的漏洞。
 
 
 
 ## 成员
 
-***待任命***
+产品安全委员会（SC）负责对openEuler安全问题进行分类和处理，以下是产品安全委员会现任成员：
+
++ 刘金刚[@liujingang09](https://gitee.com/liujingang09)，`liujingang09@huawei.com`,[GPG秘钥]
++ 杨丽[[@yangli69393](https://gitee.com/yangli69393)]，`<y69393@huawei.com> `   
++ 颜小兵[[@yanxiaobing2020](https://gitee.com/yanxiaobin2020)]，`yanxiaobing@huawei.com`
++ 朱健伟[@zhujianwei001](https://gitee.com/zhujianwei001)，`zhujianwei7@huawei.com`，[GPG秘钥]
+
+准成员：
+
+- 
+
+
+
+## 会议时间
+
+- 每周三上午10:00~12:00，通过weLink视频会议召开
+
+
+
+### 联系SC
+
+SC和产品发布相关，所以和发布经理有很多工作关联，SC会负责让产品安全的发布。请参考使用正确的联系方式以获得最佳和最快的响应。
+
+| 清单或群组                             | 类型    | 用途                                                         |
+| -------------------------------------- | ------- | ------------------------------------------------------------ |
+| security@openeuler.org                 | Private | openEuler安全披露邮箱。此列表由PSC密切监控和分类。详细信息请参考[安全披露指南](security-disclosure.md) |
+| release-managers-private@openeuler.org | Private | 发布经理的私人交流邮件，所有成员都应订阅security@openeuler.org。发布经理在发布过程中讨论安全问题的处理应使用该邮箱 |
+| security-discuss-private@openeuler.org | Private | SC的私有内部讨论邮件，所有成员都需订阅security@openeuler.org |
+
+
+
+### 安全发布流程
 
+关于如何上报安全问题，如何获取安全补丁等安全相关事宜，请参考[安全披露指南](security-disclosure.md)
 
+了解openEuler社区的安全处理流程和安全策略，请参考[安全处理流程](security-process.md)
 
-## 联系
 
-+ 邮件列表：security@openEuler.org
-+ openEuler社区ISSUE/PR
 
+## 社区讨论和支持
 
-## 安全
+在[社区页面](https://openEuler.org)上了解如何和openEuler社区做安全互动
 
-安全委员会的政策和文件
 
-+ 地址：
 
-  
+## 行为规范
 
-*如果要报告安全问题，请通过电子邮件发送到私人邮件列表：security@openeuler.org，其中包含安全问题的详细信息，以及所有openEuler错误报告的预期详细信息。*
\ No newline at end of file
+接受[openEuler行为规范]()的约束。
\ No newline at end of file
diff --git a/zh/security-committee/private-distributors-list.md b/zh/security-committee/private-distributors-list.md
new file mode 100644
index 0000000000000000000000000000000000000000..45b981a2caa2c0196873f82df699c8fb44da4610
--- /dev/null
+++ b/zh/security-committee/private-distributors-list.md
@@ -0,0 +1,41 @@
+# 发行商名单
+
+该列表用于向多个发行商提供可操作性的信息。不提供个人查找安全问题。
+
+
+
+
+
+## 名单管理
+
+openEuler通过用户组来管理发行商身份，请参考：
+
+
+
+
+
+
+
+## 进入发行商名单标准
+
+为了能够进入distirbutors-announce@openeuler.org的邮件列表，您的发行应支持：
+
+1、为我们的项目拥有一个受监控的安全电子邮箱别名
+
+2、积极维护或获得openEuler的发行伙伴身份
+
+3、加入用户群组
+
+4、对已知收到的安全问题，都有可公开验证的记录
+
+5、成为社区的积极参与者和贡献者
+
+6、有代表参与openEuler的分发过程
+
+说明：如果您不满足以上的条件，将为取消订阅。
+
+
+
+## 如何申请加入
+
+可以[在此处]()提交申请。
\ No newline at end of file
diff --git a/zh/security-committee/security-committee.md b/zh/security-committee/security-committee.md
new file mode 100644
index 0000000000000000000000000000000000000000..e7c39610ed1f7dcb746b8459aa654294cde78808
--- /dev/null
+++ b/zh/security-committee/security-committee.md
@@ -0,0 +1,32 @@
+#  新建委员会申请
+
+[English](https://gitee.com/openeuler/community/blob/master/sig/sig-template/sig-template.md) | 简体中文
+
+说明：本SIG的Charter内容遵循openEuler章程 [README](https://gitee.com/openeuler/community/blob/master/zh/governance/README.md)中描述的约定，使用[SIG-governance](https://gitee.com/openeuler/community/blob/master/zh/technical-committee/governance/SIG-governance.md)中概述的角色和组织管理。
+
+## SIG组工作目标和范围
+
+openEuler安全委员会（SC）是负责接收和响应openEuler产品安全问题报告、提供社区安全指导，开展安全治理的组织。它的使命是：为openEuler用户提供最安全的产品和开发环境。
+
++ 协助漏洞修复：确保及时修复已知漏洞。通过为软件包Maintainer们提供补丁帮助，帮助用户系统在成为攻击受害者之前进行漏洞修复，包括提供相关漏洞检测和修复工具。
++ 响应安全问题：响应上报的安全问题，跟踪安全问题的处理进展，并遵循安全问题披露策略对安全问题在社区内进行披露和公告。
++ 安全编码规则：防止漏洞被写入是安全团队的目标。安全团队会努力创建文档或开发工具来帮助开发团队避免软件开发过程中的常见陷阱。安全团队还会尝试回答在开发和使用过程中遇到的任何问题。
++ 参与代码审核：安全团队希望能够通过代码审核帮助团队提前发现代码中的漏洞。
+
+
+
+### 该SIG管理的repository及描述
+
+- 项目名称：安全
+  - 交付件形式：
+  - repository名称：security
+  
+    
+
+
+
+### 跨领域和面向全社区的流程
+
+1、开发者：openEuler社区的安全问题处理和披露流程
+
+2、消费者：关于如何上报安全问题，如何获取安全补丁等安全相关事宜
\ No newline at end of file
diff --git a/zh/security-committee/security-disclosure.md b/zh/security-committee/security-disclosure.md
new file mode 100644
index 0000000000000000000000000000000000000000..805eb4d33ae0cfb0ad3d0c1f74e673fb7e5588c5
--- /dev/null
+++ b/zh/security-committee/security-disclosure.md
@@ -0,0 +1,52 @@
+# openEuler安全和披露说明
+
+
+
+# 安全公告
+
+您可以从openEuler的[安全公告和披露页面](https://openeuler.org/)获取openEuler产品安全公告和安全披露的电子邮件。
+
+
+
+## 上报漏洞
+
+我们感谢所有向openEuler开源社区上报安全漏洞的安全研究人员和用户。安全委员会内会有社区志愿者对您上报的安全漏洞进行全面彻底的调查。
+
+您可以通过电子邮件将您发现的安全问题的详细信息以及错误报告发送到私有的security@openeuler.org邮箱列表。请你采用[安全问题模板](template-security-bug.md)。
+
+您可以使用[openEuler安全委员会](README.md)成员的GPG秘钥将电子邮件加密到此列表。
+
+
+
+### 我应该合适上报漏洞
+
+- 您认为你在openEuler中发现了潜在的安全漏洞
+- 您不确定漏洞可能会怎样影响openEuler
+- 您在其他项目中发现了openEuler依赖的漏洞，您可以附上已经上报给上游社区的链接
+
+
+
+### 什么时候不应该上报漏洞
+
+- 您想帮助提升openEuler的安全能力
+- 您需要得到安全相关的帮助
+- 您的问题与安全性无关
+
+
+
+## 安全漏洞响应
+
+- openEuler安全委员会成员会在3个工作日内确认并分析上报的安全问题，并同时启动安全处理流程。
+
+- 安全委员会确认安全问题后会对问题进行分发和跟进
+- 在安全问题从分类、确定到修复和发布的权过程中，我们会通过邮件及时更新报告
+
+
+
+## 公开披露时间
+
+- 公开披露的日期由openEuler安全委员会和错误提交者协商确定。对于安全问题，一旦有用户缓解或规避措施，我们就会尽快将漏洞完全披露出来。
+- 在尚未完全理解和修改错误、解决方案未经过充分测试、或者未完成和发行商的协调时，延迟披露是不可避免的，也是合理的。
+- 在公开披露前，对部分问题我们会先向发行商披露，并在不影响发行商利益的前提下，尽量协同多个发行商间的发布时间。
+- 披露的时间从确认安全问题起，大概需要几周。对于具有明确的缓解或规避措施的漏洞，我们会尽量缩短披露时间在两周以内。
+- openEuler安全委员会对设定的披露日期有最终决定权。
\ No newline at end of file
diff --git a/zh/security-committee/security-evaluation.md b/zh/security-committee/security-evaluation.md
new file mode 100644
index 0000000000000000000000000000000000000000..62f48a210ee4f0a3eab76688c5a79d3366d523c4
--- /dev/null
+++ b/zh/security-committee/security-evaluation.md
@@ -0,0 +1,77 @@
+# 严重性评估——我们如何进行漏洞评分
+
+本文主要介绍openEuler对安全问题采用的严重性评估方案和典型案例。
+
+
+
+### 安全问题的定义
+
+安全问题是一类漏洞，是指系统在设计、实现、操作和管理中的缺陷或弱点，可被外部威胁所利用来违反系统的安全策略，并对系统的机密性、完整性、可用性造成影响。攻击者可以利用这些漏洞拒绝用户使用计算资源，或者在用户的计算机上执行任意的代码。由于病毒和蠕虫可以利用这些漏洞在计算机之间传播，所以安全问题会给用户带来极大的风险。安全问题可以分成两个基本类型：
+
++ 拒绝服务
++ 允许执行任意代码
+
+####  拒绝服务
+
+拒绝用户使用计算资源的问题属于拒绝服务类安全问题，比如此类问题导致所运行的程序崩溃，或消耗大量内存，磁盘空间或CPU时间等。但是需要注意，程序包含各种问题，有时这些问题也会导致程序崩溃，但崩溃的现象不能以一个一致的方式重现，那么这些问题也不会被视为拒绝服务的安全问题。拒绝服务的安全问题是可以“一致”和“可靠”重现的问题，攻击者可以使用它故意使正在运行的程序崩溃。
+
+#####  拒绝服务的安全类问题的典型案例
+
++ 使客户端崩溃的特制电子邮件
++ 使看护程序崩溃的特定网络数据
++ 使游览器崩溃的特定HTML
+
+##### 非拒绝服务的安全类问题的典型案例
+
++ 通过执行非常复杂的用户输入操作使文本编辑器崩溃
++ 通过物理访问的操作或动作使计算机崩溃
+
+
+####  允许任意代码执行
+
+一般而言，允许任意代码执行带来的安全问题比拒绝服务带来的问题更加严重。允许任意代码执行可能会允许恶意用户获取对计算机的控制，或者允许病毒或蠕虫传播。在程序的正常执行过程中，会有可预期的执行流程，然而恶意的输入程序可能会改变执行流程并运行攻击者选择的代码。
+
++ 远程执行代码：每当计算机连接到网络时，远程攻击者就有可能远程利用任意代码执行问题来执行恶意代码。这意味着攻击者不必靠近或登录被攻击的计算机。比如蠕虫病毒通过Internet感染到无数连接到Internet的计算机。恶意的破解程序通常还会利用远程代码执行问题来获取对计算机系统的未授权访问。
++ 本地代码执行：本地代码执行问题时一种可能导致攻击者在用户执行特定命令时运行的代码，或者利用SUID程序提升特权的问题。
+
+通常来说，在各种命令中都会发现这类问题，但是如果需要要求用户执行某些特定命令，那么这些错误不会被认为是安全性问题。比如某个本地命令执行需要提升特权才能运行代码。
+
+
+
+### openEuler 安全问题等级
+
+ openEuler的产品安全问题等级使用常见的漏洞评分系统（CVSS）来评估在openEuler 中发现的安全问题的影响。按照优先级的风险评估，可以帮助您了解和升级系统，从而针对这些问题做出适合您运行环境的明智决策。
+
+
+
+### 通用漏洞评分（CVSS）
+
+通用漏洞评分系统（CVSS）为漏洞的基本评分提供了指导，并通过对漏洞的各个方面进行评分来描述详细的严重程度，包括：访问量、访问复杂性、机密性、完整性和可用性。CVSS等级作为一个准则来识别缺陷的关键指标，但openEuler不仅仅会直接使用CVSS等级来确定修复缺陷的优先级。对于那些已经修复的缺陷的优先级，openEuler会参考四点量表综合考虑全局影响给出评分。
+
+CVSS v3基础指标涵盖了对漏洞影响性评估的各个方面
+
++ 攻击向量（AV）：攻击的 “远程能力”以及在该能力下漏洞会被如何利用
++ 攻击复杂度（AC）：攻击的难度以及成功进行攻击所需要的因素的获取难度
++ 用户交互（UI）：确定攻击是否是自动进行的，或者需要人参与
++ 所需权限（PR）：成功进行攻击所需要的用户身份验证级别
++ 范围（S）：确定攻击者是否可以影响具有不同权限级别的组件
++ 机密性（C）：确定是否可以将数据公开给非授权方；如果可以，公开到什么级别
++ 完整性（I)：衡量数据的可信度以及未经授权的用户不会修改数据的可信度
++ 可用性（A)：：获得授权的用户在需要访问数据或服务时是否可获得
+  公式将这些度量转换成单个数字评分，范围从0.0（无风险）到10.0（最高风险）。有关基础指标的详细说明，请参考[通用漏洞评分系统v3.0：用户指南]( https://www.first.org/cvss/user-guide )
+
+
+
+### NVD和openEuler分数之间的差异
+
+由于软件包是由多个供应商提供的，而CVSS基础评分与这些供应商提供的版本号，提供的方式，平台以及软件的编译方式相关，所以对openEuler来说，直接采用第三方漏洞库（例如NVD）的评分有时候是比较困难的，因为这些评分只为每一个漏洞提供了单个CVSS的基础分数，适用到openEuler可能会出现较大差异。
+
+比如，由于Firefox应用程序也可用于Microsoft Windows（用户通常以管理员权限运行Firefox），因此NVD将Firefox的漏洞评为具有最高影响力。但openEuler 的版本会采用低影响度评分，因为Firefox一般以非特权用户的方式运行。出于以上这些原因，我们建议您尽量采用openEuler提供的CVSS基础分数。
+
+如果您认为特定的漏洞CVSS v3基础分数不正确，请告诉[我们]()，我们很高兴就此问题进行讨论并在需要的时候更新分数。
+
+
+
+## 典型案例说明
+
+待补充
\ No newline at end of file
diff --git a/zh/security-committee/security-process.md b/zh/security-committee/security-process.md
new file mode 100644
index 0000000000000000000000000000000000000000..585095e5423a68e987ed244d044cd03d07270a21
--- /dev/null
+++ b/zh/security-committee/security-process.md
@@ -0,0 +1,271 @@
+# 安全问题处理和发布流程
+
+openEuler已经采用本文中描述的安全披露和响应策略，以确保我们及时负责的处理安全问题。
+
+目录
+
++ [产品安全委员会](#安全委员会)
++ [使命和工作职责](#使命和工作职责)
+	+ [成员管理方式](#成员管理方式)
+  + [成员的角色说明](#成员的角色说明)
++ [安全问题处理和披露流程](#安全问题处理和披露流程)
+     + [安全问题收集](#安全问题收集)
+     + [安全问题确认](#安全问题确认)
+     + [成立修复团队](#成立修复团队)
+      + [制定修复计划](#制定修复计划)
+             + [安全问题影响性评估](#安全问题影响性评估)
+        + [安全问题响应说明](#安全问题响应说明)
+     + [组织补丁开发](#组织补丁开发)
+     + [修复披露](#修复披露)
+  + [修复流程回顾](#修复流程回顾)
+  
++ [安全问题处理和披露流程示意图](#安全问题处理和披露流程示意图)
+  
++ [发行商名单](#发行商名单)
+
+
+
+## 安全委员会（SC）
+
+安全委员会（SC）负责整个社区对安全问题的响应，包括内部沟通和外部披露，但整个过程需要在相关开发人员和发布经理的协助下完成。SC将由订阅了[openEuler安全邮件列表（私有）](security@openeuler.org)的志愿者组成。
+
+
+
+### 使命和工作职责
+
+SC的工作职责请参考[README](README.md)
+
+
+
+### 成员管理方式
+
+- 成员应保持积极主动的态度
+
+- 延长休假1个月或更长时间的成员应与其他成员进行协调，以确保在休假期间为该角色配备足够的人员
+
+- 休假1~3个月的成员可以确定一个临时的替补
+
+- 角色成员可以罢免其他未请假，但无法联系超过1个月或者未履行其书面职责超过1个月的成员。这个罢免也通过“[多数共识](https://en.wikipeedia.org/wiki/Supermajority#Two-third_vote)“完成
+
+  
+
+#### 加入
+
+- SC一般由7个成员组成
+
+- 新成员通常从技术指导委员会、发行经理或补丁发行经理、以及SIG内负责安全工作的核心成员中提名。
+
+- 提名的新成员通过“[懒惰的共识](https://openoffice.apache.org/docs/governance/lazyConsensus.html)”完成投票
+
+- 为了让新加入的成员熟悉安全委员会的工作职责和流程，新加入SC成员将首先担任至少三个月的准成员
+
+
+
+#### 退出
+
+成员随时可以退出，并从合格的准成员中提议替代成员。如成员退出需要投票，将按照[“多数共识”](https://en.wikipeedia.org/wiki/Supermajority#Two-third_vote)完成
+
+
+
+### 成员角色说明
+
+由于安全处理流程涉及到多个环节和对应的职责，SC的成员会被赋予一些特定的角色，以更加明确的承担这些环节的职责。以下是各个角色的定义，这些角色会定期进行轮换，以保证每一个人都有机会了解openEuler的安全处理机制
+
+
+
+**修复责任人**
+
+跟踪协调每一个安全问题的从“生”到“死”
+
+
+
+**问题分发员**
+
+- 确保应该处理问题的人员都已经收到通知
+
+- 响应还未被确认为安全问题的问题
+
+- 协助确认安全问题在openEuler产品的评分
+
+- 如果开发者在处理安全问题的时候有分歧，也可以视需要上升到问题分发员。
+
+  在线的SC成员都会负责该工作，他们会按照上报的顺序响应安全请求的原则。
+
+
+
+**基础设施保障员**
+
+这个角色确保漏洞扫描、代码安全合规扫描等配套的安全工具正常工作，包括：
+
+- 确认工具的正常运行
+- 分发和处理工具扫描的结果。包括确保漏洞扫描发现的问题的正确分发，完成新软件包的合规扫描入库等
+- 分析和提出安全领域工具的优化需求
+
+
+
+**披露员**
+
+- 按照规则收集披露问题；
+- 向安全委员会提交披露申请，包括安全公告和安全问题；
+- 提供符合披露原则的披露相关公共消息发布。包括相关的披露信息、升级文档、日志变更、向公众解释严重性，将错误通知发送到邮件列表，请求CVE等。
+
+
+
+**安全联络员**
+
+该角色不是SC的成员，每一个SIG团队内都应该指定参与安全活动的SIG成员，这个角色应该由希望后继加入SC的成员承担。他们将负责：
+
++ 优先处理分发给本SIG团队内的安全问题
++ 提供本SIG内项目的安全问题披露内容
++ 协助开展安全流程改进，激励管理、审核代码或其他不公开的安全活动
+
+
+
+**发布团队**
+
+安全补丁发布团队属于[发布团队](sig-release)的一部分，他们在安全流程里会负责：
+
+- 刷新[发行商列表](private-distributors-list.md)——管理发行商列表
+
++ 组织和发布补丁——在必须提供安全修复程序时，组织涉及到的SIG内的Maintainer，管理构建和发布补丁
+
+**发布经理**有责任在整个生命周期内组织相关活动的开展，遵守安全问题处理和披露的流程要求。
+
+
+
+
+
+## 安全问题处理和披露流程
+
+### 1、安全问题收集
+
+####  CVE例行扫描
+
+- openEuler社区会采用XXX漏洞扫描工具，对社区上使用的上游社区软件包公开披露的漏洞进行例行扫描和同步。
+- 扫描出的漏洞会按照[安全问题模板](template-security-bug.md)的格式向对应的SIG推送带有“CVE”标签的Issue
+
+
+
+#### 内部上报
+
+SIG内的bug被团队成员确认为安全漏洞，团队成员将对应的Issue调整成“私有”，同时添加“安全问题”标签，并根据实际情况添加“优先级”标签。安全问题分发员会定期查看此类问题的更新情况。
+
+
+
+####  外部上报
+
+如果您知道一个安全漏洞，不在openEuler安全团队已经处理的公开安全漏洞的列表之内，烦请立即发送电子邮件至security@openeuler.org通知SC，以便于他们可以启动补丁、发布和公告过程。
+
+请采用[安全流程电子邮件模板](email-templates.md)，同时您可以使用[openEuler安全委员会](README.md)成员的GPG秘钥将电子邮件加密到此邮件。收到上报邮件后，安全问题分发员会在其repository内新建一个安全Issue。
+
+如果有需要，SC将询问您是否可以通过负责人的方式秘密披露此问题。如果您反对，我们将采用公开披露的方式。
+
+
+
+### 2、安全问题确认
+
+安全问题分发员会完成对新问题的确认，包括：
+
+- 对于外部上报的安全问题，确定受影响的项目和软件包。
+- （包括外部上报问题和CVE问题）联系相关工程师（会优先从项目的Maintainer和Committer中选择），推动尽快确认是否是新的安全问题。确认后将Issue（私有）分发到对应的repo
+- 对于外部上报的安全问题，确认后通知问题上报人。
+
+确认结果记录在Issue的进展内，并调整Issue的状态进入解决阶段。
+
+
+
+### 3、成立修复团队
+
+修复负责人将组织修复团队，修复团队包括：
+
+- 对应的版本或补丁发布经理
+
+- 受影响项目的SIG成员，优先选择前期已经参与问题分发阶段的团队成员（定义在其对应的*OWNERS*文件内）
+
+
+
+### 4、制定修复计划
+
+对于每一个漏洞，修复责任人会与修复团队，发布经理进行协调，并负责向社区相关成员发送电子邮件。修复责任人会根据问题的严重性，开发需要的时间和发布经理反馈的版本计划，综合自己最佳的判断来制定问题的修复计划。
+
+
+
+#### 安全问题影响性评估
+
+修复负责人和修复团队将使用[CVSS计算器](https://www.first.org/cvss/specification-document#i5)创建一个CVSS。他们会将使用“[严重性评估——我们如何进行漏洞评分]()”来确定错误的影响和严重性。修复负责人对计算出的风险进行最终评估。
+
+- 如果评估分数低于4.0（严重性分数较低）或评估的风险较低，则修复责任人可以选择半公开进行修复。这意味着PR是直接在公开的openEuler存储库上进行的，同时可以在公开渠道讨论。同时修复团队可以在特定情况下（比如假期等）放慢发布过程。这些决策必须在安全会议上讨论。
+
+- 如果评估分数低于6（严重程度中等），高于4.0，则修复责任人也可以选择半公开进行修复。修复责任人将确定公开处理该修复程序是否会对用户造成伤害，以决定是否将对问题安全性方面的讨论限定在私有渠道。
+
+注意：修复责任人有权对漏洞的严重程度进行分类。
+
+
+
+#### 安全问题响应说明
+
+- 如果处理的是openEuler社区开发项目的安全问题，则所有的计划时间表会尽快形成。
+- 如果不是，则修复程序依赖于上游社区的披露时间表。修复责任人会通过与上游社区的合作，尽量做到在适应上游社区时间表的同时，最大程度的保护openEuler社区的用户。
+
+
+
+### 5、组织补丁开发
+
++ 如需要在私有安全库进行开发，修复负责人将使修复团队可以访问openEulerXXXXXX中的私有安全存储库，以开发修复程序。
++ 修复负责人将向[openEuler CVE编号颁发机构申请CVE](cve-request.md)，**上游社区公开披露的CVE不需要此过程**。
++ 发布经理发布经理根据发布计划组织补丁开发
++ 私有ropo上相关修复文件已经提交到对应版本的软件包库，或者公开修复的软件包已经提交到对应的软件包库。发布经理将通知修复责任人——修复工作已经完成。
+
+注意：openEuler私有安全存储库由SC拥有。组织管理由sig-infrastructure完成。
+
+
+
+### 6、修复披露
+
+随着修复的开展，修复负责人需要针对更广泛的社区范围提交总体沟通计划。总体沟通启动应该在修复团队制定了修复或缓解措施以后开始，以便可以将可达成的计划传递给用户。
+
+
+
+**发行商披露（可选）** （在问题确认后1~14天内完成）
+
++ 如果问题严重到需要尽早通知发行商，修复负责人将在修复团队的帮助下做出此决定。比如影响严重的“可远程利用”或“特权升级”等问题。否则可以跳过此过程。
++ 修复负责人将补丁程序通过电子邮件发送给distributors-announce@openEuler.org，以便发行商可以提前准备，并在发行版发布之日向用户提供版本。发行商应订阅[发行商披露邮件列表](distributors-announce@openEuler.org)，阅读[发行商披露须知](private-distributors-list.md)信息，以了解添加到该列表的要求。
+
+
+
+**修复发布日**（在问题确认后1~21天内完成）
+
++ 在即将发布前，至少提前24小时通过电子邮件通知[发行商](private-distributors-list.md)，通知信息应包含公共消息，公告的日期。
++ 修复负责人会将补丁推送到master分支和相关的发行版本分支。修复团队会使用/lgtm和/approve通过
++ 版本的发行经理会尽快merge这些PR。此时不应更改提交内容，以防止与发送给发行商的补丁程序产生不应有的冲突，以及在分支选择patch时发生冲突。
++ 发行经理应确保所有的二进制文件通过build，可公开使用且正常运行。
++ 修复负责人将提供新版本号、CVE编号（如有需要）、严重性和影响以及二进制文件的位置的信息给披露负责人，以支撑更广泛的分发和用户操作。此披露负责人将尽早将公告更新到社区页面，并应包括用户在升级到固定版本之前可以采用的任何缓解措施。公告将通过以下渠道发送
+  + security@openeuler.org
+  + distributors-announce@openeuler.org
+  + [社区安全页面](https://openeuler.org/zh/security.html)
+  +  在https://gitee.com/openeuler/issues 中打开问题，并标记成`area/security`，并以相关CVE ID为前缀
+  
++ 如涉及，修复负责人将从私人安全存储库中删除修复团队
+
+
+
+### 7、修复流程回顾
+
+这些步骤应该在发布日期后的1~3天完成。回顾过程是改进的动力。
+
++ 修复负责人将该问题的回顾过程发送到security-discuss-private@openeuler.org，包括有关每个人的详细信息，过程时间表的执行情况，与引入该问题相关的PR链接，以及对响应和发布的任何处理或建议。
++ 鼓励发行经理和修复团队将自己的反馈意见发送到security-discuss-private@openeuler.org。诚实的批判是我们改善社区的唯一途径。
+
+
+
+## 安全问题处理和披露流程图示
+
+![](安全问题处理流程.jpg)
+
+
+
+## 发行商名单
+
+该列表用于向openEuler的发行商提供安全相关可操作的信息，请参考[发行商列表](private-distributors-list.md)
+
+
diff --git a/zh/security-committee/template-security-bug.md b/zh/security-committee/template-security-bug.md
new file mode 100644
index 0000000000000000000000000000000000000000..0ecc11bee6725ce47dc9eec2175941b03e039cbb
--- /dev/null
+++ b/zh/security-committee/template-security-bug.md
@@ -0,0 +1,28 @@
+# openEuler 安全流程电子邮件模板
+
+这是电子邮件模板的集合，用于处理PSC需要处理的各种安全问题。
+
+
+
+## 安全问题上报模板
+
+主题：[最新公告]
+
+
+
+你好，openEuler社区。
+
+在$COMPONENT版本的$OLDVERSION或更早版本发现了一个安全问题。严重等级是$SEVERITY，希望能够升级到$COMPONENT解决此问题。
+
+
+
+- 是漏洞吗？：
+  + 描述问题发生需要的场景（包括软硬件和交互场景等）
+  + 问题所造成的影响和影响的范围（包括版本范围）
+  + 如何确认使用的版本是否包含该问题
+
++ 如何缓解漏洞造成的影响
+  + 短期缓解方案
+  + 长期缓解方案：比如patch的安装地址、安装方式等
+
++ 漏洞的详情（如果是公开的CVE，请提供CVE编号）
\ No newline at end of file
diff --git "a/zh/security-committee/\345\256\211\345\205\250\351\227\256\351\242\230\345\244\204\347\220\206\346\265\201\347\250\213.jpg" "b/zh/security-committee/\345\256\211\345\205\250\351\227\256\351\242\230\345\244\204\347\220\206\346\265\201\347\250\213.jpg"
new file mode 100644
index 0000000000000000000000000000000000000000..64441b7390854d704904a51fb648effbcf9f6b28
Binary files /dev/null and "b/zh/security-committee/\345\256\211\345\205\250\351\227\256\351\242\230\345\244\204\347\220\206\346\265\201\347\250\213.jpg" differ