What are the security implications of 'open-source' vs. 'source-available'?

Question

In light of the current fiasco surrounding TrueCrypt, I have received considerable criticism from current clients and peers in the IT industry for my continued support of the open-source model. Such criticism is usually lumped in with ongoing dialogue on the virtues and failures of the open-source model following episodes such as heartbleed. I have attempted to point out that in spite of many news articles labeling TrueCrypt as open-source, the source-available label found on Wikipedia is more correct.

It conjunction with that distinction, I have argued that having the source code available for review is inherently more secure than not, but that it should not suggest the same level of trust as a project that follows an open-source development model including allowing redistribution of modified work. While my gut tells me this is a reasonable position to take, the difference is subtle and my ability to communicate it convincingly is limited.

Are there more concrete evaluations to go on than just my gut here? Is there a measurable difference in the relative security of source-available applications vs true open-source counterparts? If so, is it well established what factors exactly contribute to this? What about the OS development model specifically results in more secure code than just releasing code for review? Or does this boil down to opinion in the end?

Edit: does it make any difference whether the specific software in question is cryptography related?

Answer 1

Source-available (SA) differs from true open-source (OS) that there is no right to fork. That means when a security flaw in a SA software gets known and the developers refuse to fix it (which doesn't have to be out of bad intentions - it could just be lack of resources), users do not have the option to fork the project and continue the project under a new name with a new team.

However, should a flaw in a SA project be discovered and made public, continuous refusal to fix would hurt the reputation of a SA project badly and drive users away from it.

Some OS proponents claim that the ability of everyone to offer a patch for a OS project results in faster bugfixes. However, this only applies to a part of OS projects: Those which follow the Bazaar development model and not the Cathedral model. There are many OS projects which do not accept unsolicited contributions from 3rd parties. A bugfix could still be offered independently so users can apply it manually, but that's a maintenance overhead many administrators and users shy away from.

And forking a project because of a single issue is usually more trouble than its worth. I witnessed several forks of open source projects as part of either side of the fork. The result was always that it hurt the overall progress of both forks because development resources got diluted, infrastructure and management structures had to be duplicated and users got confused. Trying to hold a project together despite any conflicts usually pays off.

Answer 2

Open source and source available, as general categories, are identical in their security implications. The key benefit is faster discovery of bugs/inefficiencies/vulnerabilities; many hands make light work. In practice, the value of this benefit will vary based on the size of the community interested in the project and thus the number of people looking over the source code.

Regarding the example given: the message from TrueCrypt merely indicates that support has been discontinued. Giving advanced notice would have been nice, to say the least, but such an action is not restricted to open source (or source available) entities; private corporations discontinue products all the time. If they do it less often, e.g. because people are paying them to provide continued support, one should recognize that hiring or otherwise paying open source committers for continued support of a product slated to be discontinued is always an available alternative.

Availability of continued support has always been, and should remain, a key consideration regarding the suitability of a given product for a particular task, open source or otherwise.

Answer 3

In my experience the question is so broad and the prejudices so deeply ingrained that you may be wasting your time trying to argue the case on either side.

Closed source projects/organizations do not readily give up their code for analysis by an independent party - and even though will only usually do so uner an NDA, therefore any such analysis is likely to have very high sample bias. However here's a couple:

http://osswatch.jiscinvolve.org/wp/2012/02/28/open-source-matches-proprietary-code-quality/ http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/ICSOC2013_50_Open_Source_Versus_Proprietary_BPEL_Engines.pdf

For further discussion see also:

http://courses.cs.washington.edu/courses/csep590/05au/whitepaper_turnin/oss%2810%29.pdf http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/open-source-security.html http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html

Given that the facts about Truecrypt are yet to emerge, it's hardly a poster-child for either side of the argument (open-source software was not the reason RSA, Lockheed-Mrtin, Washinton Post and others got hacked).