关于行业中披露漏洞的做法
漏洞披露是一个需要漏洞报告者（如安全研究人员）与项目维护者密切合作的领域。双方需要从发现潜在有害安全漏洞的那一刻起合作，直至向全世界披露该漏洞，理想情况下同时提供修补程序。通常，当有人私下向维护者通报安全漏洞时，维护者会开发修复方案、进行验证，并通知项目或软件包的用户。
漏洞的首次报告是私下进行的，完整细节仅在维护者确认问题并理想情况下提供修复或补丁后才会公开发布，有时会延迟发布以便有更多时间安装补丁。欲了解更多信息，请参阅 OWASP Cheat Sheet 系列关于漏洞披露的介绍。
漏洞报告者的最佳实践
向维护者私下报告漏洞是良好的做法。在可能的情况下，作为漏洞报告者，我们建议您避免
- 在未给予维护者修复机会的情况下公开披露漏洞。
- 绕过维护者。
- 在代码修复版本尚未可用时披露漏洞。
- 在不存在公开赏金计划的情况下，期望因报告问题而获得报酬。
如果漏洞报告者已尝试联系维护者但未得到回复，或被要求等待过长时间才可披露，则在经过一定时间后公开披露漏洞是可以接受的。
我们建议漏洞报告者在报告流程中明确说明其披露政策的条款。即使漏洞报告者并未遵循严格的政策，明确的时间线期望也有助于维护者了解何时会进行披露。有关披露政策示例，请参阅 GitHub Security Lab 的披露政策。
维护者的最佳实践
作为维护者，明确说明您希望通过何种渠道接收漏洞报告是良好的做法。如果这些信息不明确，漏洞报告者将不知道如何联系您，可能会尝试从 git 提交历史中提取开发者的电子邮件地址以寻找合适的安全联系人。这会导致摩擦、报告丢失或未解决报告的公开。
维护者应及时披露漏洞。如果您的仓库中存在安全漏洞，我们建议您
- 将漏洞视为安全问题而非普通错误，在响应和披露时均如此。例如，您需要在发行说明中明确指出该问题是安全漏洞。
- 即使暂无资源立即进行调查，也应尽快确认收到漏洞报告。这表明您响应迅速并会采取行动，为您与漏洞报告者的后续互动奠定积极基调。
- 在验证报告的影响和真实性时应让漏洞报告者参与进来。报告者很可能已经在多种情景下评估过该漏洞，其中一些场景您可能未曾考虑。
- 以您认为合适的方式修复问题，并仔细考虑漏洞报告者提供的任何关注点和建议。报告者通常了解一些边缘情况和规避修复的方法，若没有安全研究背景可能会被忽视。
- 在归功于发现时始终感谢漏洞报告者。
- 尽快发布修复。
- 在披露漏洞时，请确保让更广泛的生态系统了解该问题及其修复方案。常见的情况是，已修复的安全问题只在项目的当前开发分支中提交，但该提交或随后的发布并未明确标记为安全修复或安全发布，这会给下游使用者带来问题。
公开漏洞细节并不会让维护者形象受损。软件中无处不在的安全漏洞是常态，用户会信任那些拥有明确、成熟漏洞披露流程的维护者。
关于在 GitHub 项目中报告和披露漏洞
GitHub 提供两种流程
- 标准流程：漏洞报告者使用仓库安全策略中提供的联系方式联系仓库维护者。如有必要，维护者随后会创建草稿仓库 advisory。
- 私密漏洞报告：漏洞报告者通过提交草稿仓库 advisory 并提供其调查结果，直接且私密地向仓库维护者披露漏洞细节。
标准流程
在 GitHub 上报告和披露项目漏洞的流程如下
如果您是漏洞报告者（例如安全研究人员）并希望报告漏洞，请首先检查相关仓库是否已有安全策略。更多信息请参阅 向您的仓库添加安全策略。如果已有，请遵循其指引了解流程后再联系该仓库的安全团队。
如果仓库尚未制定安全策略，建立与维护者私密沟通的最有效方式是创建一个 issue，询问首选的安全联系人。请注意，该 issue 会立即公开可见，因而不应包含任何漏洞信息。建立沟通后，您可以建议维护者为后续使用制定安全策略。
注意
仅针对 npm - 若我们收到 npm 包中的恶意软件报告，我们会尝试私下联系您。如果您未及时处理该问题，我们将公开披露。更多信息请参阅 npm 包恶意软件报告指南。
如果您在 GitHub 上发现安全漏洞，请通过我们的协调披露流程报告该漏洞。更多信息请参阅 GitHub 安全漏洞赏金计划 网站。
如果您是维护者，可在流程的最初阶段通过为仓库设置安全策略或在项目的 README 等位置明确提供安全报告指南来主导整个流程。有关添加安全策略的说明，请参阅 向您的仓库添加安全策略。若没有安全策略，漏洞报告者可能会尝试通过电子邮件或其他私密方式联系您，或者直接在公开 issue 中提供安全问题细节。
作为维护者，要披露代码中的漏洞，首先在 GitHub 上为该包的仓库创建草稿安全 advisory。仓库安全 advisory 让公共仓库的维护者能够私密讨论并修复项目中的安全漏洞。协作完成修复后，维护者可以公开发布该 advisory，以向项目社区披露安全漏洞。通过发布安全 advisory，维护者可便于社区更新依赖并研究漏洞影响。更多信息请参阅 关于仓库安全 advisory。
要开始使用，请参阅 创建仓库安全 advisory。
私密漏洞报告
公共仓库的所有者和管理员可以在仓库中启用私密漏洞报告。请参阅 为仓库配置私密漏洞报告。
私密漏洞报告为安全研究者提供了一种安全、结构化的方式，在 GitHub 内直接向仓库维护者私下披露安全风险。当漏洞被报告后，维护者会立即收到通知，能够在不提前公开的情况下审查并响应。
如果没有明确的联系渠道，安全研究者可能会觉得只能公开披露漏洞，例如在社交媒体发布、打开公开 issue，或通过非正式渠道联系维护者，这会给用户带来不必要的风险。
对于安全研究者，使用私密漏洞报告的好处包括：
- 一种清晰、结构化的联系方式
- 更流畅的披露与讨论漏洞细节的流程
- 能够与仓库维护者私下讨论漏洞细节
- 在修复可用之前，降低漏洞细节公开的风险
对于维护者，使用私密漏洞报告的好处包括：
- 在同一平台上接收并处理报告
- 安全研究者代表维护者创建或发起 advisory 报告
- 在修复可用之前，降低漏洞细节公开的风险
- 有机会与安全研究者私下讨论漏洞细节并协作修补程序
安全研究者也可以使用 REST API 私密报告安全漏洞。请参阅 仓库安全 advisory 的 REST API 端点。
注意
如果包含漏洞的仓库未启用私密漏洞报告，安全研究者和仓库维护者都需要遵循上文 标准流程 中的说明。
后续步骤
如果您是安全研究者，请参阅 私密报告安全漏洞，了解如何私下向仓库维护者报告漏洞。
如果您是仓库维护者，请参阅 为仓库配置私密漏洞报告 以在您的仓库中启用此功能，或参阅 创建自定义安全配置 在组织层面统一管理。