跳转至

OpenCloudOS 安全漏洞披露策略

1. 概述

OpenCloudOS 社区将发行版及其组件的安全性视为首要责任。社区实行协同漏洞披露(Coordinated Vulnerability Disclosure, CVD):在修复方案可用之前,不公开漏洞细节;修复发布后,及时、完整、可验证地公开信息。

本策略说明:如何向社区报告漏洞、社区的响应承诺、漏洞如何评级与修复、以及安全公告如何发布。本策略面向安全研究者、下游厂商、用户和上游社区。

本策略不涉及社区基础设施(官网、构建系统、代码托管)被攻击,以及源码投毒等安全事件的内部应急流程。

2. 适用范围

本策略适用于:

  • OpenCloudOS 所有在维护期内的发行版本及其内核;
  • 社区软件仓库中分发的全部软件包;
  • 社区自行开发或维护的组件、补丁与构建配置。

不适用于:

  • 已结束生命周期(EOL)的版本 —— 社区不再为其提供安全修复,建议升级到在维护期内的版本;
  • 第三方在 OpenCloudOS 之上自行构建的衍生发行版或商业产品 —— 请联系相应供应方;
  • 上游项目中与 OpenCloudOS 无关的问题 —— 建议直接报告给上游项目,社区可协助转交。

在维护期内的版本及生命周期策略,见《版本生命周期》。

3. 如何报告漏洞

3.1 报告渠道

报告类型 渠道
未公开的漏洞(0day、尚无 CVE 编号) 邮件至 security@opencloudos.tech,建议使用 PGP 加密
已公开的漏洞(已有 CVE 编号,需确认 OpenCloudOS 是否受影响) 邮件至 security@opencloudos.tech,无加密要求

请勿在公开的 Issue、邮件列表、社交媒体或代码提交信息中描述未公开的漏洞细节。

PGP 公钥:https://keys.openpgp.org/vks/v1/by-fingerprint/7A556C4804B196CD87F1FB9CE6BCD4FE7B7BAC04

社区同时按 RFC 9116 发布 security.txt。

3.2 报告内容

为便于快速验证和评估,请在报告中尽量包含:

  1. 受影响范围:组件或软件包名称、版本号、OpenCloudOS 发行版本、硬件架构;
  2. 漏洞描述:漏洞类型、成因、触发条件;
  3. 影响说明:攻击者可获得什么(如远程代码执行、权限提升、信息泄露、拒绝服务),以及所需的前置条件(是否需要认证、本地访问、非默认配置);
  4. 复现方式:环境配置、复现步骤,以及 PoC(如有);
  5. 修复建议:建议的补丁或缓解措施(如有);
  6. 公开情况:该漏洞是否已在其他渠道公开,是否已向上游或其他发行版报告,是否已有 CVE 编号;
  7. 披露计划:你期望的公开时间,以及是否计划发表文章或在会议上演讲;
  8. 署名意愿:希望在公告中如何署名,或要求匿名。

仅提供自动化扫描工具原始输出、缺少人工分析和可复现证据的报告,社区可能无法受理。

3.3 匿名报告

接受匿名报告。但匿名报告无法进行技术追问,处理深度会受限,也无法完成协同披露时间的协商。

4. 社区的响应承诺

阶段 时限 说明
确认收到 2 个工作日内 由人工回复,非自动回复
初步结论 10 个工作日内 给出三种结果之一:确认漏洞并给出评级、说明不构成漏洞的理由、或说明需要更长分析时间并承诺下次反馈时间
进度同步 每 14 天 在漏洞关闭前定期同步进展
流程结束通知 修复发布后 告知报告者公告编号与公开时间(匿名报告除外)

每份报告均由安全 SIG 指定专人跟进,负责推动评估、修复与披露的全过程。

5. 对报告者的期望与安全港

5.1 期望

  • 仅在证明漏洞存在所必需的范围内进行验证,不扩大影响;
  • 不访问、修改、删除他人数据,不破坏服务可用性;
  • 不利用漏洞获取超出验证目的的权限或数据;
  • 不向第三方提供可直接利用的攻击工具;
  • 在协商的公开时间之前,不向第三方披露漏洞细节。

