People often have fears that since the source code of an open source project is open to inspection it is also open to abuse by those wishing to do harm. This document explores some of these concerns.
There are close to no viruses or malware on open source platforms (I've never heard of one). The reason for this is simply one of scale. If you want to cause havoc with a virus then attack the desktop which is prevailent and doesn't have the same level of security monitoring. If you want to use malware to grab passwords or something then target the desktop which is prevailent and doesn't have the same level of security monitoring.
If people are worried about malware or viruses being put into the code base that is distributed then they ought to spend some time understanding how open source is actually developed. It is not the case that just anyone can put code into a release. All contributions and contributors go through a quality assurance process. In a well managed project every contribution is reviewed by other members of the community, this removes the opportunity to insert bad code into the product.
To get bad code into a release one would need the whole project team on board or the project would need to adopt an inneffective QA process for contributions. In other words, the method of getting such code into an open source project is the same as it is for closed source. The difference between the two is that the customer can examine QA efforts since the whole process is visible. If they don't like what they see they can get involved and improve the process or they can walk away. In the closed source world examining the security processes is not possible, neither is contributing to those processes. As a result the customer must place their blind trust in these unseen processes.
The key with open source is that you have control over who you trust. If, for example, you are the National Security Agency in the US and security is the highest priority you will choose to use entirely open source because you have the budget to improve the processes and make the systems more secure. Similarly, if you are a one man band you probably purchase from a supplier and pay them to manage your security as a "low risk" customer, in this instance it is irrelevant if the product is open source or closed source, except for the fact that in the open source world there are people like the NSA helping to manage the security of the Linux Kernel as well as the supplier you choose to pay.
A University will probably rely largely on a supplier, but will want the ability to act quickly if an exploit emerges that affects them. In this situation open source is usually faster to patch, although it is impossible to prove this as closed source companies do not report exploits until after event, consequently we don't know the lead times (many reports say open source is faster, but without hard facts from the closed source world it is impossible to be certain).
Finally, in the case an exploit only affects 5% of customers using a particular configuration a closed source company is unlikely to patch that flaw in reasonable time. This is true of both closed and open source. However, in open source we can create the patch ourselves or we can pay any contractor willing to look at it. It is true we could pay the closed source company to give such levels of service, but since there is no competition for this kind of work it will invariably be more expensive.
The fact is that open source is just software, like any other software. It is not, in and of itself, more or less secure. It does provide more options for assessing and managing security, this means that if we want to take ownership of the security of our systems then open source has the potential to be more secure.
People therefore ask the wrong questions. People ask "is open source secure" yet nobody asks "is closed source secure", they instead ask "is (closed source) product X secure".
With open source we can ask is "is (open source) product X secure enough for our needs, or is there are supplier we can work with to ensure it is secure enough, or do we have the internal resources to ensure it is secure enough for our needs". With closed source we can only ask "is (closed source) product X secure enough".
Even if we do ask the right questions, in the case of closed source we can't actually evaluate the security of the software, we can only examine the past history of the software. With open source we can analyse current code and processes as well as looking at the past history. So again, open source wins out, if we trust the process or we have the resources to take ownership.
We have a briefing note on the topic of secutiry at http://www.oss-watch.ac.uk/resources/securityintro.xml
> IF you do, do you have database of this software, which is "clean" for down > loads, etc, or is this naive of me in that it's not possible to do; would > require significant storage space, etc.?I believe the majority of security breeches are actually caused by people (bad practices, social engineering, leaving on a bus, not setting a secure password etc). So while people in both types of projects may be targeted to introduce weaknesses we can only see the results in open source projects. Further being persuaded to reveal internal details for exploit is a non issue for open source projects as scrutiny by all is encouraged.
No, we do not maintain such a database. It is impossible for a team of our size to evaluate all products in the market. Furthermore, it makes not sense since most security exploits result from a bad configuration at the point of install. That is the exploits are not in the software themselves.
What I can say is that *all* open source software that is developed in a well managed way is at least as secure as closed source software that is developed in an equally well managed way. We therefore focus on helping people understand what a "well managed" open source project looks like. Our consultations are free (to UK HE and FE) and are targetted at the specific problem and product being proposed.
As the majority of security breeches are actually caused by people (bad practices, social engineering, leaving on a bus, not setting a secure password etc). So while people in both types of projects may be targeted to introduce weaknesses (or inadvertently do so) we can only see that by direct inspection in open source projects. Further being persuaded to reveal internal details for exploit is a non issue for open source projects as scrutiny by all is encouraged. SteveLee