openSUSE:安全披露策略
披露策略
SUSE 安全团队定期审计包含在 (open)SUSE 发行版和相关产品中的软件。有关我们如何以及何时进行此操作的详细信息，请 阅读此处。
在这些审计过程中，我们有时会发现安全问题。这包括（但不限于）
- 代码本身中的安全漏洞
- 薄弱的默认配置
- 与其他组件的有害交互
我们对这些问题实行协调披露。这意味着我们会通过私有渠道通知内部和外部利益相关者，以便他们有机会与我们讨论报告的问题并准备修复方案。
为了确保我们发现的问题不会一直保密太久，我们制定了一项政策，规定在最长 90 天的禁运期后，必须向公众公开报告的信息。这包括没有为最终用户提供可用修复方案的情况。我们这样做是为了确保没有已知的安全问题一直保密，从而让用户了解他们正在使用的软件的安全状况。如果未收到回复，我们保留随意缩短禁运期的权利。
如果对 CRD 日期或问题本身没有达成一致，我们将在最多 90 天后公开信息，以便社区有机会采取行动并自行决定。
我们使用 openSUSE Bugzilla 实例来跟踪安全审计以及我们发现的问题。当我们打开关于安全问题的 Bugzilla 条目时，我们会将当前的协调发布日期 (CRD，信息公开的时间) 标记在以下格式的错误注释中
内部 CRD：2020-12-12 [或更早 | 预定]
可选的或更早表示我们可以随时公开信息的情况（例如，SUSE 内部代码，没有外部上游）。当上游尚未同意特定日期时，我们会在末尾使用预定标签。在这些情况下，一旦达成一致，我们会使用明确的 CRD 更新错误（通常更早）。
CRD 的开始不是从创建错误本身开始，而是在明确声明之后。在初始报告中，我们通常会建议较短的禁运期，为期 14 到 30 天，具体取决于发现的复杂性和进一步的背景。在私下讨论中，可以建立更长的禁运期，但 90 天是硬性限制。
我们还通过其他方式（主要是电子邮件）传达这些截止日期。对于非 (open)SUSE 方，如果拥有合适的通信渠道，我们将会在 CRD 届满前 30 天和 15 天通知他们（可能略有变化，因为这目前是手动完成的，因此发生在德国工作日）。
当 SUSE 员工负责修复安全问题（例如，因为它属于 SUSE 维护的代码或配置）时，我们会通知 - 该员工的经理在 CRD 前 15 天 - 报告链中的下一个人在 CRD 前 5 天，如果所有受影响的产品都没有可用于内部测试的修复方案。这有助于解决打包者未响应的情况，例如，因为他们不在。
对于仅在 openSUSE 上存在的软件包，如果没有（活跃）维护者，我们将向 openSUSE Factory 提交删除请求，如果安全问题未在给定时间内得到修复。这样做是为了确保带有已知安全问题的软件包不会被包含在新产品中。
如果上游或其他相关方通过未遵循协调披露流程（例如，在当前分配的 CRD 之前发布错误修复提交或更新）违反了已建立或提供的禁运期，则 SUSE 安全团队可能会考虑立即发布所有相关信息。