5.2 安全港

对于遵守本策略的善意研究行为,社区承诺:

  • 不要求签署保密协议(NDA);
  • 不就该研究行为向报告者追究法律责任,也不要求第三方追究;
  • 除法律要求或公开披露所必需外,不向第三方披露报告者的个人信息。

若存在恶意意图、以漏洞牟利或造成实际损害的证据,上述承诺不适用。

5.3 漏洞奖励

社区不设置漏洞赏金(Bug Bounty)计划,不提供金钱或实物报酬。社区通过安全公告署名和致谢页面向报告者表达认可。

6. 漏洞评估

6.1 评分标准

社区支持 CVSS v3.1 和 CVSS v4.0 两种评分标准。评分针对漏洞在 OpenCloudOS 中的实际影响,而非漏洞的通用理论影响。

评估原则:

  • 基于真实可达的攻击场景评分,而非假设最坏情况;
  • 存在多个攻击场景时,取影响最大者;
  • 库或依赖组件的漏洞,按其在 OpenCloudOS 中的实际使用方式评分;
  • 若 OpenCloudOS 的默认配置、编译选项或加固机制(如 SELinux 策略、模块默认不加载、FORTIFY、PIE)阻断或削弱了利用,相应下调评分或等级,并在公告中说明理由。

因此,OpenCloudOS 的评分可能与 NVD 或上游 CNA 不同。涉及 OpenCloudOS 时,建议优先参考社区给出的评分。社区在安全中心页面同时展示 NVD、上游 CNA 与 OpenCloudOS 三方评分,便于对照。

6.2 影响等级

除 CVSS 分数外,社区给出 EARS(漏洞可利用与攻击风险等级)五档分级,用于确定修复优先级:

等级 定义
Critical(严重) 此类漏洞具有极强的破坏性,通常允许未经身份验证的远程攻击者在系统默认配置下轻松利用,且无需用户交互,即可导致系统完全被控制(例如获得远程 root 权限)、远程数据窃取或大规模数据丢失。此类漏洞通常已知存在活跃的在野利用,或极有可能被用于发起大规模攻击。
建议操作:请立即更新至最新版本,以阻断潜在的大规模攻击。
Important(高危) 此类漏洞可造成重大安全影响,在特定环境配置下易于被利用,可能导致严重的远程拒绝服务(DoS)、本地权限提升、或本地数据窃取/丢失。历史上类似漏洞曾有利用案例,因此被利用的可能性较高,存在被针对性攻击的风险。
建议操作:请尽快安排升级,以防止被针对性利用。
Moderate(中危) 此类漏洞虽可造成重大影响,但通常受到更多限制,例如需要依赖特定配置、用户权限或用户交互才能被利用,其影响可能包括网络服务拒绝服务、跨站脚本攻击或获取普通用户权限。由于需要更专业的知识或复杂的利用条件,且近期无活跃的在野利用趋势,其被利用的可能性较低。
建议操作:建议在后续常规的更新周期中安排修复。
Low(低危) 此类漏洞安全性影响一般,实际损害很小。利用通常需要非常复杂的配置、较高的现有权限以及用户交互配合,因此极难被成功利用。
建议操作:通常无需紧急处理,可在后续包含多个修复的累积更新中一并解决。
Negligible(可忽略) 此类问题仅在理论上存在安全风险,在实际环境中几乎不可能造成损害或仅在极为特殊和罕见的配置下出现。其利用代码几乎不可能用于真实攻击,且历史上未发现积极利用案例。
建议操作:一般无需专门关注或更新,不影响系统的正常使用。

影响等级反映社区对漏洞严重程度的技术判断。该等级不因是否出现公开利用代码而改变,仅在出现新的技术细节时重新评估。

一份公告包含多个漏洞时,公告整体等级取其中最高者。

6.3 修复时限目标

