漏洞管理流程¶

OpenStack 漏洞管理团队负责协调漏洞的逐步披露。

团队成员是独立且注重安全的个人，他们确保及时处理漏洞，并以协调和公平的方式通知下游利益相关者。如果团队成员受雇于下游利益相关者，则该成员不会提前向其雇主通报任何漏洞。为了减少早期阶段的漏洞披露，该团队的成员人数有意限制在少数人。

支持版本¶

漏洞管理团队协调修复 OpenStack 维护的稳定分支（对应于之前的发行版本）中的漏洞，以及所有受监管的仓库中的 master 分支（下一个开发版本）。

流程¶

每个安全漏洞都会分配给 VMT 协调员（漏洞管理团队成员），他们将推动修复和披露流程。以下是我们遵循的步骤。

接收¶

报告可以通过加密的私人电子邮件发送给 VMT 的一位成员，也可以作为 StoryBoard 或 Launchpad 安全漏洞（选中“这是一个安全问题”复选框）接收。

VMT 执行的第一个步骤是

如果在 StoryBoard 或 Launchpad 中尚不存在漏洞，则创建一个漏洞
检查报告是否指明了正确项目，并根据需要进行调整
在报告描述前添加一个禁运提醒，包括其禁运的截止日期
为 openstack/ossa 或 ossa 项目添加一个 待办/不完整 任务
订阅项目的核心安全审查团队，以确认影响并确定受影响的分支
添加带有不完整接收消息的评论

一旦 VMT 确认需要 OSSA，ossa 漏洞任务状态将被设置为 进行中/已确认。如果对是否需要 OSSA 提出质疑，则 ossa 漏洞任务状态应恢复为 待办/不完整，直到解决该问题为止。

如果不需要 OSSA 并且没有 OSSN 的好处，则 ossa 漏洞任务将被设置为 不会修复 或无效（取决于跟踪器和情况），并且漏洞状态将从 私人安全 切换为公开，可以选择性地添加一个安全漏洞标签，如果报告涉及潜在的安全加固机会。具体内容索引在报告分类和 OSSA 任务状态表中。

补丁开发¶

对于私人报告，报告者（如果直接作为漏洞报告）和受影响项目的核心安全审查团队以及他们认为有必要开发和验证补丁的任何人都会被添加到漏洞的订阅列表中。补丁作为对当前 master 分支（以及任何受影响的支持分支）的补丁提出，并附加到私人漏洞报告中，不会发送到公共代码审查系统。

对于公共报告，无需直接订阅任何人，补丁可以直接提交到代码审查系统，而不是作为漏洞附件（尽管漏洞应在任何提交消息中引用，以便自动更新）。

如果在流程的这个阶段或任何后续阶段遇到项目方面的延误，VMT 和其他相关方可能会联系该项目的安全联络员，要求他们更加关注该问题。

补丁审查¶

对于私人报告，一旦初始补丁已附加到漏洞，项目中的订阅列表中的核心审查人员应审查它并提出更新或预先批准合并。私下开发的补丁需要预先批准，以便在披露时可以加快通过公共代码审查的速度。

对于公共报告，OpenStack 通常的公共代码审查和批准流程适用。

起草影响描述¶

与此同时，VMT 协调员准备一个漏洞描述，该描述将传达给下游利益相关者，并作为最终发布的 Security Advisory 的基础。

该描述应正确署名报告者，指定受影响的版本（包括不受支持的版本），并准确描述影响和缓解机制。VMT 协调员应使用以下模板。一旦发布描述，openstack/ossa 或 ossa 漏洞任务状态应切换为 审查/分类。

审查影响描述¶

该描述由报告者和 PTL 验证。

发送 CVE 请求¶

为了确保完全的可追溯性，我们尝试在向更广泛的公众传达问题之前获得 CVE 分配。这通常在补丁接近最终批准时完成。ossa 漏洞任务状态设置为 进行中，并且批准的影响描述通过 MITRE 的 CVE 请求表单提交。

