漏洞管理¶
OpenStack 项目认真对待安全漏洞报告并谨慎处理。OpenStack 软件的使用场景各不相同，但包括高知名度的服务和暴露的系统，如果未及时修复漏洞，很容易使敏感数据或其他资源面临被破坏的风险。
漏洞管理团队¶
OpenStack 拥有一个 漏洞管理团队 (VMT)，在项目中承担着多项职责。OpenStack VMT 为满足既定标准的 OpenStack 软件的 安全支持子集 提供直接的漏洞管理，但更重要的是，它维护着推荐的 流程、模板、报告分类法以及类似的工具，任何项目团队都可以应用这些工具来减轻管理自身漏洞报告的负担并发布相应的安全公告。
禁运漏洞管理¶
大多数 OpenStack 软件的安全漏洞报告最初都是在 https://bugs.launchpad.net/ 上创建的 私有 安全 漏洞，只有 OpenStack 漏洞管理团队 和最初的报告者可见。如果漏洞的严重程度足够高（根据许多特定于上下文的因素主观确定），将努力使其暂时保持私有状态，以便进行研究并讨论、开发和审查必要的修复程序。这种暂时的保密性被称为禁运，旨在为准备解决方案并将其传达给经过审核的利益相关者（例如软件发行版、部署者和服务提供商）提供时间，他们可能需要额外的时间才能在漏洞被公众知晓之前应用这些修复程序。
在禁运期间，主题专家（例如 联络员 和项目特定的核心安全审查团队）可能会订阅该漏洞，以提供见解并协助将其解决。一旦草拟了修复程序并警告了下游利益相关者，补丁就会被推送到正常的公共代码审查系统，并且会向 OpenStack 和通用的自由/开源软件邮件列表发送 安全公告 (OSSA)。
公开漏洞报告¶
许多 OpenStack 安全漏洞最初是在公开视图中开始的，要么是后来被发现暗示某种可利用条件中的错误和补丁，要么是报告者或主题专家认为严重性最低的报告，或者由于需要大量的社区参与才能彻底缓解相关风险，因此无法在私下轻松解决的问题。在禁运漏洞管理中，额外的资源和效率成本有时会超过短暂保密性的好处，但最终仍然会导致安全公告。
安全联系人¶
如果漏洞报告者选择不自行提交漏洞报告，但仍希望私下报告漏洞，他们可以向 VMT 成员的 OpenPGP 密钥 发送加密的电子邮件，以代表他们创建一个 私有 安全 漏洞。
安全增强¶
在审查了疑似漏洞报告中提出的情况后，认为没有必要发布相关的安全公告的情况并不少见。影响此决定的因素包括漏洞是否真正可利用、它是否是普遍存在于 OpenStack 软件中的常见/已知条件、修复程序是否可以安全地回溯到稳定分支而不会引入潜在的破坏性行为更改、它是否依赖于已经记录为不安全的配置、它是否需要另一个更严重的漏洞才能成功利用，或者它是否是其他依赖项而不是 OpenStack 软件本身的漏洞。
这些仍然可能需要修复的错误，并且可能提高软件的整体纵深防御安全性，也就是所谓的安全加固机会。在许多情况下，非公告建议仍可能以 安全说明 (OSSN) 的形式发布，或者作为 OpenStack 安全指南 的附录。此外，新的和现有的项目都可以受益于 OpenStack 安全团队 提供的各种主动资源，例如 安全开发指南 和 Bandit 源代码安全分析器。
