代码拉取完成，页面将自动刷新
openEuler已经采用本文中描述的安全披露和响应策略，以确保我们及时负责的处理安全问题。
目录
安全委员会（SC）负责整个社区对安全问题的响应，包括内部沟通和外部披露，但整个过程需要在相关开发人员和发布经理的协助下完成。SC将由订阅了openEuler安全邮件列表（私有）(openeuler-security@openeuler.org)的志愿者组成。
SC的工作职责请参考README
成员应保持积极主动的态度
延长休假1个月或更长时间的成员应与其他成员进行协调，以确保在休假期间为该角色配备足够的人员
休假1~3个月的成员可以确定一个临时的替补
角色成员可以罢免其他未请假，但无法联系超过1个月或者未履行其书面职责超过1个月的成员。这个罢免也通过“多数共识“完成
半年内缺席例会6次及以上的成员，视为自动退出。
SC一般由7位成员组成，成员人数原则上不少于6人，不多于9人。
任何成员任何时候均可提出新成员提名，通过例会审视和投票。
新成员通常从技术指导委员会、发行经理或补丁发行经理、以及SIG内负责安全工作的核心成员中提名。
提名的新成员通过“懒惰的共识”完成投票（反对票不足现有成员1/3则通过）。
为了让新加入的成员熟悉安全委员会的工作职责和流程，新加入SC成员将首先担任至少三个月的准成员
成员随时可以退出，并从合格的准成员中提议替代成员。如成员退出需要投票，将按照“多数共识”完成
由于安全处理流程涉及到多个环节和对应的职责，SC的成员会被赋予一些特定的角色，以更加明确的承担这些环节的职责。以下是各个角色的定义，这些角色会定期进行轮换，以保证每一个人都有机会了解openEuler的安全处理机制
问题分发员/安全响应协调人
事件触发型或周期型角色，通过主动承担或决策分配产生，随事件处理结束而结束。
确保应该处理问题的人员都已经收到通知
响应还未被确认为安全问题的问题
协助确认安全问题在openEuler产品的评分
如果开发者在处理安全问题的时候有分歧，也可以视需要上升到问题分发员。
在任的SC成员都会负责该工作，他们会按照上报的顺序响应安全请求的原则。
修复责任人
固定角色，跟踪协调对应安全问题的从“生”到“死”，以责任田形式分配相关项目或领域。协助漏洞修复：协助Maintainer开展漏洞分析、评估和修复建议等工作，包括提供相关漏洞检测工具。
基础设施保障员/安全工具应用人
固定角色，这个角色确保漏洞扫描、代码安全合规扫描等配套的安全工具正常工作，包括：
披露员
固定角色，周期性执行漏洞披露流程。
安全联络员
该角色不是SC的成员，每一个SIG团队内都应该指定参与安全活动的SIG成员，这个角色应该由希望后继加入SC的成员承担。他们将负责：
发布团队
安全补丁发布团队属于发布团队的一部分，他们在安全流程里会负责：
发布经理有责任在整个生命周期内组织相关活动的开展，遵守安全问题处理和披露的流程要求。
在漏洞响应和修复处理之外，安全委员会还需构建社区安全能力和提供安全工具解决方案，相应设立以下角色：
规范建设推进人
固定角色，规划并推进规范建设。构建社区安全能力：结合业界和社区的优秀实践，制定openEuler社区安全设计和安全编码等规范和指导。
规范应用推广人
固定角色，配合规范建设推进人计划并推行落地行动。构建社区安全能力：通过培训和研讨等多种方式分享安全规范，协助SIG和开发团队构建安全能力。
安全流程看护人
固定角色，为安全响应，漏洞披露，漏洞分析提供周期性的流程改进服务
SIG内的bug被团队成员确认为安全漏洞，团队成员将对应的Issue调整成“私有”，同时添加“安全问题”标签，并根据实际情况添加“优先级”标签。安全问题分发员会定期查看此类问题的更新情况。
如果您知道一个安全漏洞，不在openEuler安全团队已经处理的公开安全漏洞的列表之内，烦请立即发送电子邮件至openeuler-security@openeuler.org通知SC，以便于他们可以启动补丁、发布和公告过程。
请采用安全流程电子邮件模板，同时您可以使用openEuler安全委员会成员的PGP公钥将电子邮件加密到此邮件。收到上报邮件后，安全问题分发员会在其repository内新建一个安全Issue。
如果有需要，SC将询问您是否可以通过负责人的方式秘密披露此问题。如果您反对，我们将采用公开披露的方式。
安全问题分发员会完成对新问题的确认，包括：
确认结果记录在Issue的进展内，并调整Issue的状态进入解决阶段。
修复负责人将组织修复团队，修复团队包括：
对应的版本或补丁发布经理
受影响项目的SIG成员，优先选择前期已经参与问题分发阶段的团队成员（定义在其对应的OWNERS文件内）
对于每一个漏洞，修复责任人会与修复团队，发布经理进行协调，并负责向社区相关成员发送电子邮件。修复责任人会根据问题的严重性，开发需要的时间和发布经理反馈的版本计划，综合自己最佳的判断来制定问题的修复计划。
修复负责人和修复团队将使用CVSS计算器创建一个CVSS。他们会将使用“严重性评估——我们如何进行漏洞评分”来确定错误的影响和严重性。修复负责人对计算出的风险进行最终评估。
如果评估分数低于4.0（严重性分数较低）或评估的风险较低，则修复责任人可以选择半公开进行修复。这意味着PR是直接在公开的openEuler存储库上进行的，同时可以在公开渠道讨论。同时修复团队可以在特定情况下（比如假期等）放慢发布过程。这些决策必须在安全会议上讨论。
如果评估分数低于6（严重程度中等），高于4.0，则修复责任人也可以选择半公开进行修复。修复责任人将确定公开处理该修复程序是否会对用户造成伤害，以决定是否将对问题安全性方面的讨论限定在私有渠道。
注意：修复责任人有权对漏洞的严重程度进行分类。
注意：openEuler私有安全存储库由SC拥有。组织管理由sig-infrastructure完成。
随着修复的开展，修复负责人需要针对更广泛的社区范围提交总体沟通计划。总体沟通启动应该在修复团队制定了修复或缓解措施以后开始，以便可以将可达成的计划传递给用户。
发行商披露（可选） （在问题确认后1~14天内完成）
修复发布日（在问题确认后1~21天内完成）
在即将发布前，至少提前24小时通过电子邮件通知发行商，通知信息应包含公共消息，公告的日期。
修复负责人会将补丁推送到master分支和相关的发行版本分支。修复团队会使用/lgtm和/approve通过
版本的发行经理会尽快merge这些PR。此时不应更改提交内容，以防止与发送给发行商的补丁程序产生不应有的冲突，以及在分支选择patch时发生冲突。
发行经理应确保所有的二进制文件通过build，可公开使用且正常运行。
修复负责人将提供新版本号、CVE编号（如有需要）、严重性和影响以及二进制文件的位置的信息给披露负责人，以支撑更广泛的分发和用户操作。此披露负责人将尽早将公告更新到社区页面，并应包括用户在升级到固定版本之前可以采用的任何缓解措施。公告将通过以下渠道发送
area/security，并以相关CVE ID为前缀如涉及，修复负责人将从私人安全存储库中删除修复团队
这些步骤应该在发布日期后的1~3天完成。回顾过程是改进的动力。
该列表用于向openEuler的发行商提供安全相关可操作的信息，请参考发行商列表
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。