OpenStack 的安全分类与 MITRE 期望的不完全匹配，因此以下是填写请求表单的检查清单。（表单会随着您填写而动态增长输入字段。）

在页面顶部
- 请求类型 是 报告漏洞/请求 CVE ID
- 电子邮件地址 应为请求者的电子邮件地址（通常，在 VMT 官方管理的报告中，分配给 VMT 的协调员的电子邮件地址）
- 对于禁运报告，协调员的 OpenPGP 密钥应粘贴到提供的字段中。
在“在提交此请求之前……”框中
- 选中指示产品未被 CNA 覆盖的复选框
- 选中未分配先前的 CVE ID 的复选框
在必需部分
- 选择适当的漏洞类型（如果下拉列表中没有相关内容，则使用 其他或未知 输入自由文本类型）
  - 这将生成一个新的其他漏洞类型 必填字段，您可以在其中放置 CWE 标识符（如果您知道匹配项）或 CWE-noinfo（如果您不知道）
- 将供应商 设置为 OpenStack
- 将产品和版本字段设置为与影响描述中的 $PROJECTS 和 $AFFECTED_VERSIONS 相匹配
在可选部分
- 将单选按钮设置为已确认/已确认 为 是
- 从下拉列表中选择适当的攻击类型（通常，对于我们的情况，这是 上下文相关）
- 选中相关的影响复选框
  - 如果您选中“其他”，将打开一个自由文本字段，您可以在其中键入影响
- 如果可能，尝试填写受影响的组件 和 攻击向量 字段
- 将来自影响描述的散文的建议描述 粘贴到其中（通常省略第一句话，因为它与其他字段重复）
- 将 $CREDIT 详细信息放入发现者/署名 字段
- 在参考资料 字段中，放入漏洞 URL（以及 Gerrit 中补丁的 URL，如果已经公开）
- 如果报告仍然是私有的，请在附加信息 字段中注明这一点，并添加一些文本，例如 此报告目前处于禁运状态，并且尚未安排披露日期。
在页面底部
- 填写安全码
- 单击提交请求 按钮

如果某些字段包含无效数据，它们将以红色突出显示；更正这些，更新安全码 并再次提交请求，直到您收到确认页面。注意：如果您离开页面，您可能将丢失所有输入的内容。

获取分配的 CVE¶

MITRE 返回分配的 CVE。它被添加到漏洞中（在 Launchpad 的右上角查看“链接到 CVE”，或在 StoryBoard 中使用故事评论），并且漏洞标题更改为“$TITLE ($CVE)”。

禁运披露¶

一旦补丁获得批准并且分配了 CVE，就会将带有漏洞描述的签名电子邮件发送给下游利益相关者。披露日期设置为 5-10 个工作日，不包括周一/周五和节假日，时间为 1500 UTC。不应在披露日期之前部署公共补丁。一旦发送电子邮件，任何请求订阅报告的利益相关者都可能被添加。

对于非禁运的公共漏洞，不会向下游发送单独的提前通知。相反，一旦收到 CVE 分配并开始 OSSA 编写，OSSA 漏洞任务状态将被设置为 fix committed 状态。

打开漏洞，推送补丁¶

作为准备，请确保您有核心审查人员 和 稳定维护人员 可用，以帮助在披露时推送修复程序。

在披露时间

删除 Launchpad 漏洞上的禁运提醒
打开漏洞以使其公开。Launchpad 将向订阅任何受影响项目的每个人发送初始通知电子邮件
提醒推送补丁的人，他们应该在提交消息中包含“Closes-bug”或“Related-bug”行，引用漏洞
将补丁推送到 Gerrit 以供 master 和受支持的稳定分支审查；加快批准，因为补丁已经在 Launchpad 漏洞上过审查
将漏洞标题更新为“[OSSA-$NUM] $TITLE”

