Security Software: Open Source vs Closed Source
I recently had a discussion on Google Plus about the relative merits of open source vs closed source security software. The discussion started as a question about which password management and synchronisation service was best, but quickly devolved into a discussion of the relative merits of open source vs closed source software when it came to security.
The first comment that brought up this dichotomy went something along these lines “I trust a company that is paid to develop software more than I would trust one person developing software in his spare time. The former can dedicate more time and resources to fixing bugs and ensuring better security”.
While there is some truth in that statement, a company can dedicate more time and resources to development than a single person, or a group of people, writing software in their spare time, there also seems to be a number of fallacies in the statement.
The first problem with this statement is that it assumes that open source software is usually developed by one person. On the contrary, open source software is usually developed in a distributed manner with thousands of users from all over the world contributing to the code. As a matter of fact, this is the main point in favour of the use of open source security software.
The source code is being scrutinised by thousands of dedicated programmers. These programmers are not working on the project because they have to, but rather because they enjoy doing so. With so many eyes observing the source code, it would be very difficult for a malicious programmer to insert backdoors or other security compromising features into the code. Also, if you are completely paranoid, you can do a source code audit using your own staff to ensure that there are no security holes in the software.
In addition, if you discover a new vulnerability in the product, there are many thousands of programmers who will produce patches to plug the hole. If you are so inclined, you can have your staff work on a security patch to plug the hole instead of waiting for someone else to do it. That is the beauty of open source, you have complete control over the source code. You do not need to wait for a corporate entity to fix something, you can roll up your sleeves and come up with a fix yourself — you are no longer at the mercy of a corporation producing software to maximise its profits.
Another fallacy in that statement is that it assumes that open source software is only developed by people in their spare time. That is completely untrue. Many of the contributors to open source projects do so as a part of their job in some company. For example, many Red Hat employees contribute to the Linux kernel and other open source projects. Also, the Mozilla browser is an open source project that is supported by the Mozilla Corporation, a for-profit entity.
Apart from these two fallacies, there is another aspect of the equation that was not considered by the poster of that statement. Namely, there is nothing to stop a company that develops proprietary closed source software from inserting backdoors or other security compromising code into the product either from a malevolent intent or to comply with legal obligations to law enforcement organisations in its country of origin. And, this is the clincher as far as I am concerned, you have absolutely no way of knowing that this backdoor exists.
By definition of closed source, you cannot see the source code of the product you buy. Therefore, you do not know what additional functionality it has. A company may insert a backdoor into your product and you would be completely oblivious to this fact. You can only infer the presence of backdoors from unusual behaviour, e.g., unexpected network traffic from your application when it “calls home”. However, the backdoor can be designed in a way that minimises the chances for detection. Again, these backdoors can be inserted into a product either from malevolent intent or to comply with legal obligations to local law enforcement, or even intelligence, agencies.
One last point. All it takes for a company to compromise software is a managerial decision to do so. Once this decision is reached, all employees would have to comply with corporate policy. On the other hand, it would take consensus among the thousand of programmers working on an open source project for something similar to occur. Surely, the former is easier than the latter.
To conclude, whom would you rather trust? A company developing software in secret and giving you no way of examining the source code of your product or a group of distributed developers examining each others’ code and producing an open source product that you can examine yourself for security vulnerabilities or deliberate security compromises? I don’t know about you, but I would go with the open source alternative.
I recently had a discussion on Google Plus about the relative merits of open source vs closed source security software. The discussion started as a question about which password management and synchronisation service was best, but quickly devolved into a discussion of the relative merits of open source vs closed source software when it came…