The safety of open source software is a question that comes up periodically from time to time. Let’s talk about why the question keeps coming up, and what’s different about open source software versus closed source software.
The main thing that can get you when it comes to the safety of open source software is anything but obvious. Hint: it isn’t the development model.
Why people ask if open source software is safe to use
People have a natural tendency to fear things they don’t understand. And open source software can be hard to understand.
Open source proponents like it for several reasons, some of them idealistic. Richard Stallman believes that software should be free to copy, study, and modify. He is more concerned about the rights of the person using the software then he is about the author of the software. If you ever want to stir the pot, start a discussion about whether he is a liberal or a libertarian.
Where the idea that open source is safer comes from
The argument over whether it is safe to use comes largely from the writings of Eric Raymond, who is very much a self-avowed libertarian. Raymond argues that when software is free to study and modify, it is going to be less buggy and more secure, because more people are looking at it.
If people are looking at it, there is something to that argument. The problem is when a piece of software is important, but not super interesting. In the case of two of the most notorious security vulnerabilities in open source software, Log4J and Heartbleed, serious vulnerabilities turned up in widely used pieces of software that were being maintained by criminally small teams of volunteers after hours. Problems with this software cost large mega corporations billions of dollars, and yet they were relying on a couple of unpaid volunteers coding critical infrastructure as a hobby.
It sounds bad because it is bad.
The solution is for somebody to step up and sponsor these types of projects so that people are maintaining them during regular business hours and making enough money doing it for it to not be a low priority for them. Sometimes it takes a crisis for the problem to become apparent.
Free as in freedom, beer, or puppy?
Richard Stallman makes the distinction of free software being free as in freedom, not free as in beer. That means you are free to do things with it, not that you can get it for free with strings attached. Microsoft Outlook 98 was a good example of free as in beer software. Microsoft made it free to copy for a time, so they could gain market share. Once it was clear that the Outlook and Exchange combination would unseat Lotus Notes, something magical happened. Microsoft stopped giving Outlook away.
But there is a third model, that I argue is probably more appropriate. It’s not free isn’t freedom, because you aren’t going to study it. Let’s be honest. I know you aren’t studying it because aren’t even scanning it for vulnerabilities. It’s free is in puppy. You get the puppy for free, but there’s a lot of care and responsibility attached. Take care of the puppy, and it’s the best thing ever. If you don’t take good care of the puppy, lots of unpredictable things happen.
With great freedom comes great responsibility.
What if the bad guys study open source software?
The key argument that says open source software is not safe to use is the theory that bad guys are studying the software and finding vulnerabilities in it to exploit. The bad guys have to do black box tests against closed source software, but it’s a white box test against open source software. So open source software can in theory have an infinite number of zero day vulnerabilities.
It’s an interesting theory. It’s a very old interesting theory. I’ve been hearing this argument since the 1990s. I’m still waiting for an example.
I study vulnerabilities for a living and my specialty is working with companies who have large backlogs of vulnerabilities and helping them to bring that situation under control by setting priorities and goals.
A big crisis comes along about every 18 months. I’m not just talking a high publicity vulnerability with a brand name, a logo, and a marketing campaign, but something that does real damage. That crisis may or may not have all of those things attached.
The first vulnerability with a marketing campaign was Heartbleed, which was a vulnerability in open source software. The vulnerability in 2021 that will go into the Hall of Fame was also in open source software. That was Log4J. But 18 months before Log4J, the big deal was a vulnerability called Zero Logon. That was a problem in Microsoft software. The open source software Samba also had the problem, but the problem was a design flaw that Microsoft made, and the open source team had the same problem for compatibility reasons.
The theory that you are safer if you buy closed source software is just that. An unproven theory. The real world evidence doesn’t significantly favor one model over the other.
You can find studies saying that more vulnerabilities were found in a given year in open source products than in closed source, but the pattern doesn’t really hold over time.
And if there were a huge difference, you wouldn’t see widespread adoption of the hybrid model. Did you know that there are really only two web browsers in existence today? Mozilla Firefox uses its own browser engine. Every other major competitor, including Apple, Microsoft, and Google, use a descendants of a browser engine called WebKit that is open source. Apple uses a different fork than everyone else does, but they are all relying on closely related open source engines and putting their own user interface on top.
You are using open source software to view this website. The web server is open source, running on an open source operating system. But the software running on your computer is open source too. Unless you are reading this with Internet Explorer, which is absolutely not safe to do. And most of the network equipment in between your computer and mine is running open source software too. Possibly a mix of open- and closed-source software, but plenty of open source is in the mix.
The main gotcha with open source software
As I stated before, I analyze vulnerabilities for a living. I study the backlogs of large companies for a living. There is one difference between open source software and closed source software that does affect its safety. And it does get a lot of companies.
Closed source software generally has regular maintenance cycles. Microsoft and Adobe release updates every second Tuesday. Oracle releases theirs quarterly.
Open source software as a whole does not have the predictable release cycle. If it is sponsored by a company, they may have a release cycle. The open source software that Oracle owns also gets updates quarterly. Mozilla has a monthly release cycle, it’s just not the same day as Microsoft.
But thousands of other open source projects have no scheduled cycle. The bug fixes come out when they come out.
I have seen anarchy. This is it. And it’s a mess.
It makes governance difficult, because you probably don’t know what’s on all of your systems running open source software. Large companies struggle to produce lists of all the computers they own, let alone all of the software installed on them. So that makes tracking changes so you can roll them back more difficult.
And when I studied a large company’s backlog a couple of years ago because they wanted to know why their Linux systems always had vulnerabilities, when they had Windows systems that were completely clean, it took me less than an hour to figure it out. Their Linux systems were clean as of the maintenance window, but by the time they scanned the systems a week or two later, they were slightly out of date.
But the MTTR on their Linux systems was generally keeping pace, and the average severity of the vulnerabilities they found, if anything, was better than on their Windows counterparts. It’s just that the Linux environment was a moving target. Or should I say, lots of moving targets.
But when you run open source software on Windows, you can run into a similar situation. That’s probably one reason Microsoft released the tool winget to help keep that software up to date. The software falls out of date quickly, but at least it’s a single command to catch back up.
That’s why I care a lot more about trends and MTTR than I do point in time vulnerability counts when I’m helping customers bring their updates under control in my day job. The vulnerability counts can be affected by a factors beyond your control. But the trends will tell me if you’re doing the right thing or not doing the right thing. If you’re doing the wrong thing, the trends will go in the wrong direction. If you’re doing the right thing, the trends will go in the positive direction, even if you have a bad month here and there. Which you will.
Is open source software safe to use: in conclusion
All software has bugs. All of it. Managing it is not just a matter of choosing one model or the other. The governance model between maintaining the two is a little bit different, and if you’re not familiar with it, it will get you.
I can point you to people with theories as to why one model is more secure than the other, but no one has ever been able to give any concrete proof that one model is always better than the other. That’s why you see so many companies using a hybrid model.
The theories are nice, but it’s been more than 25 years, and no one has been able to prove open source software is unsafe to use. But you do need to know how to manage it. And what you know about managing proprietary Unix or Windows doesn’t necessarily apply to open source software. But that doesn’t mean the problem is open source.