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.

Joe Murray
  • 341
  • 1
  • 6
  • 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 Sep 18 '17 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 Sep 18 '17 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 Sep 18 '17 at 18:58
  • Github does provide private repos that can be selectively opened to secteam invitees. Not sure if that exists for forks...I suspect not. – Joe Murray Sep 18 '17 at 23:21
  • 2
    *Full immediate disclosure* (i.e. public disclosure with no delay) is a perfectly legitimate thing to do. – Miles Rout Sep 19 '17 at 22:41
  • Open Source is the new attack vector, I guess. If you can't beat em, join em and then beat em. Can you create secure systems in an open environment? Can you do it in a closed environment? –  Sep 27 '17 at 16:08
  • 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 Sep 28 '17 at 14:57
  • We follow the fairly common practice of a regularly scheduled release window for security matters so that user orgs can be ready. I think there may have been one or two exceptions, but it seems to work better for us. – Joe Murray Sep 28 '17 at 19:02
  • IMHO there is more to be gained by making all bugs shallow, than the risk of reverse engineering an exploit from a pull request for a security patch. – Martin Spamer Oct 17 '17 at 14:18

1 Answers1

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.

Lloyd Moore
  • 164
  • 4