What is best practice for handling PRs addressing security vulnerabilities in public repo?

Question

How should an open source project with a public repository best handle pull requests (PRs) that address securely reported but not yet publicly disclosed security vulnerabilities?

I'm involved in an open source project with several hundred contributors. We publish security notices and vulnerabilities several times a year as part of a regularly scheduled monthly release. We don't publish information about the vulnerabilities until we make the patched version available. We are able to securely manage security issues in our project management system (JIRA). But we haven't got a good process for obscuring the PRs that fix security vulnerabilities as they are submitted to GitHub. We're concerned that people can find these fixes before they are released and create zero day exploits.

We've considered using private repos that fork the main repo, but much of our currently review and QA workflow occurs on the PRs. If we moved the workflow to a security team only private repo, that would reduce the window when the fix is public down to the hours it takes to generate the tarballs and publish them on sourceforge, which would be a big improvement. We'd also likely need to avoid merging the PRs into our public beta.

Before going in that direction, I'd like to know what is the best practice for handling pre-release security bug fix patches in open source projects with open repos? If the problem can be better addressed by using a different platform than GitHub, I should mention we are evaluating migrating to GitLab.

Answer 1

The protocol for this is to decide the risk factors in publicly showing vulnerabilities. For anything security related, those PRs need to be in a private repo that only your security team can see. This stands regardless of the platform you use for producting and actioning Pull Requests.