MITRE 的 CVE 请求表单此时应再次使用，但选择请求类型 为 通知 CVE 关于发布 并填写协调员的电子邮件地址，提供指向公告的链接（如果这是官方 OSSA，则为 https://security.openstack.org/ 上的 URL），涵盖的 CVE ID 和发布日期。再次，填写页面底部的安全码 并提交请求。

发布 OSSA¶

在推送补丁后不久（可能等待第一个测试运行完成），将公告发布到 OpenStack ML。等待所有补丁合并到受支持的分支后，再将 ossa 漏洞任务状态设置为 修复已发布。

所有补丁已合并¶

经过代码审查批准的补丁不一定会立即合并，但应密切跟踪它们，直到它们合并（如果提交消息中正确标识了漏洞编号，则会自动更新以反映这一点）。然后，如果需要，可以标记受影响软件的后续安全点版本。

异常禁运终止¶

如果报告在禁运期间持续 90 天没有修复，或者报告的重大细节在公共场所被披露，则 VMT 协调员会在那时终止禁运，后续流程将切换到公共报告工作流程。

报告分类¶

VMT 现在使用此分类列表来协助漏洞报告分类，尤其是在漏洞不需要公告时。

类别	结果	描述
类别 A	OSSA	需要在 master 和所有受支持版本中修复的漏洞
类别 B1	OSSN	只能在 master 中修复的漏洞，稳定分支的安全说明，例如默认配置值不安全
类别 B2	OSSN	尚未完成修复的漏洞，所有版本的安全说明，例如糟糕的架构/设计
类别 B3	OSSN	实验性或调试功能中存在的漏洞，不用于生产用途
类别 C1	潜在的 OSSN	不被认为是一个实际的漏洞（但有些人可能会为其分配 CVE）
类别 C2	潜在的 OSSN	一个漏洞，但不在 OpenStack 支持的代码中，例如在依赖项中
类别 D	潜在的 OSSN	不是漏洞，只是一个具有（一些）安全影响的错误，例如加强机会/误导性文档
类别 E		既不是漏洞也不是加固机会
类别 Y		仅在开发版本中发现的漏洞
类别 Z		当正当程序失败时

OSSA 任务状态¶

以下是不同 OSSA 任务状态含义的摘要

状态	含义
待办/不完整	尚不清楚报告是否需要公告
进行中/已确认	漏洞已确认，影响描述正在进行中
审查/分类	影响描述已提交进行审查
合并/修复已发布	所有补丁都已合并
无效/不会修复	无需进一步操作

披露范围¶

漏洞管理的科学在于能够评估报告的影响和严重性，能够设计安全补丁，成为一个追求完美且一丝不苟的过程遵循者，并尊重较少披露的原则。

较少披露是指随着时间的推移，将漏洞细节披露给越来越多的人，但仅限于达到下一步骤所需的人员。上图显示了流程各个步骤中的“披露范围”。

漏洞报告者保留对其发现的披露的最终控制权。如果出于某种原因他们对我们的流程感到不舒服，他们的披露条款选择将优先。

禁运例外¶

为了使禁运期简短有效，VMT 可能会选择公开漏洞报告。修复时间过长（例如，超过 2 周）或需要复杂补丁的问题通常更适合公开解决。除非在特殊情况下，任何禁运期不应超过 90 天。

下游利益相关者¶

OpenStack 作为上游项目，被许多发行版、产品、私有和公共服务产品使用，这些产品会受到漏洞的负面影响。为了配合协调披露，这个生态系统，统称为下游利益相关者，需要提前收到警告，以便能够准备补丁并在披露日以协调的方式推出它们。禁运期保持在自愿较短的时间（3-5 个工作日），作为在长时间隐藏漏洞和不给下游利益相关者反应时间之间的折衷方案。

如果您目前不是引用的利益相关者，但认为您绝对应该包含在该电子邮件分发列表中，请向漏洞管理团队的成员提交带有理由的电子邮件。

