关于披露行业漏洞
漏洞披露是漏洞报告者（如安全研究人员）和项目维护者之间协作非常重要的领域。 双方需要从发现潜在有害安全漏洞的那一刻起共同努力，直到向世界披露漏洞，最好有可用的修补程序。 通常，当有人让维护者私下了解安全漏洞时，维护者会开发修复程序、验证修复程序并通知项目或包的用户。
漏洞的初始报告是私下发布的，并且只有在维护者确认问题后才会公布全部详细信息，最好提供补救或修补程序，有时会延迟，以便有更多的时间安装修补程序。 有关详细信息，请参阅 OWASP 备忘单系列网站上的“关于漏洞披露的 OWASP 备忘单系列”。
漏洞报告者的最佳实践
私下向维护者报告漏洞是一项良好的做法。 如果可能，作为漏洞报告者，我们建议您避免：
- 公开披露漏洞而不给维护者补救的机会。
- 绕过维护者。
- 在代码的修复版可用之前披露漏洞。
- 在没有公共奖励方案的情况下，报告某个问题时期望得到补偿。
漏洞报告者如果已尝试联系维护者但未收到回复，或与已联系他们但被要求等待很久才能披露，则在一段时间后公开披露漏洞是可以接受的。
我们建议漏洞报告者在报告过程中明确说明其披露政策的条款。 即使漏洞报告者不遵守严格的政策，最好在预期漏洞披露的时间表上对维护者设定明确的期望。 有关披露策略的示例，请参阅 GitHub 安全实验室网站上的“安全实验室披露策略”。
维护者最佳实践
作为维护者，最佳做法是明确说明您想如何和在何处收到关于漏洞的报告。 如果此信息不可明确，但漏洞报告者不知道如何联系您，可能寻求从 git 提交历史记录中提取开发人员电子邮件地址，以尝试找到适当的安全联系人。 这可能导致摩擦、丢失报告或发布未解决的报告。
维护者应及时披露漏洞。 如果您的仓库存在安全漏洞，我们建议您：
- 在响应和披露中，将漏洞视为安全问题，而不是简单的错误。 例如，您需要明确提及问题在发布说明中是一个安全漏洞。
- 即使没有即时的调查资源，也应尽快确认收到漏洞报告。 这传递了这样一个信息：您可以快速响应并采取行动，并为您与漏洞报告者之间的其余互动设定了积极的基调。
- 当您验证报告的影响和真实性时，请让漏洞报告者参与。 漏洞报告者可能已经花时间考虑了各种情景中的漏洞，其中一些情况您自己可能都没有考虑过。
- 以你认为合适的方式解决这个问题，认真考虑漏洞报告者提出的任何关切和建议。 通常，漏洞报告者会了解没有安全研究背景时容易错过的某些角落案例和补救旁路。
- 始终将漏洞的发现归功于漏洞报告者。
- 目标是尽快发布修复。
- 确保您在披露漏洞时让更广泛的生态系统意识到问题及其补救措施。 在项目当前开发分支中修复已识别的安全问题，但提交或后续版本未明确标记为安全修复或发布的情况并不少见。 这可能给下游消费者造成问题。
发布安全漏洞的详细信息不会使维护者看起来很糟糕。 安全漏洞在软件中随处可见。用户会信任那些在其守则中明确制定了安全漏洞披露程序的维护者。
关于在 GitHub 上报告和披露项目中的漏洞
GitHub 上有两个可用的进程：
- 标准过程：漏洞报告者使用位于存储库安全策略中的联系人信息与存储库维护人员取得联系。 然后，如有需要，存储库维护人员将创建草案存储库公告。
- 私人漏洞报告：漏洞报告者通过提出草案存储库公告并提供其发现的详细信息，私下直接向存储库维护人员披露漏洞详细信息。
标准过程
在 安全 Bug 赏金](https://bounty.github.com/)”网站。
如果您是维护者， 您可以在管道开始时通过为您的仓库设置安全策略来掌控这一过程，或者以其他方式使安全报告说明清楚可用，例如在项目的 README 文件中。 有关添加安全策略的信息，请参阅“将安全策略添加到存储库”。 如果没有安全策略，漏洞报告者可能会尝试向您发送电子邮件或以其他方式私下与您联系。 或者，有人可能会开一个（公共）议题讨论安全问题的细节。
作为维护者，要在您的代码中披露漏洞，请先在 GitHub 中软件包的仓库内创建安全通告。 使用存储库安全公告，公共存储库的维护人员可私下讨论和修复项目中的安全漏洞。 协作得到修补程序后，存储库维护人员可发布安全通知，向项目社区公开安全漏洞。 通过发布安全通知，存储库维护人员可使其社区更轻松地更新包依赖项并对安全漏洞的影响进行调查。 有关详细信息，请参阅“关于存储库安全公告”。
若要开始操作，请参阅“创建存储库安全公告”。
私人漏洞报告
公共存储库的所有者和管理员可以对其存储库启用专用漏洞报告。 有关详细信息，请参阅“为存储库配置私人漏洞报告”。
私人漏洞报告为漏洞报告者提供了一种简单的方法，可以在 GitHub 中向存储库维护人员私下披露安全风险，并即时将该问题告知给存储库维护人员。 有关安全研究人员和存储库维护人员的详细信息，请分别参阅“私下报告安全漏洞”和“管理私下报告的安全漏洞”。