Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How secure is open source collaboration software?

Open source collaboration can be rife with risk. Learn about the open source security requirements to consider and who should be responsible for security and support.

This article can also be found in the Premium Editorial Download: Network Evolution: Chit chat: The new team collaboration apps go mainstream

Open source collaboration software has similar security risks to any other open source software. The main question...

is who is responsible for maintaining, upgrading and deploying it?

Open source collaboration software has its own set of security risks, too. Some people might say security means getting several developers to scrutinize the code base -- but this hasn't always worked well.

In 2014, a serious vulnerability, known as Heartbleed, affected OpenSSL, one of the most popular open source projects that practically runs modern security over the Internet. Heartbleed was undetected in the code base for several years.

Many developers had access to the code, but none found it. Reliance on the masses doesn't always work for open source software security, which leads to the next issue when security threats are found: How do you plug these holes and maintain the code base?

If you install and operate open source collaboration software in your company, you need to keep it up to date, especially amid various security patches. The challenge is having an owner of the software -- someone who is held responsible and gives support when things go wrong.

Normally, you will use a collaboration software as a service (SaaS) vendor that develops its own open source collaboration software or maintains one. In this case, security will be the vendor's responsibility.

When you choose open source collaboration software for your organization, consider the following:

  • Make sure the software comes from a company you can trust;
  • Evaluate the size of the ecosystem around it;
  • Follow the open source software's security advisory notifications; and
  • If you opt for a SaaS vendor, see how the vendor views security and the privacy of its customers.

Do you have a question for Tsahi Levent-Levi or any of our experts? Ask your enterprise-specific questions today! (All questions are treated anonymously.)

Next Steps

New employee habits reshaping enterprise collaboration

Security is a top concern for collaboration in the enterprise

Getting your organization ready for open source software

This was last published in February 2016

Dig Deeper on Unified Communications Security

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What security requirements would you have for a SaaS vendor that uses open source software for collaboration?
The philosophy of "Open Source" is correct, but the problem is laziness and greed users (especially large software companies).
Heartbleed weakness appeared in more than 180 programs, including those from IBM, Oracle and others.
The explanation is simple and sad at the same time. Everyone wants free to use, but a few (very few) colleagues are willing to help.
Another aspect is a lack of professional testing of open-source products. While some users do provide a feedback it's still not a good substitute for systematic testing.
Napravnik - while true, there are some huge open source successes such as Linux. At the end it is all about demand. And yes - everyone is greedy.

Albert - in many cases, open source is used in professional products (or backed by a company selling support/services for it). This means it still goes through systematic and rigorous testing.

Heartbleed is a good example. It was found in OpenSSL, which is an open source tool used in commercial products. So it went through systematic testing of said products. And it still got through the cracks.
To me, proprietary enterprise software in many cases rely on security by obscurity and not by any means of systematic testing or professionalism.