Repositories Overseen

所有 OpenStack 源代码仓库中报告的可疑漏洞，只要符合以下规定，都将直接受到 VMT 的监督。

Requirements

1. 对于私下提交的可疑漏洞报告，保密期限不得超过 90 天，除非在特殊情况下。 保密期限到期后，无论是否发布了安全公告或提供了补丁，报告都将公开可见。

2. VMT 不会跟踪或发布外部软件组件的安全公告。 只有官方 OpenStack 项目团队提供的源代码才有资格接受 VMT 的监督。 例如，服务器/容器镜像中包含的基础操作系统组件或编译二进制工件中引入的库都不在 VMT 的范围内。

3. Repositories 必须具有版本化的发布才能符合 VMT 的监督条件。 如果漏洞出现在官方发布版或维护的稳定分支上（请参阅 Stable Branch Maintenance Phases），则该漏洞值得发布安全公告。 仅存在于最新发布版本后的 master 分支上，或仅存在于未维护的分支上的漏洞，VMT 不会协调其披露。 预发布版本、发布候选版本和里程碑不被视为本策略目的上的官方发布版本。

4. 每个受监督仓库的缺陷跟踪器必须配置为最初仅允许 VMT 访问私下提交的报告。 VMT 负责确定报告的可疑漏洞是否针对正确的仓库，并在可能的情况下进行重定向，因为报告者通常不熟悉我们的项目结构，可能会选择错误的位置。 这意味着项目团队对私下报告的可疑漏洞的初步分类控制权有所丧失，但有助于最大限度地减少在公开披露之前不必要地了解这些漏洞的人数，从而降低过早结束保密期限的风险。

5. 团队必须指定一个安全问题专用的联系人，以便 VMT 可以与他们联系以对潜在漏洞的报告进行分类。 拥有超过五个核心评审人员的团队应（为了限制私有报告的不必要暴露）确定其中一部分人员作为安全核心评审人员，他们的职责是能够确认错误报告是否准确/适用，或者至少了解其他可以及时执行这些活动的领域专家。 他们还应该能够审查并预先批准附加到私有错误的补丁，这就是为什么至少大多数人预计会成为其仓库的核心评审人员的原因。 这些人员应成为团队缺陷跟踪器中的一个群组联系人，以便 VMT 可以轻松地订阅他们的新报告。

6. 团队必须指定一个 security liaison，作为 VMT 在严重或长期存在的漏洞报告未能获得有效解决时的升级点。 如果没有明确指定，PTL 将是该团队的默认联络人。

7. Repositories 应该对重要功能进行自动化测试。 测试需要对 VMT 和安全评审人员来说是可行的，以便在保密期间本地运行以评估补丁，并且还必须在 OpenStack 官方持续集成基础设施的上下文中运行。 这有助于降低在公开代码审查时匆忙通过安全修复而产生新错误的风险，并减少 VMT 在后期发布勘误补丁的工作量。

8. 鼓励项目对他们的软件进行审查、审计或威胁分析，以主动识别潜在的安全漏洞。 如果项目团队执行此操作，结果最好也由第三方验证（这可以是社区中未直接参与该项目成员）。 建议在每个主要发布版本之后立即刷新分析，但过时的分析仍然比完全没有分析更有用。 这是一项建议，旨在将 VMT 的工作量降至最低，但不是严格要求。