The downloadable version of this article can be found here:
http://techrepublic.com.com/5138-10877-6064730.html
The debate on which is more secure, open source or proprietary software, has been visited many times on TechRepublic. Has your attitude about the security of either or both methods changed in the last year? Is any nontrivial application, regardless of its development methodology, really completely secure?
For example:
http://techrepublic.com.com/5100-1009_11-6064402.html
Discussion on:
View:
Show:
and no nothing is completely secure.
One of your more useful articles that Mark.
One of your more useful articles that Mark.
The discussion about the two different approaches toward security is very healthy for both approaches. It's a given that there are going to be bugs and let's face it no single company can afford the number and quality of talent that work for free on Linux and other open source projects. It's the strength of open source. On the other hand it's pretty hard to make a living working on open source projects so the proprietary software is needed if for no other reason than to indirectly fund the open source development projects.
detailing of why open sourceis more secure.
You forgot one of the best known open source applications which is an excellent example, Apache itself. It is extremely rare for there to be a Vulnerability in Apache, most reported vulnerabilities come from end user mistakes in the configuration of it. as soon as the configuration is repaired the vulnerability goes away.
Note: Mozilla has released patches to exploits in hours also for Firefox, not even their normal days patch time.
You forgot one of the best known open source applications which is an excellent example, Apache itself. It is extremely rare for there to be a Vulnerability in Apache, most reported vulnerabilities come from end user mistakes in the configuration of it. as soon as the configuration is repaired the vulnerability goes away.
Note: Mozilla has released patches to exploits in hours also for Firefox, not even their normal days patch time.
CVE list has 184 vulnerabilities for Apache since '99 compared with 395 for IE. I would not call this rare. Obviously, this does not consider the "criticality" of the vulnerability, the actuality of actual explots, whether we should include vulnerabilities involving PHP plugins etc.
The greater security of Apache vs IE is not in question, but rather the use of the word "rare". Many of the vulnerabilities come from the same source (C programming) as those of IE - buffer overflows, parsing errors of mal-formed URLs etc.
The greater security of Apache vs IE is not in question, but rather the use of the word "rare". Many of the vulnerabilities come from the same source (C programming) as those of IE - buffer overflows, parsing errors of mal-formed URLs etc.
That's probably C++ more than C. C allows you to shoot yourself in the foot: C++ occasionally shoots you in the foot whether you did it yourself or not.
ie being 2.15 times as likely to have a bug than apache means that apache's bugs aren't rare?
395/184=2.1467391, rounded to 2.15
lets also look at the patch times for those bugs shall we?
hmm, doesn't really require much effort.. with one CRITICAL security risk bug taking 18 months before microsoft released the patch, it doesn't look good for proprietary code on the patch times. Oops, the shortest IE patch is 60 days.. still doesn't look good.
shall we really dig into it and see that the open source software bugs are known about by all that want to within minutes of them being found, while proprietary software companies keep them hidden for months until they have a chance to write the patch?
so yup, open source bugs are rare compared to proprietary software. when proprietary software companies have instant disclosure and patch times under a week, then I'll start to change my opinion of how lousy proprietary software is.
395/184=2.1467391, rounded to 2.15
lets also look at the patch times for those bugs shall we?
hmm, doesn't really require much effort.. with one CRITICAL security risk bug taking 18 months before microsoft released the patch, it doesn't look good for proprietary code on the patch times. Oops, the shortest IE patch is 60 days.. still doesn't look good.
shall we really dig into it and see that the open source software bugs are known about by all that want to within minutes of them being found, while proprietary software companies keep them hidden for months until they have a chance to write the patch?
so yup, open source bugs are rare compared to proprietary software. when proprietary software companies have instant disclosure and patch times under a week, then I'll start to change my opinion of how lousy proprietary software is.
A good introductory article to the subject. Glad that someone thought to address this debate from a more original/pro-active perspective & point of view.
Firstly, as others have said about the popularity factor, there are many niches where Unix-like FLOSS is the most popular, or significantly popular. Server operating systems are the classic example. The fact that most of the Internet infrastructure uses FLOSS should be a prime candidate for this point, being that a ?closed? corporate network has a smaller attack surface than the public Internetwork. Not just Apache, but sendmail, BIND, et al. are the standard server software for their respective roles.
A significant point missed about the introduction of malicious functions/?features? is that with FLOSS, they are easily removed by users themselves or their agents (such as a friend/neighbour, or an employed programmer), yet with proprietary users are left to plead the vendor, begging to have the changes made on their behalf. The motives of resolving bugs and gaining profit are usually at odds with one another.
To this end, I would argue that by proprietary vendors making their source viewable (eg MS ?Shared Source?) ? but still without the freedom of users being able to apply modifications themselves ? proprietary software is actually falling into the very trap it accuses FLOSS of being (in). That is; potential vulnerabilities being made more public; the key difference is that with proprietary the users of software are still powerless to improve the matter themselves, yet with FLOSS (as subtly implied in the article) anyone is free to submit a patch, based on their own findings. A critical point missed, though, is that users can apply said patch immediately *to their own systems* themselves, rather than having to wait for it to be incorporated in the ?official/approved? source, and distributed to everyone (although doing both would be best, of course). This allows more effective testing schemes/mechanisms, to best ensure that the patch does as intended (and nothing more), upon being submitted to the maintainer(s). For comparison, consider how cryptography (particularly hash functions) are developed; mass public testing, before they have a chance of becoming publicly standardised.
I think it would be good to explicitally state the point that proprietary will never be able to make use of the same style of socially-driven development as FLOSS, lest it become FLOSS itself, and no longer proprietary. Proprietary wanting (to be) the best of both worlds; wanting to benefit from the advantages of peer-review and open scrutiny/development, without passing along the ability to exercise those same benefits to their ?customers? (by releasing the source code as FLOSS).
Further to these points, is the idea of what constitutes ?exposure? in the sense of vulnerability probing.
I agrue that, as probing a working implementation produces more useful data than attempting to determine bugs from design plans (source code), and distribution of compiled binary versions is far more wide-spread than source-code (which is only really of interest to programmers), that proprietary is just as exposed as FLOSS (if not more-so), yet (and this being the key point, as any competent PR professional will tell you) the significance is in the way that each philosophy handles discovered vulnerabilities. FLOSS openly (and promptly) publishes patches without encumberance as mere ?matter of fact?, however proprietary takes its time even when it *does* release patches, if it does at all. The ?bug vs feature? concept illustrates that the notion of certain behaviour being labelled as security vulnerabilities/bugs is a matter of perspective; the question is ?security for whom??. Take note of contentious (mis)features like Digital Restritions Management and Treturous Computing as being ?features? that the user would otherwise consider vulnerabilities/bugs, but that proprietary vendors/developers may not wish to remove (the user/?customer? being considered the ?attacker? in these warped security models).
Firstly, as others have said about the popularity factor, there are many niches where Unix-like FLOSS is the most popular, or significantly popular. Server operating systems are the classic example. The fact that most of the Internet infrastructure uses FLOSS should be a prime candidate for this point, being that a ?closed? corporate network has a smaller attack surface than the public Internetwork. Not just Apache, but sendmail, BIND, et al. are the standard server software for their respective roles.
A significant point missed about the introduction of malicious functions/?features? is that with FLOSS, they are easily removed by users themselves or their agents (such as a friend/neighbour, or an employed programmer), yet with proprietary users are left to plead the vendor, begging to have the changes made on their behalf. The motives of resolving bugs and gaining profit are usually at odds with one another.
To this end, I would argue that by proprietary vendors making their source viewable (eg MS ?Shared Source?) ? but still without the freedom of users being able to apply modifications themselves ? proprietary software is actually falling into the very trap it accuses FLOSS of being (in). That is; potential vulnerabilities being made more public; the key difference is that with proprietary the users of software are still powerless to improve the matter themselves, yet with FLOSS (as subtly implied in the article) anyone is free to submit a patch, based on their own findings. A critical point missed, though, is that users can apply said patch immediately *to their own systems* themselves, rather than having to wait for it to be incorporated in the ?official/approved? source, and distributed to everyone (although doing both would be best, of course). This allows more effective testing schemes/mechanisms, to best ensure that the patch does as intended (and nothing more), upon being submitted to the maintainer(s). For comparison, consider how cryptography (particularly hash functions) are developed; mass public testing, before they have a chance of becoming publicly standardised.
I think it would be good to explicitally state the point that proprietary will never be able to make use of the same style of socially-driven development as FLOSS, lest it become FLOSS itself, and no longer proprietary. Proprietary wanting (to be) the best of both worlds; wanting to benefit from the advantages of peer-review and open scrutiny/development, without passing along the ability to exercise those same benefits to their ?customers? (by releasing the source code as FLOSS).
Further to these points, is the idea of what constitutes ?exposure? in the sense of vulnerability probing.
I agrue that, as probing a working implementation produces more useful data than attempting to determine bugs from design plans (source code), and distribution of compiled binary versions is far more wide-spread than source-code (which is only really of interest to programmers), that proprietary is just as exposed as FLOSS (if not more-so), yet (and this being the key point, as any competent PR professional will tell you) the significance is in the way that each philosophy handles discovered vulnerabilities. FLOSS openly (and promptly) publishes patches without encumberance as mere ?matter of fact?, however proprietary takes its time even when it *does* release patches, if it does at all. The ?bug vs feature? concept illustrates that the notion of certain behaviour being labelled as security vulnerabilities/bugs is a matter of perspective; the question is ?security for whom??. Take note of contentious (mis)features like Digital Restritions Management and Treturous Computing as being ?features? that the user would otherwise consider vulnerabilities/bugs, but that proprietary vendors/developers may not wish to remove (the user/?customer? being considered the ?attacker? in these warped security models).
You've made some good points. It's true that the article did not quite cover all possible points of interest in the case for the greater security benefits of an open source development model; hopefully it is obvious that doing so would make the article untenably long, however.
In addition to this article, I have written a number of others here at TechRepublic over the years that also discuss the matter of licensing and security. If you're interested, they can be found buried amongst the other security articles cataloged on my articles list. It is not comprehensive, but it does cover quite a lot of what I have written during the time covered by that list, and is mostly kept up-to-date.
I'd be interested in seeing your comments on some of those other articles.
In addition to this article, I have written a number of others here at TechRepublic over the years that also discuss the matter of licensing and security. If you're interested, they can be found buried amongst the other security articles cataloged on my articles list. It is not comprehensive, but it does cover quite a lot of what I have written during the time covered by that list, and is mostly kept up-to-date.
I'd be interested in seeing your comments on some of those other articles.
Recent changes in the backend code for TR's discussion forum have eaten the link to my articles list. While this is probably not the same list I linked before, it is certainly longer, considering I spent several more years writing gobs of security articles for TR:
http://apotheon.com/pub
http://apotheon.com/pub
Hello just wanted to let you know that the web page has a typo at the beginning it should say Debates rage but it says Debatesrage instead. Also "Partof". Congrats for this article btw.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle









































