修复安全漏洞¶
Bugzilla 中已报告一个安全敏感的漏洞，并已获得安全评级。
如果此漏洞是私密的（对于已报告的安全漏洞来说最有可能），则**修补流程与修复普通漏洞的流程略有不同**。
如果您参与审查、测试和落地安全补丁，请遵循以下安全指南。有关如何请求安全审批和落地补丁的更多详细信息，请参阅安全漏洞审批流程。
保护隐私信息¶
Bugzilla 中的安全敏感漏洞意味着除漏洞 ID 号以外的所有信息都将隐藏。这包括标题、评论、报告人、指派人和抄送的人员。
安全敏感漏洞通常会保持私密状态，直到在新版本中发布修复程序，**并在确保最大数量的用户更新其 Firefox 版本后的一段时间内**。漏洞通常在 6 个月和几个版本之后公开。
从私下报告安全漏洞的那一刻起，到发布修复程序并将漏洞设置为公开的那一刻起，需要谨慎处理有关该漏洞的所有信息，以避免在发布修复程序之前（0 天漏洞）已知的未缓解漏洞被利用。
在正常流程中，可以通过以下方式访问有关漏洞性质的信息
Bug 评论（Bugzilla、GitHub 问题）
提交消息（在 Bugzilla、树检入和测试服务器上可见）
代码注释
测试用例
Bug 内容可能会在公开的 IRC/Slack 频道和邮件列表电子邮件中进行讨论。
在修补安全漏洞时，您需要注意您共享的信息类型和位置。
在提交消息中¶
人们一直在关注代码检入，因此我们希望避免共享在向用户发布修复程序之前过早地泄露或帮助轻松找到漏洞的信息。这包括
漏洞的**性质**（溢出、使用后释放、XSS、CSP 绕过等）
**触发和利用该漏洞的方法** - 在提交消息、代码注释和测试用例中。
Bug/提交与安全相关的事实
提交消息或代码注释中的**触发词**，例如“security”、“exploitable”或安全漏洞的性质（溢出、使用后释放等）
提交消息中的**安全审批人的姓名**。
受漏洞影响的 Firefox 版本和组件。
具有明显修复程序的补丁。
在 Bugzilla 和其他公共渠道中¶
除了提交之外，您还需要注意不要在公共场所（例如 Bugzilla）中泄露有关漏洞的敏感信息
在私有 Bug 的评论中提及这些 Bug。
不要在与公共相关的 Bug 中评论敏感信息。
还要注意您向谁提供 Bug 访问权限：**在抄送错误的人或别名之前仔细检查**。
最近，您现在可以在“重复”、“依赖于”、“阻止”、“回归”、“由…导致回归”或“另请参阅”部分添加公共 Bug。Bugzilla 仅会向具有
editbugs权限或安全漏洞访问权限的人员显示这些关系。
在 IRC、Slack 频道、GitHub 问题、邮件列表中：如果您需要讨论安全漏洞，请使用私有频道（使用密码或适当的权限访问管理进行保护）
开发期间¶
测试安全漏洞¶
推送到 Try 服务器需要 1 级提交访问权限，但**内容查看是公开可访问的**。
尽可能**不要推送到 Try 服务器**。应在检入之前在本地进行测试，以防止公开泄露漏洞。
由于公开可见性，推送到 Try 与提交补丁具有相同的顾虑。在考虑之前，请注意落地补丁（有或没有安全审批）部分中的顾虑，并在执行此操作之前与安全团队联系以获取非正式的“安全审批”。
不要将漏洞本身的测试用例推送到 Try。
如果您需要推送到 Try 服务器，请确保您的测试不会泄露漏洞的相关信息或如何触发它。不要在任何地方提及它与安全相关。
混淆安全补丁¶
如果您的安全补丁由于其包含的代码而显得过于明显（例如，一行修复），或者您确实需要推送到 Try 服务器，请**考虑将您的安全相关补丁集成到同一区域中的非安全工作中**。并且/或者假装它与其他内容相关，例如某些性能改进或正确性修复。**绝对不要在提交消息中包含 Bug 号。**这将有助于使安全问题难以识别。（关于“安全通过模糊”的绝对禁令与加密系统有关。在其他情况下，您仍然不能依赖模糊，但它有时可以为您争取一点时间。在这种情况下，我们需要将修复程序更快地交付给我们的用户，而不是攻击者能够将其武器化和部署攻击，而一点额外的时间可以提供帮助。）
请求安全审批¶
有关更多详细信息，请参阅安全漏洞审批流程
落地补丁（有或没有安全审批）¶
在请求安全审批或落地之前，请确保您的补丁不会不必要地泄露有关安全漏洞的信息。具体来说
补丁提交消息及其内容不应提及安全、安全漏洞或安全审批人。请注意，您可以直接在 Phabricator 中更改提交消息，如果这是您唯一需要做的事情 - 您无需修改本地提交并重新推送它。虽然通常鼓励使用全面的提交消息；但对于安全漏洞，应省略它们，而应在 Bug 中发布（最终将公开发布。）
将测试分离到单独的提交中。**在落地补丁时不要落地测试。请记住，我们不想自曝其短！**这包括推送到 Try 时。
测试应稍后检入，在包含修复程序的正式 Firefox 版本上线至少 4 周后。例如，如果 Firefox 53 包含影响全球的安全问题，并且该问题在 54 中已修复，则此修复程序的测试不应在 54 上线 4 周后检入。
例外情况是，如果存在不影响任何发布分支的安全问题，仅影响 mozilla-central 和/或其他开发分支。由于安全问题从未发布给全球，因此一旦在所有受影响的位置修复了 Bug，就可以将测试检入到各个分支中。
有两种主要技术可以记住稍后检入测试
将安全 Bug 克隆到一个单独的“任务”Bug 中，**该 Bug 也位于安全敏感组中以确保它不可公开访问**，命名为“为 Bug xxxxx 落地测试”，并指派给自己。它应该获得“sec-other”关键字评级。
提示：在 Phabricator 中，如果您已将测试分离，则可以更改与提交链接的 Bug，同时保留先前授予的审查，这意味着您只需在准备好时落地补丁，而不是让您的审查者和您必须记住一两个月后的情况。
或者，将“in-testsuite”标志设置为“？”，并在稍后将测试检入时将其设置为“+”。
落地测试¶
测试可以在**包含修复程序的版本上线至少 4 周后落地**。
例外情况是，如果安全问题从未在发布版本中发布，并且已在所有开发分支中修复。
公开安全漏洞¶
这是安全管理团队的责任。
要点¶
在包含修复程序的版本上线足够长的时间以供用户更新其软件之前，不要泄露有关漏洞的任何信息.
这包括代码注释、提交消息、测试、公共通信渠道。
如有疑问：'''请求安全审批？'''
如有疑问：**需要安全人员提供信息**。
如果没有评级，请假设最坏的情况，并将漏洞视为安全关键级.