自漏洞确认之日起,社区对在维护期内版本的修复目标为:

等级 修复目标
Critical 7 个自然日内
Important 30 个自然日内
Moderate 90 个自然日内
Low 不保证修复,随后续常规更新发布
Negligible 不保证修复,随后续常规更新发布

存在在野利用、或已被 CISA KEV 等权威目录收录的重大漏洞,不受上述等级限制,按最高优先级处理,必要时先发布缓解措施再发布补丁。

对于确实无法修复的问题(如上游已停止维护、修复会破坏兼容性),社区将在公告中说明原因并提供缓解方案。

7. 协同披露与禁发期

7.1 禁发期(Embargo)

修复方案尚未就绪时,社区与报告者及其他相关方协商统一的公开时间,在此之前漏洞信息仅在必要知悉范围内共享(按 TLP:RED 处理)。

  • 社区倾向于较短的禁发期,通常建议 14 至 30 天;
  • 已验证的漏洞最长在 90 天内公开;确有正当理由(如修复复杂、需多方协调)时,可延长一次,最多再延 90 天;
  • 社区尊重报告者或上游社区已经确定的披露时间,并遵守其约定。

7.2 禁发期失效

出现以下任一情形,社区视为漏洞已公开,将立即发布已掌握的信息,不论修复是否完成:

  • 任何一方提前公开了漏洞信息;
  • 公共代码仓库中出现明确指向该安全问题的提交;
  • 漏洞细节已在公开渠道被讨论或被第三方独立披露。

7.3 上游与下游协同

  • 漏洞位于上游项目时,社区在报告者同意的前提下,协助将问题转交上游,并与上游的披露时间保持一致;
  • 漏洞属 OpenCloudOS 自有组件且影响下游衍生发行版时,社区在公开前向下游厂商发出预警;
  • 涉及多方的复杂协调,社区可通过 CERT/CC 的 VINCE 等平台进行。

7.4 研究者自行发表

报告者计划自行发表研究成果(文章、会议演讲、PoC)时,请与社区协调时间,并遵守同一披露时间约定。社区不限制报告者发表其研究内容。

8. CVE 编号

  • 漏洞位于上游项目且该项目已有对应的 CNA(如 Linux 内核由 kernel.org CNA 负责)时,CVE 编号由该 CNA 分配,社区协助推动;
  • 漏洞位于社区自有组件、且不在其他 CNA 范围内时,社区负责为其申请 CVE 编号;
  • 社区在安全公告中完整引用相关的 CVE 编号,并在安全中心维护 CVE 与受影响软件包、修复版本、公告编号的对应关系。

9. 安全公告

9.1 发布内容

修复发布后,社区发布 OpenCloudOS 安全公告(OpenCloudOS Security Advisory, OCSA),编号格式为 OCSA-YYYY:NNNN。公告包含:

  • 漏洞描述与影响说明;
  • 对应的 CVE 编号;
  • CVSS 评分与影响等级;
  • 受影响的发行版本、软件包与架构;
  • 修复版本与升级方式;
  • 缓解措施(若适用);
  • 报告者署名(经其同意)。

9.2 获取渠道

渠道 地址
安全公告页面 https://security.opencloudos.tech/advisories
漏洞库页面 https://security.opencloudos.tech/cves
机器可读数据(CSAF 等) 详见:https://docs.opencloudos.org/security/security_data_api/

社区不提供公告的提前通知服务。所有公告面向公众开放,不需要登录或订阅商业服务。

10. 致谢

社区在安全公告与致谢页面中向漏洞报告者致谢。报告者可选择:

  • 以真实姓名、代号或所属机构名义署名;
  • 不署名(匿名)。

默认情况下,社区会为报告者署名;如需匿名,请在报告中说明。

11. 策略维护

  • 本策略由 OpenCloudOS 安全 SIG 维护;
  • 策略变更通过社区邮件列表公告,并在本页记录版本与生效日期;
  • 对本策略的意见与建议,可发送至 security@opencloudos.tech。