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 travels.

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.

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.

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 travels.

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.

(Reposted here on advice of commenter on https://stackoverflow.com/questions/46282866/what-is-best-practice-for-handling-prs-addressing-security-vulnerabilities-in-pu)

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 travels.

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.