!4 申请合入安全委员会的说明

* update README.md.
* 删除文件 漏洞处理说明/security-process.md
* 修改安全处理为主流程
* 刷新文档链接
* 合入安全委员会安全处理和漏洞披露相关的文档
* update README.md.

README.md

-# security
+# 安全委员会
 
-#### 介绍
-security 
+本文档主要介绍安全委员会的职责、组织构成和运作方式，以及负责的相关流程。
 
-#### 软件架构
-软件架构说明
 
 
-#### 安装教程
+## 安全委员会（SC）使命
 
-1.  xxxx
-2.  xxxx
-3.  xxxx
+OpenHarmony安全委员会（SC）是负责接收和响应OpenHarmony产品安全问题报告、提供社区安全指导，开展安全治理的组织。它的使命是：为OpenHarmony用户提供最安全的产品和开发环境。
 
-#### 使用说明
 
-1.  xxxx
-2.  xxxx
-3.  xxxx
 
-#### 参与贡献
+## 工作职责
 
-1.  Fork 本仓库
-2.  新建 Feat_xxx 分支
-3.  提交代码
-4.  新建 Pull Request
++ 协助漏洞修复：确保及时修复已知漏洞。通过为软件包Maintainer们提供补丁帮助，帮助用户系统在成为攻击受害者之前进行漏洞修复，包括提供相关漏洞检测和修复工具。
++ 响应安全问题：响应上报的安全问题，跟踪安全问题的处理进展，并遵循安全问题披露策略对安全问题在社区内进行披露和公告。
++ 安全编码规则：普及安全编码知识是安全团队的目标。安全团队会努力创建文档或开发工具来帮助开发团队避免软件开发过程中的常见陷阱。安全团队还会尝试回答在开发和使用过程中遇到的任何问题。
++ 参与代码审核：安全团队希望能够通过代码审核帮助团队提前发现代码中的漏洞。
 
 
-#### 码云特技
 
