23

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.

Improve this question
9
  • 1
    I'm not sure if there is a best practice set up. GitLab is essentially a private GitHub. Balancing the concerns of open source and security fixes is not easy. How many of your security fixes come from people not on your security team?
    – Berin Loritsch
    Commented Sep 18, 2017 at 16:38
  • Most issues are reported by others, but probably less than a fifth of fixes come from those not on the security team.
    – Joe Murray
    Commented Sep 18, 2017 at 16:58
  • 1
    In my opinion, if you need some part of your process to be private, then it should be done outside of GitHub (because GH is public); after this specific part is done and everyone reviewed its code; you can create a PR on GH that will be merged as quick as possible, just to 'return' to the official process. You could use another tool to manage those exceptions in the process.
    – Emerson Cardoso
    Commented Sep 18, 2017 at 18:58
  • 2
    Full immediate disclosure (i.e. public disclosure with no delay) is a perfectly legitimate thing to do.
    – mrr
    Commented Sep 19, 2017 at 22:41
  • 1
    This question seems to assume that, as long as the security issue is not disclosed by the team, it is unknown to the world. That is simply not true; any security issue that is discovered should be assumed to be known about by someone with bad intentions somewhere. Now, if you assume that somebody else already knows about the issue and might be exploiting it, you can no longer postpone the release of the fix until your regular monthly release. You must release ASAP. That means there is no problem with following the regular PR flow. Just PR against the latest release branch, merge, tag, release.
    – Jory Geerts
    Commented Sep 28, 2017 at 14:57

1 Answer 1

Reset to default
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.