Back
Open Source Software – Is It the Death of Your Company?
Open source software (OSS) is software whose source code is available for modification or enhancement by anyone.
Many companies use OSS to develop their applications, but yet do not know what dangers exist in it. There may be legal ramifications stemming from the licenses that are being used by the OSS or security vulnerabilities that can exist in the software itself. Do you even know what OSS you are using in your application? Have your developers pulled the source into your application instead of using the binaries? If not, the first step is to find out what OSS you are using and what versions. The next step is to find out what license this software is using.
Licenses
There are many different open source licenses, some of them good (permissive) and some not so good. A “permissive” license is simply a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works. As of last count, the Open Source Initiative (OSI) has 76 different licenses, some permissive and some not so permissive. There are also some that OSI does not recognize, such as the Beerware license. It says “As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp”. This is considered a permissive license. Copyleft is a copyright licensing scheme where an author surrenders some, but not all rights under copyright law. Copyleft allows an author to impose some restrictions on those who want to engage in activities that would more usually be reserved by the copyright holder.
“Weak copyleft” licenses are generally used for the creation of software libraries, to allow other software to link to the library and then be redistributed without the legal requirement for the work to be distributed under the library’s copyleft license. Only changes to the weak-copylefted software itself become subject to the copyleft provisions of such a license, not changes to the software that links to it. This allows programs of any license to be compiled and linked against copylefted libraries such as glibc (the GNU project’s implementation of the C standard library) and then redistributed without any re-licensing required.
Copyleft licenses (GPL, etc.) become an issue if the OSS source is actually pulled into your application. The developers can do this without anyone’s knowledge, but would require you to release your source code. All of your intellectual property then becomes open source under that license.
The licenses on the OSS you are using can have many or few restrictions on your software. Make sure you are aware of the license(s) that is applied to each OSS you are using and have a lawyer review all of them.
What if you do not comply with the license? I am not a lawyer, but I believe if a company finds out you are using their software out of compliance with the license, you may end up with a lawsuit. In fact, the lawyer I was working with at a previous job was adamant that the company not use any copyleft software. He would not sign off on the software release unless it was free of copyleft software.
Security Vulnerabilities
As you are aware, all software has bugs and from a security perspective, the OSS you are using contains them as well. Over the last couple of weeks I was doing a web application penetration test and discovered that the software was using about 80 different open source libraries (JAR files). Among them were the Apache Commons Collections (ACC) and Apache Standard Taglibs (AST). Each of these have security vulnerabilities that are considered high risk (CVSS score of 7.5 or above). For example, ACC is vulnerable to insecure deserialization of data, which may result in arbitrary code execution.
If the application is using OSS that is out-of-date by many months or years, it may have undiscovered or unreported vulnerabilities. Older software tend to have security vulnerabilities that go undetected or unreported.
What vulnerabilities you allow in your software is up to your company policy, so you need to determine if you will allow the release of software that is old or contains security vulnerabilities.
Solutions
You can do research on each OSS you use. This means visiting the website for the OSS or opening up each JAR file and reviewing the license information. Make sure you track this because OSS can change licenses between releases. Under one version it could be released using the aforementioned BEER license and the next one could be under a copyleft license.
For security vulnerabilities, going to the vendors web site might give you some information, but also review the following:
- https://seclists.org
- https://www.cvedetails.com
- https://www.securityfocus.com
- https://www.osvdb.org/
Also consider using software to scan for these issues. The two that I am most familiar with are:
I am most familiar with CLM, which we installed in a previous company that I worked for; it discovered many issues in the OSS we were using in our products. The software teams had to scramble to fix the issues that were discovered. As I mentioned before, the lawyer did not allow the release of any software with certain licenses. They ended up either upgrading the OSS or removing it completely from the software.