模板¶

接收禁运提醒（私有问题）¶

This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past $NINETY_DAYS and will be made
public by or on that date even if no fix is identified.

NINETY_DAYS 值应为报告被协调员接受并订阅了项目审查人员之日起的 90 天。可以使用 date -I -d90days shell 命令轻松计算。如前所述，此禁运提醒是在漏洞报告的“Bug 描述”字段的开头添加的。

接收不完整消息（未确认问题）¶

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

此句子应作为（或包含在）漏洞报告上的第一条评论中添加。

影响描述 ($DESCRIPTION)¶

Title: $TITLE
Reporter: $CREDIT
Products: $PROJECT
Affects: $AFFECTED_VERSIONS

Description:
$CREDIT reported a vulnerability in [project feature name].
By doing [action] a [actor] may [impact] resulting in [consequence].
Only [project deployment mode] are affected.

AFFECTED_VERSIONS 需要在发布修复程序后保持有效。例如，当 kilo、liberty 和 mitaka 仍然受安全支持时，keystone 的 AFFECTED_VERSIONS 应该如下所示

Affects: >=2015.1.0 <2015.1.5, >=8.0.0 <8.1.1 and ==9.0.0

一旦 kilo 到达生命周期结束，该行将变为

Affects: >=8.0.0 <8.1.1 and ==9.0.0

如果受影响的最旧版本不易识别，请将其留空

Affects: <8.1.1 and ==9.0.0

按照惯例，< 版本是遵循三组件语义版本规则的下一个可能的补丁版本发布，因此，如果给定分支上当前受影响的最高版本是 8.1.0，则受影响的版本包括 <8.1.1，即使下一个实际标记的版本可能是 8.2.0 或 9.0.0（但由于我们不知道发布时下一个版本会是什么，因此我们选择它可能成为的最低版本）。这种约定也明确了预发布版本可能不足以解决漏洞。

下游利益相关者通知电子邮件（私有问题）¶

我们发送两封单独的电子邮件，以避免 linux-distros 的无关回复

收件人： embargo-notice@lists.openstack.org
- 主题： [pre-OSSA] OpenStack $PROJECT ($CVE) 中的漏洞
- 此电子邮件必须使用 VMT 发件人的 OpenPGP 密钥签名。 该密钥的指纹发布在 https://security.openstack.org/vmt.html
收件人： linux-distros@vs.openwall.org
- 主题： [vs] OpenStack $PROJECT ($CVE) 中的漏洞
- 此电子邮件必须
  - 使用 VMT 发件人的 OpenPGP 密钥签名，并且
  - 使用 linux-distros 公钥加密（见下文）
  - 请注意主题行：前四个字符必须是 [vs]（即，左方括号、小写 ‘v’、小写 ‘s’、右方括号、空格），否则列表自动化可能会拒绝该电子邮件

两封电子邮件的正文应相同

This is an advance warning of a vulnerability discovered in
OpenStack, to give you, as downstream stakeholders, a chance to
coordinate the release of fixes and reduce the vulnerability window.
Please treat the following information as confidential until the
proposed public disclosure date.

$DESCRIPTION

Proposed patch:
See attached patches. Unless a flaw is discovered in them, these
patches will be merged to their corresponding branches on the public
disclosure date.

CVE: $CVE

Proposed public disclosure date/time:
$DISCLOSURE, 1500UTC
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

Original private report:
https://launchpad.net/bugs/$BUG
For access to read and comment on this report, please reply to me
with your Launchpad username and I will subscribe you.
--
$VMT_COORDINATOR_NAME
OpenStack Vulnerability Management Team
https://security.openstack.org/vmt.html

对于 DISCLOSURE，请使用 ISO-8601 样式的 YYYY-MM-DD。

