具有公共存储库的开源项目应如何最好地处理安全报告但尚未公开披露的安全漏洞的拉取请求（PR）？
我参与了一个有数百位贡献者的开源项目。作为定期计划的每月发布的一部分，我们每年发布几次安全公告和漏洞。在发布修补程序版本之前，我们不会发布有关漏洞的信息。我们能够在项目管理系统（JIRA）中安全地管理安全问题。但是，在将安全漏洞提交给GitHub时，我们没有一个很好的流程来掩盖可修复安全漏洞的PR。我们担心人们会在发布这些修补程序之前找到这些修补程序，并创建零日漏洞利用。
我们已经考虑过使用私有存储库来派生主存储库，但是我们当前的大部分审查和质量检查工作流都在PR上进行。如果我们将工作流仅移交给安全团队的私人仓库，则可以将修补程序公开时的时间减少到生成压缩包并将其发布到sourceforge所需的时间，这将是一个很大的改进。我们还可能需要避免将PR合并到我们的公开Beta中。
在朝这个方向发展之前，我想知道在具有开放存储库的开源项目中处理预发行安全性漏洞修复补丁的最佳实践是什么？如果可以通过使用不同于GitHub的平台来更好地解决问题，那么我应该提到我们正在评估迁移到GitLab的过程。
1
我不确定是否有最佳做法。GitLab本质上是一个私有GitHub。平衡开源和安全修补程序的关注并非易事。您有多少安全修复程序来自安全团队以外的人员？
—
Berin Loritsch
大多数问题是由其他人报告的，但可能只有不到五分之一的修复来自非安全团队。
—
Joe Murray
在我看来，如果您需要将流程的某些部分设为私有，则应在GitHub之外完成（因为GH是公共的）；在完成这一特定部分并且每个人都检查了其代码之后；您可以在GH上创建PR，并将其尽快合并，以“返回”正式流程。您可以使用其他工具来管理流程中的那些异常。
—
艾默生·卡多佐
完全立即披露（即立即公开披露）是完全合法的事情。
—
Miles Rout
这个问题似乎是假设，只要团队未公开安全问题，世界就不会知道。很显然这不是真的; 任何发现的安全问题都应假定是某人出于恶意在某处知道的。现在，如果您假设其他人已经知道此问题并且可能正在利用此问题，则无法再将修补程序的发布推迟到每月定期发布。您必须尽快释放。这意味着遵循常规的PR流程没有问题。只是针对最新的发行分支进行PR，合并，标记，发行。
—
Jory Geerts