Open-source in the world of data breaches

Open-source in the world of data breaches

Charlie Wardell, Decooda CTO

 

There are a few things that you may want to take into consideration before implementing open-source software, as opposed to proprietary software, in your overall solution/strategy.

Let’s explore the strengths and weaknesses of utilizing open-source projects.

  • Rapid implementation

Open-source software allows you to implement key components of your architecture rapidly.  The larger open-source projects often have a thriving community, documentation and published books to support the movement.

  • Minimal upfront cost

Proof of Concepts that would traditionally require the purchase of 3rd party components or libraries can now be implemented with minimal upfront cost.

  • Freedom of choice

Open-source software provides a freedom from vendor lock-in. Having the ability to choose and deploy a widely adopted open-source initiative assures long-term viability.

 

However, with the benefit of speed and reduced upfront cost come certain risks.

  • Security Concerns

One of the major risks open-source software has is the potential of installing a solution that is not up to the security rigor that your organization requires. Backdoors and malware may be easily overlooked in complex open source systems and rumors of backdoors in some of the major open-source initiatives go back to the 90’s. A quick search on the internet for “NSA and BACKDOOR” will show the concerns over key technologies like Linux and OpenSSL being compromised by the NSA.

It should be noted that a few months ago, it was discovered that the Equifax Data Breach which affected 143 million customers was directly related to an exploited flaw in a larger open-source project called Apache Struts.

Open-source systems are typically developed by a community of people with like-minded interests.  Some open-source projects enlist hundreds or even thousands of contributors. As an example, a significant project hosted by the Apache Foundation call for contributors by very specific needs. Developers that contribute to these needs usually have their code peer-reviewed and integrated by one of the project managers.

Unfortunately, not all open source projects are created equal and not all contributors have the same benevolent end-game in mind. Rigor is often times neglected on some of the smaller open source projects and the pressure to provide patch releases on the larger initiatives sometimes circumvent protocol for trusted contributors.

  • Smaller open-source initiatives

There are literally thousands of libraries available on Github for example that is no longer active or have rogue contributors moving the projects forward sporadically. The contributions to these projects are often times void of the oversight that some of the larger projects have but designed by one or two authors trying to provide for the greater good. In some of these cases, the code is manageable and able to be “forked” into your own well-maintained project.

  • Larger open-source initiatives

With the Apache Struts exception above, open-source systems managed by commercial organizations like Red-Hat (CentOs or JBoss), Oracle (MySql), Ubuntu, and WordPress to name a few typically do not suffer from these concerns. It is presumed that the larger open-source projects are closely managed by the organization that monetizes on the open-source initiative through support contracts, upgrades, implementation, and training. These organizations have a vested interest to ensure a certain quality that one would expect from commercial off-the-shelf distributions. In these cases, open-source software is a basis for revenue for these organizations.

  • Is open-source really free?

Well yes and no. The project you adopt may not have license fees attributed to its use, but as you become more dependent on some of the larger open-source projects, there will most likely become a time where you will have to budget for maintenance and support contracts.

 

In conclusion

The decision to use open-source, or a competing commercial off the shelf project, does not need to become a holy war within your organization. Going open-source on some of your key components may have major undeniable benefits. However, in today’s world of frequent security breaches, (more notably the Equifax Data Breach) one needs to be very prudent based on the domain they are deploying in.

If I were deploying a corporate website, I would have no problem deploying a community-driven open-source content management system. Keeping in mind that a secure system is only as strong as its weakest link. If I were deploying a system that housed personally identifiable information, financials, or HIPPA related data I would err on the side of caution.

 

 

Comments are closed.

Enjoy this blog? Please spread the word :)