by Mitchell Kavalsky
Patching has never been more important. The WannaCry ransomware attack that infected more than 300,000 systems, the NotPetya attack that hobbled approximately 16,500 more, and of course the Equifax breach that compromised the information of 145.5 million Americans all happened because patches weren’t added quickly enough.
But what if patches weren’t available at all? That’s the potential dilemma for users of open source software, especially if the open source product is old or never gained popularity, or the community lacks enthusiasm or focus.
There is no guaranteed support cycle for vulnerability remediation in open source, and while those vulnerabilities go uncorrected, the critical nature of the risk increases.
So the question is, can your organization stomach the potential risk of open source? Here are some factors to consider.
3 reasons organizations choose open source software
Open source has a lot to offer, and there’s definitely a place for it. Especially in terms of budget, functionality, and culture, it’s easy to see why so many organizations choose open source.
It’s often free or sold at a much cheaper licensing fee than proprietary software but works just as well, if not better.
The functionality can be closer to what you actually need and want since the software was developed by your peers. If you need to customize software to your business’s specific needs, open source is often the way to go.
In some cases, you might just prefer the open source culture.
But no matter why you choose open source, you should always keep the potential risks in mind.
Can you afford the risk of open source software?
Whether you’re using open source or considering it, there are a few questions to ask yourself about open source security:
- What is the software’s track record? Linux has a 26-year history, a strong community backing, and a long list of major organizations that use it, including Google, NASA, and the U.S. Department of Defense. With a resume like that, it poses a much lower risk to your organization.
But if you’re considering an open source application that’s newer, isn’t yet (or never was) widely used, or has a history of bugs or failures, understand that you’re taking on a greater risk for the functionality you need.
- If your open source software needs patching, how long will you have to wait?
Users of open source rely on that community to resolve any vulnerabilities, but if the community isn’t attentive, or has lost interest, you may be stuck waiting. At minimum, this will inconvenience your company, but at worst, it could leave your systems open to attack.
A review of more than 200 open source applications between October 2015 and March 2016 found that on average, the vulnerabilities discovered in these programs had been identified more than five years before. That’s a lot of lead time for a hacker.
- How will you manage without support? Using open source can sometimes be like using proprietary software that has reached its end of life and is no longer supported. You can still use it, but need to be prepared to handle any issues without a trusty 1-800 number to call for support.
How long can you go without the functions the open source software supports? If mission-critical functions are run on open source software, how much revenue could downtime cost you if a problem arises?
- What rights do you have? From a contractual standpoint, how are you allowed to use the software and who is liable if something goes wrong?
Open source software does involve licensing, which ensures usage and collaboration continue in a way that supports the open source community and guards against misuse. A lot of licenses for open source products indemnify the developer or the developer tree should any vulnerability arise.
As a result, a lot of companies that use open source are buying cyber insurance. You might save money on open source software, but to reduce risk, you’ll unfortunately have to spend in other places to cover any potential negative impacts to your customers.
Where do you stand?
One of the biggest risks with open source has always been accountability. Who is responsible for fixing vulnerabilities when they’re found? With established software with active communities, patching might be no problem. With software that’s older or less popular, you may be on your own, since there’s no guaranteed support cycle.
Take into account your company’s needs and risk tolerance. Understand the role open source plays in your critical activities and determine the risk tolerance you can afford if a vulnerability -- or even a code failure -- emerges.
Is that flexible code base, functionality, and affordability enough to offset an unreliable support model? Only your organization can answer that question and determine if open source is right for you.