建议的补丁附加到电子邮件中。为补丁附件文件名使用独特且具有描述性的名称，例如，cve-2013-4183-master-havana.patch 或 cve-2013-4183-stable-grizzly.patch。由于附加到 Launchpad 漏洞的补丁可能是在获得 CVE 编号之前编写的，因此您可能需要重命名补丁。理想情况下，补丁文件名应包含 CVE 编号、OpenStack 组件名称（如果涉及多个组件）以及应用补丁的分支。

注意

linux-distros 邮件列表的要求是，附件文件名应为字母数字，但点、减号和下划线字符允许在文件名中（但不作为文件名的第一个字符），因此请在重命名补丁文件时记住这一点。

如上所述，两封电子邮件都必须使用 GPG 签名。确保您使用的是指纹发布在 https://security.openstack.org/vmt.html 的密钥，以便有一个公共位置与 OpenStack VMT 相关联，您可以在该位置独立找到您的密钥。

请注意，发布到 linux-distros 应该加密到 https://oss-security.openwall.org/wiki/mailing-lists/distros 的密钥，并期望回复使用您签名消息的密钥进行加密。

OpenStack 安全公告 (OSSA)¶

文档首先作为 yaml 描述提交到 ossa 项目，使用此模板

date: YYYY-MM-DD

id: OSSA-$NUM

title: '$TITLE'

description: '$DESCRIPTION_CONTENT'

affected-products:
  - product: $PROJECT
    version: $AFFECTED_VERSIONS

vulnerabilities:
  - cve-id: $CVE

reporters:
  - name: '$CREDIT'
    affiliation: $CREDIT_AFFILIATION
    reported:
      - $CVE

issues:
  links:
    - https://launchpad.net/bugs/$BUG

reviews:
  kilo:
    - https://review.opendev.org/$MASTER_REVIEW

  juno:
    - https://review.opendev.org/$STABLE_REVIEW

notes:
  - 'Optional note such as cross project version requirements'

注意

DESCRIPTION_CONTENT 从 yaml 文件中提取并直接插入到生成的重构文本文件中。因此，它可能包含 RST 标记，如下所示（换句话说，不要过度使用）。请参阅存储库中的 OSSA yaml 文件以获取示例。

另一个含义是，描述的行长度由您在 YAML 文件中使用的内容决定。由于您最终会将生成的 RST 文件内容粘贴到电子邮件消息中，因此您可能希望将描述内容中的行长度保持在不会在电子邮件中换行的长度。

获得批准后，查看 gate-ossa-docs 输出并浏览呈现的 HTML 建议，然后更改 URL 以在第一个路径组件之前插入 _sources/ 并将文件扩展名更改为 rst 以获取生成的 RST 文档。我们发送两封单独的电子邮件，以避免 oss-security 列表的无关回复

收件人： openstack-announce@lists.openstack.org, openstack-discuss@lists.openstack.org
收件人： oss-security@lists.openwall.com

两封电子邮件的主题和内容相同

主题： [OSSA-$NUM] $PROJECT: $TITLE ($CVE)
正文： 生成的 RST 文档

说明

电子邮件必须使用 GPG 签名。
$CVE 必须始终采用 CVE-YYYY-XXXX 的形式
$NUM 采用 YYYY-XXX 的形式

漏洞管理流程

漏洞管理流程¶

支持版本¶

流程¶

接收¶

补丁开发¶

补丁审查¶

起草影响描述¶

审查影响描述¶

发送 CVE 请求¶

获取分配的 CVE¶

禁运披露¶

打开漏洞，推送补丁¶

发布 OSSA¶

所有补丁已合并¶

异常禁运终止¶

报告分类¶

OSSA 任务状态¶

披露范围¶

禁运例外¶

下游利益相关者¶

模板¶

接收禁运提醒（私有问题）¶

接收不完整消息（未确认问题）¶

影响描述 ($DESCRIPTION)¶

下游利益相关者通知电子邮件（私有问题）¶

OpenStack 安全公告 (OSSA)¶

目录