Handling security bugs in your Free Software project

If you are managing a Free Software project, you may eventually be confronted with a security vulnerability. Normally bugs in the Open Source world are discussed in a transparent way on public forums. In the case of security bugs however, there are benefits to temporarily withholding these details from the public.

Some people describe this approach as responsible disclosure. It boils down to this:

if the vulnerability is not publicly known, warn the vendors first and give them some time to fix it before making the details public.

If the vulnerability is already public knowledge, then you can focus on fixing it as soon as possible and maybe let reporters know about a better way to report their findings.

Sample Security Policy

Here's the procedure we now follow in the Mahara project for security bugs we found ourselves or which have been privately disclosed to us through [email protected]:

  1. Figure out the extent of the problem: which versions of Mahara are affected by this problem?
  2. Fix the problem on all supported branches of the project in a private source control repository.
  3. Share the vulnerability information with vendor-sec and request a CVE identifier.
  4. Prepare release tarballs and packages.
  5. Draft a security advisory for the Security forum.
  6. Wait until the embargo date to push the release out.

Emails to vendor-sec should include:

  • a description of the problem
  • any proof of concept code demonstrating the vulnerability
  • the list of affected versions
  • any patches you have prepared
  • a proposed embargo date

Benefits of properly handling security bugs

First and foremost, it protects end-users by giving them a chance to download and install fixed versions of your software before widespread exploitation of the security flaws.

Secondly, it may increase your project credibility. While you are admitting that your software has flaws, you are also demonstrating that your project is committed to dealing with the most serious ones promptly and in a responsible manner.

Finally, sharing security flaws and having your fixes reviewed by a select group of experts may reveal extra vulnerabilities you missed while preparing your patches. This gives you an opportunity to improve your fixes before they are released and to avoid having to issue yet another security advisory a few days later.

Big thanks to Steffen Joeris for his help in shaping the Mahara policy!