获得对事件的了解

我们监控着安全问题的多种信息来源。

这包括多种公开或非公开的安全邮件列表、我们的主要联系地址（security@suse.de）、Novell Bugzilla（和其他供应商的 bug 追逐系统）、软件包版本更新、 Mitre 与 NVD CVE 数据库、和其他供应商的顾问。这些来源有意重叠，以确保我们不会错过任何事件。

此外，我们自己的源代码审计也经常发现问题。

一旦发现一个事件，它会被添加到 Novell Bugzilla 。（这些 bug 通过不会向公众公开），如果你想要了解这些 bug 的样本和我们的处理方法，你可以点击这个链接。

漏洞报告包括：

然后，它被提交给打包者。

(安全团队本身只在很少情况下自己修复软件包，因为打包者最了解他的软件包和周围的社区。)

打包者

打包者接受这些补丁（或创建它们），并将它们应用于所有旧有支持的发行版中的软件包。

必要时，他与上游的开发者进行沟通。

他通常用修复安全问题后发布的新上游版本来更新当前的开发树。

当他完成后，他将这些软件包提交给受影响的发行版的签收暂存目录。

我们通常只向旧版本的软件包回传安全修复，以避免与系统的现有部分发生交互。en:SDB:Backports 是一篇关于这个主题的好文章。

构建系统团队审查提交的软件包（以避免在软件包工作期间出现在修复中出现错误或类似情况），并将软件包签入构建系统。

然后构建系统会自动构建软件包。

构建系统团队也会将元补丁信息签入系统，然后生成一套 YOU 补丁源供 QA 使用。这组二进制文件是固定的，将以这种方式交付给所有客户。

QA 团队利用这些生成的补丁源，像客户看到的那样测试更新：

如果更新工作正常，而且之后的程序也能正常工作。

运行软件包现有的测试用例，并检查回归情况。

在更新前和更新后对漏洞（如果有的话）进行测试。它在之前必须是可复制的。

并且在更新后不能重现。

如果一切都通过了，就给予更新的 QA 批准。

安全团队批准发布更新（遵守披露时间表）。

自动机制会将更新通知发布到邮件列表、Novell 客户中心，以及更新通知索引页。