17 Star 83 Fork 45

OpenHarmony / security

Create your Gitee Account
Explore and code with more than 8 million developers,Free private repositories !:)
Sign up
Clone or Download
README.md 8.21 KB
Copy Edit Web IDE Raw Blame History
almighty authored 2020-09-14 10:54 . update zh/security-process/README.md.

安全问题处理和发布流程

OpenHarmony已经采用本文中描述的安全披露和响应策略,以确保我们及时负责的处理安全问题。

目录

安全问题响应组

安全问题响应组负责社区对安全问题的响应和处理,包括内部沟通和外部披露,但整个过程需要在相关开发人员和发布经理的协助下完成。

工作职责

安全问题响应组的工作职责请参考README

修复责任人

跟踪协调每一个安全问题的从“生”到“死”

问题分发员

  • 确保应该处理问题的人员都已经收到通知

  • 响应还未被确认为安全问题的问题

  • 协助确认安全问题在OpenHarmony产品的评分

  • 如果开发者在处理安全问题的时候有分歧,也可以视需要上升到问题分发员。

  • 在线的安全问题响应组成员都会负责该工作,他们会按照上报的顺序响应安全请求的原则。

披露员

  • 按照规则收集披露问题;
  • 向安全问题响应组提交披露申请,包括安全公告和安全问题;
  • 提供符合披露原则的披露相关公共消息发布。包括相关的披露信息、升级文档、日志变更、向公众解释严重性,将安全问题通知发送到邮件列表,请求漏洞编号等。

安全联络员

该角色不是安全问题响应组的成员,每一个SIG团队内都应该指定参与安全活动的SIG成员,这个角色应该由希望后继加入安全问题响应组的成员承担。他们将负责:

  • 优先处理分发给本SIG团队内的安全问题
  • 提供本SIG内项目的安全问题披露内容
  • 协助开展安全流程改进,激励管理、审核代码或其他不公开的安全活动

安全问题处理和披露流程

1、安全问题收集

安全问题例行扫描

  • OpenHarmony社区会采用XXX漏洞扫描工具,对社区上使用的上游社区软件包公开披露的漏洞进行例行扫描和同步。
  • 扫描出的漏洞会向对应的SIG推送带有“安全问题”标签的Issue。

内部上报

SIG内的bug被团队成员确认为安全漏洞,团队成员将对应的Issue调整成“私有”,同时添加“安全问题”标签,并根据实际情况添加“优先级”标签。安全问题分发员会定期查看此类问题的更新情况。

外部上报

如果您知道一个安全漏洞,不在OpenHarmony安全团队已经处理的公开安全漏洞的列表之内,你可以按照以下方式处理:

邮件通知: 烦请立即发送电子邮件至scy@openharmony.io通知安全问题响应组,以便于安全问题响应组可以启动补丁、发布和公告过程。 收到上报邮件后,安全问题分发员会在社区内新建一个安全Issue。

社区Issue: 你可以在发现问题的社区中创建问题Issue,并标记成安全问题,创建问题的时候请选择“私有”Issue。

如果有需要,安全问题响应组将询问您是否可以通过负责人的方式秘密披露此问题。如果您反对,我们将采用公开披露的方式。

社区的漏洞奖励措施正在筹划中,会在后期上线。

2、安全问题确认

安全问题分发员会完成对新问题的确认,包括:

  • 对于外部上报的安全问题,确定受影响的项目和软件包。
  • (包括外部上报问题和安全问题)联系相关工程师(会优先从项目的Maintainer和Committer中选择),推动尽快确认是否是新的安全问题。确认后将Issue(私有)分发到对应的repo。
  • 对于外部上报的安全问题,确认后通知问题上报人。

确认结果记录在Issue的进展内,并调整Issue的状态进入解决阶段。

3、成立修复团队

修复负责人将组织修复团队,修复团队包括:

  • 对应的版本或补丁发布经理

  • 受影响项目的SIG成员,优先选择前期已经参与问题分发阶段的团队成员(定义在其对应的OWNERS文件内)

4、制定修复计划

对于每一个漏洞,修复责任人会与修复团队,发布经理进行协调,并负责向社区相关成员发送电子邮件。修复责任人会根据问题的严重性,开发需要的时间和发布经理反馈的版本计划,综合自己最佳的判断来制定问题的修复计划。

安全问题影响性评估

修复负责人和修复团队将使用CVSS计算器创建一个CVSS。他们会将使用“严重性评估——我们如何进行漏洞评分”来确定错误的影响和严重性。修复负责人对计算出的风险进行最终评估。

  • 如果评估分数低于4.0(严重性分数较低)或评估的风险较低,则修复责任人可以选择半公开进行修复。这意味着PR是直接在公开的OpenHarmony存储库上进行的,同时可以在公开渠道讨论。同时修复团队可以在特定情况下(比如假期等)放慢发布过程。这些决策必须在安全会议上讨论。

  • 如果评估分数低于7(严重程度中等),高于4.0,则修复责任人也可以选择半公开进行修复。修复责任人将确定公开处理该修复程序是否会对用户造成伤害,以决定是否将对问题安全性方面的讨论限定在私有渠道。

注意:修复责任人有权对漏洞的严重程度进行分类。

安全问题响应说明

  • 如果处理的是OpenHarmony社区开发项目的安全问题,则所有的计划时间表会尽快形成。
  • 如果不是,则修复程序依赖于上游社区的披露时间表。修复责任人会通过与上游社区的合作,尽量做到在适应上游社区时间表的同时,最大程度的保护OpenHarmony社区的用户。

5、组织补丁开发

  • 修复负责人将向OpenHarmony 社区提交安全问题Issue。
  • 发布经理发布经理根据发布计划组织补丁开发。
  • 私有repo上相关修复文件已经提交到对应版本的软件包库,或者公开修复的软件包已经提交到对应的软件包库。发布经理将通知修复责任人——修复工作已经完成。

6、修复披露

随着修复的开展,修复负责人需要针对更广泛的社区范围提交总体沟通计划。总体沟通启动应该在修复团队制定了修复或缓解措施以后开始,以便可以将可达成的计划传递给用户。

修复发布日(在问题确认后1~21天内完成)

修复负责人将提供新版本号、安全问题编号(如有需要)、严重性和影响以及二进制文件的位置的信息给披露负责人,以支撑更广泛的分发和用户操作。此披露负责人将尽早将公告更新到社区页面,并应包括用户在升级到固定版本之前可以采用的任何缓解措施。公告将通过以下渠道发送

7、修复流程回顾

这些步骤应该在发布日期后的1~3天完成。回顾过程是改进的动力。

  • 修复负责人将该问题的回顾过程发送到scy@openharmony.io,包括有关每个人的详细信息,过程时间表的执行情况,与引入该问题相关的PR链接,以及对响应和发布的任何处理或建议。
  • 鼓励发行经理和修复团队将自己的反馈意见发送到scy-priv@openharmony.io。诚实的批判是我们改善社区的唯一途径。

Comment ( 0 )

Sign in to post a comment

1
https://gitee.com/openharmony/security.git
git@gitee.com:openharmony/security.git
openharmony
security
security
master

Search