There's a thing I don't understand. I found a project on Github. Looking at the list of commits, you can see stuff like "fixed XSS in file whatever, etc". But that commit is part of a long list of commits that were made after the latest public release. So that vulnerability is basically public (everyone can look it up in Github), and the patch has not been released (it will be included in the next public release). To me, that in practice sounds like a zero-day vulnerability is available, even though in theory I guess "day zero" has already passed.

So how should you manage code in Github without leaking info about vulnerabilities that way? Is there a best practice, or a common accepted way to mitigate this problem?

  • If you look at some issues with the Linux kernel, e.g. the Dirty COW vulnerability, IIRC the bug was patched publicly before it was announced. However, the commit nor any other surrounding info alluded to the fact that it was a serious vulnerability. – multithr3at3d Jun 16 '18 at 17:05
  • @multithr3at3d That's how the Linux Foundation thinks security is achieved. Of course, hiding vulnerabilities and downplaying them whenever possible only gives an advantage to the folk who actually pay attention to the commits. It makes it really easy to develop exploits for Linux. – forest Jun 17 '18 at 2:03
  • 1
    OP, you do not want to hide vulnerabilities. Patch them quickly and release an advisory telling people who use your software to update. Tell them as much as you know about the bug so those who cannot update it can mitigate it, and so others can determine the threat to their particular setup. – forest Jun 17 '18 at 2:05
  • @forest, ok, but what does "quickly" mean? The problem here is the time between the commit (which makes the vulnerability public) and the release of the patched version. Apparently you would have to release it soon after the commit (hours or days at most? How quickly?), or delay the security commit until you are ready to make a release. – reed Jun 17 '18 at 9:10
  • 1
    As quickly as you can. As soon as you make the commit, consider the bug public. By not releasing an advisory, you are making it public only to people who wish to exploit your software for themselves and not to the people who might build the software directly from your repo. – forest Jun 17 '18 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.