-1.  使用 Readme\_XXX.md 来支持不同的语言，例如 Readme\_en.md, Readme\_zh.md
-2.  码云官方博客 [blog.gitee.com](https://blog.gitee.com)
-3.  你可以 [https://gitee.com/explore](https://gitee.com/explore) 这个地址来了解码云上的优秀开源项目
-4.  [GVP](https://gitee.com/gvp) 全称是码云最有价值开源项目，是码云综合评定出的优秀开源项目
-5.  码云官方提供的使用手册 [https://gitee.com/help](https://gitee.com/help)
-6.  码云封面人物是一档用来展示码云会员风采的栏目 [https://gitee.com/gitee-stars/](https://gitee.com/gitee-stars/)
+## 成员
+
+产品安全委员会（SC）负责对OpenHarmony安全问题进行分类和处理，以下是产品安全委员会现任成员：
+
++ [张阿东](https://gitee.com/zhangadong)，zhangadong@huawei.com
++ [张林利](https://gitee.com/almighty1982)，linli.zhang@huawei.com
++ [林轩宇](https://gitee.com/lin-xuanyu)，linxuanyu1@huawei.com
+
+准成员：
+
+- 
+
+
+
+## 会议时间
+
+- 每周三上午10:00~12:00，通过weLink视频会议召开
+
+
+
+### 联系SC
+
+SC和产品发布相关，所以和发布经理有很多工作关联，SC会负责让产品安全的发布。请参考使用正确的联系方式以获得最佳和最快的响应。
+
+| 清单或群组                             | 类型    | 用途                                                         |
+| -------------------------------------- | ------- | ------------------------------------------------------------ |
+| security@openharmony.io                 | Private | OpenHarmony安全披露和安全小组内部讨论邮箱。 |
+
+
+
+### 安全发布流程
+
+关于如何上报安全问题，如何获取安全补丁等安全相关事宜，请参考[安全披露指南](/漏洞处理说明/security-disclosure.md)
+
+了解OpenHarmony社区的安全处理流程和安全策略，请参考[安全处理流程](/漏洞处理说明/README.md)
+
+
+
+## 社区讨论和支持
+
+在[社区页面](https://harmonyostest.devccsrnd.hwcloudtest.cn:3089/cn/home)上了解更多鸿蒙的详细知识以及如何和OpenHarmony社区做安全互动
+
+
+
+## 行为规范
+
+接受[OpenHarmony行为规范]()的约束。
\ No newline at end of file

漏洞处理说明/README.md

+# 安全问题处理和发布流程
+
+OpenHarmony已经采用本文中描述的安全披露和响应策略，以确保我们及时负责的处理安全问题。
+
+目录
+
++ [产品安全委员会](#安全委员会)
++ [使命和工作职责](#使命和工作职责)
+	+ [成员管理方式](#成员管理方式)
+  + [成员的角色说明](#成员的角色说明)
++ [安全问题处理和披露流程](#安全问题处理和披露流程)
+     + [安全问题收集](#安全问题收集)
+     + [安全问题确认](#安全问题确认)
+     + [成立修复团队](#成立修复团队)
+      + [制定修复计划](#制定修复计划)
+             + [安全问题影响性评估](#安全问题影响性评估)
+        + [安全问题响应说明](#安全问题响应说明)
+     + [组织补丁开发](#组织补丁开发)
+     + [修复披露](#修复披露)
+  + [修复流程回顾](#修复流程回顾)
+  
++ [安全问题处理和披露流程示意图](#安全问题处理和披露流程示意图)
+  
++ [发行商名单](#发行商名单)
+
+
+
+## 安全委员会（SC）
+
+安全委员会（SC）负责整个社区对安全问题的响应，包括内部沟通和外部披露，但整个过程需要在相关开发人员和发布经理的协助下完成。SC将由订阅了[OpenHarmony安全邮件列表（私有）](security@openharmony.io)的志愿者组成。
+
+
+
+### 使命和工作职责
+
+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的成员会被赋予一些特定的角色，以更加明确的承担这些环节的职责。以下是各个角色的定义，这些角色会定期进行轮换，以保证每一个人都有机会了解OpenHarmony的安全处理机制
+
+
+
+**修复责任人**
+
+跟踪协调每一个安全问题的从“生”到“死”
+
+
+
+**问题分发员**
+
+- 确保应该处理问题的人员都已经收到通知
+
+- 响应还未被确认为安全问题的问题
+
+- 协助确认安全问题在OpenHarmony产品的评分
+
+- 如果开发者在处理安全问题的时候有分歧，也可以视需要上升到问题分发员。
+
+  在线的SC成员都会负责该工作，他们会按照上报的顺序响应安全请求的原则。
+
+
+
+**基础设施保障员**
+
+这个角色确保漏洞扫描、代码安全合规扫描等配套的安全工具正常工作，包括：
+
+- 确认工具的正常运行
+- 分发和处理工具扫描的结果。包括确保漏洞扫描发现的问题的正确分发，完成新软件包的合规扫描入库等
+- 分析和提出安全领域工具的优化需求
+
+
+
+**披露员**
+
+- 按照规则收集披露问题；
+- 向安全委员会提交披露申请，包括安全公告和安全问题；
+- 提供符合披露原则的披露相关公共消息发布。包括相关的披露信息、升级文档、日志变更、向公众解释严重性，将错误通知发送到邮件列表，请求CVE等。
+
+
+
+**安全联络员**
+
+该角色不是SC的成员，每一个SIG团队内都应该指定参与安全活动的SIG成员，这个角色应该由希望后继加入SC的成员承担。他们将负责：
+
++ 优先处理分发给本SIG团队内的安全问题
++ 提供本SIG内项目的安全问题披露内容
++ 协助开展安全流程改进，激励管理、审核代码或其他不公开的安全活动
+
+
+
+**发布团队**
+
+安全补丁发布团队属于[发布团队](sig-release)的一部分，他们在安全流程里会负责：
+
+- 刷新[发行商列表](private-distributors-list.md)——管理发行商列表
+
++ 组织和发布补丁——在必须提供安全修复程序时，组织涉及到的SIG内的Maintainer，管理构建和发布补丁
+
+**发布经理**有责任在整个生命周期内组织相关活动的开展，遵守安全问题处理和披露的流程要求。
+
+
+
+
+
+## 安全问题处理和披露流程
+
+### 1、安全问题收集
+
+####  CVE例行扫描
+
+- OpenHarmony社区会采用XXX漏洞扫描工具，对社区上使用的上游社区软件包公开披露的漏洞进行例行扫描和同步。
+- 扫描出的漏洞会按照[安全问题模板](template-security-bug.md)的格式向对应的SIG推送带有“CVE”标签的Issue
+
+
+
+#### 内部上报
+
+SIG内的bug被团队成员确认为安全漏洞，团队成员将对应的Issue调整成“私有”，同时添加“安全问题”标签，并根据实际情况添加“优先级”标签。安全问题分发员会定期查看此类问题的更新情况。
+
+
+
+####  外部上报
+
+如果您知道一个安全漏洞，不在OpenHarmony安全团队已经处理的公开安全漏洞的列表之内，烦请立即发送电子邮件至security@OpenHarmony.org通知SC，以便于他们可以启动补丁、发布和公告过程。
+
+请采用[安全流程电子邮件模板](template-security-bug.md)，同时您可以使用[OpenHarmony安全委员会](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是直接在公开的OpenHarmony存储库上进行的，同时可以在公开渠道讨论。同时修复团队可以在特定情况下（比如假期等）放慢发布过程。这些决策必须在安全会议上讨论。
+
+- 如果评估分数低于6（严重程度中等），高于4.0，则修复责任人也可以选择半公开进行修复。修复责任人将确定公开处理该修复程序是否会对用户造成伤害，以决定是否将对问题安全性方面的讨论限定在私有渠道。
+
+注意：修复责任人有权对漏洞的严重程度进行分类。
+
+
+
+#### 安全问题响应说明
+
+- 如果处理的是OpenHarmony社区开发项目的安全问题，则所有的计划时间表会尽快形成。
+- 如果不是，则修复程序依赖于上游社区的披露时间表。修复责任人会通过与上游社区的合作，尽量做到在适应上游社区时间表的同时，最大程度的保护OpenHarmony社区的用户。
+
+
+
+### 5、组织补丁开发
+
++ 如需要在私有安全库进行开发，修复负责人将使修复团队可以访问OpenHarmonyXXXXXX中的私有安全存储库，以开发修复程序。
++ 修复负责人将向[OpenHarmony CVE编号颁发机构申请CVE](cve-request.md)，**上游社区公开披露的CVE不需要此过程**。
++ 发布经理发布经理根据发布计划组织补丁开发
++ 私有ropo上相关修复文件已经提交到对应版本的软件包库，或者公开修复的软件包已经提交到对应的软件包库。发布经理将通知修复责任人——修复工作已经完成。
+
+注意：OpenHarmony私有安全存储库由SC拥有。组织管理由sig-infrastructure完成。
+
+
+
+### 6、修复披露
+
+随着修复的开展，修复负责人需要针对更广泛的社区范围提交总体沟通计划。总体沟通启动应该在修复团队制定了修复或缓解措施以后开始，以便可以将可达成的计划传递给用户。
+
+
+
+**发行商披露（可选）** （在问题确认后1~14天内完成）
+
++ 如果问题严重到需要尽早通知发行商，修复负责人将在修复团队的帮助下做出此决定。比如影响严重的“可远程利用”或“特权升级”等问题。否则可以跳过此过程。
++ 修复负责人将补丁程序通过电子邮件发送给dev@openharmony.io，以便发行商可以提前准备，并在发行版发布之日向用户提供版本。
+
+
+
+**修复发布日**（在问题确认后1~21天内完成）
+
++ 在即将发布前，至少提前24小时通过电子邮件通知[发行商](private-distributors-list.md)，通知信息应包含公共消息，公告的日期。
++ 修复负责人会将补丁推送到master分支和相关的发行版本分支。修复团队会使用/lgtm和/approve通过
++ 版本的发行经理会尽快merge这些PR。此时不应更改提交内容，以防止与发送给发行商的补丁程序产生不应有的冲突，以及在分支选择patch时发生冲突。
++ 发行经理应确保所有的二进制文件通过build，可公开使用且正常运行。
++ 修复负责人将提供新版本号、CVE编号（如有需要）、严重性和影响以及二进制文件的位置的信息给披露负责人，以支撑更广泛的分发和用户操作。此披露负责人将尽早将公告更新到社区页面，并应包括用户在升级到固定版本之前可以采用的任何缓解措施。公告将通过以下渠道发送
+  + security@OpenHarmony.org
+  + dev@openharmony.io
+  + [社区安全页面](https://OpenHarmony.org/zh/security.html)
+  +  在https://gitee.com/OpenHarmony/issues 中打开问题，并标记成`area/security`，并以相关CVE ID为前缀
+  
++ 如涉及，修复负责人将从私人安全存储库中删除修复团队
+
+
+
+### 7、修复流程回顾
+
+这些步骤应该在发布日期后的1~3天完成。回顾过程是改进的动力。
+
++ 修复负责人将该问题的回顾过程发送到security@openharmony.io，包括有关每个人的详细信息，过程时间表的执行情况，与引入该问题相关的PR链接，以及对响应和发布的任何处理或建议。
++ 鼓励发行经理和修复团队将自己的反馈意见发送到security@openharmony.io。诚实的批判是我们改善社区的唯一途径。
+
+
+
+## 安全问题处理和披露流程图示
+[图片上传中…(image-i8vUTgHlimtvQS1ys0Vo)]
+
+## 发行商名单
+
+该列表用于向OpenHarmony的发行商提供安全相关可操作的信息，请参考[发行商列表](private-distributors-list.md)
+
+

漏洞处理说明/private-distributors-list.md

+# 发行商名单
+
+该列表用于向多个发行商提供可操作性的信息。不提供个人查找安全问题。
+
+
+
+
+
+## 名单管理
+
+OpenHarmony通过用户组来管理发行商身份，请参考：
+
+
+
+
+
+
+
+## 进入发行商名单标准
+
+为了能够进入dev@openharmony.io的邮件列表，您的发行应支持：
+
+1、为我们的项目拥有一个受监控的安全电子邮箱别名
+
+2、积极维护或获得OpenHarmony的发行伙伴身份
+
+3、加入用户群组
+
+4、对已知收到的安全问题，都有可公开验证的记录
+
+5、成为社区的积极参与者和贡献者
+
+6、有代表参与OpenHarmony的分发过程
+
+说明：如果您不满足以上的条件，将为取消订阅。
+
+
+
+## 如何申请加入
+
+可以[在此处]()提交申请。
\ No newline at end of file

漏洞处理说明/security-disclosure.md

+# OpenHarmony安全和披露说明
+
+
+
+# 安全公告
+
+您可以从OpenHarmony的[安全公告和披露页面](https://harmonyostest.devccsrnd.hwcloudtest.cn:3089/cn/home)获取OpenHarmony产品安全公告和安全披露的电子邮件。
+
+
+
+## 上报漏洞
+
+我们感谢所有向OpenHarmony开源社区上报安全漏洞的安全研究人员和用户。安全委员会内会有社区志愿者对您上报的安全漏洞进行全面彻底的调查。
+
+您可以通过电子邮件将您发现的安全问题的详细信息以及错误报告发送到私有的security@openharmony.io邮箱列表。请你采用[安全问题模板](template-security-bug.md)。
+
+
+### 我应该合适上报漏洞
+
+- 您认为你在OpenHarmony中发现了潜在的安全漏洞
+- 您不确定漏洞可能会怎样影响OpenHarmony
+- 您在其他项目中发现了OpenHarmony依赖的漏洞，您可以附上已经上报给上游社区的链接
+
+
+
+### 什么时候不应该上报漏洞
+
+- 您想帮助提升OpenHarmony的安全能力
+- 您需要得到安全相关的帮助
+- 您的问题与安全性无关
+
+
+
+## 安全漏洞响应
+
+- OpenHarmony安全委员会成员会在3个工作日内确认并分析上报的安全问题，并同时启动安全处理流程。
+
+- 安全委员会确认安全问题后会对问题进行分发和跟进
+- 在安全问题从分类、确定到修复和发布的权过程中，我们会通过邮件及时更新报告
+
+
+
+## 公开披露时间
+
+- 公开披露的日期由OpenHarmony安全委员会和错误提交者协商确定。对于安全问题，一旦有用户缓解或规避措施，我们就会尽快将漏洞完全披露出来。
+- 在尚未完全理解和修改错误、解决方案未经过充分测试、或者未完成和发行商的协调时，延迟披露是不可避免的，也是合理的。
+- 在公开披露前，对部分问题我们会先向发行商披露，并在不影响发行商利益的前提下，尽量协同多个发行商间的发布时间。
+- 披露的时间从确认安全问题起，大概需要几周。对于具有明确的缓解或规避措施的漏洞，我们会尽量缩短披露时间在两周以内。
+- OpenHarmony安全委员会对设定的披露日期有最终决定权。
\ No newline at end of file

漏洞处理说明/template-security-bug.md

+# OpenHarmony 安全流程电子邮件模板
+
+这是电子邮件模板的集合，用于处理PSC需要处理的各种安全问题。
+
+
+
+## 安全问题上报模板
+
+主题：[最新公告]
+
+
+
+你好，OpenHarmony社区。
+
+在$COMPONENT版本的$OLDVERSION或更早版本发现了一个安全问题。严重等级是$SEVERITY，希望能够升级到$COMPONENT解决此问题。
+
+
+
+- 是漏洞吗？：
+  + 描述问题发生需要的场景（包括软硬件和交互场景等）
+  + 问题所造成的影响和影响的范围（包括版本范围）
+  + 如何确认使用的版本是否包含该问题
+
++ 如何缓解漏洞造成的影响
+  + 短期缓解方案
+  + 长期缓解方案：比如patch的安装地址、安装方式等
+
++ 漏洞的详情（如果是公开的CVE，请提供CVE编号）
\ No newline at end of file