Software Integrity


The pros and cons of adding open source to your software

The pros and cons of adding open source to your software

For years, free and open source software (FOSS) has a had a negative connotation, with some developers forbidden to use it in final software product releases. The obvious downside in avoiding open source is that organizations run the additional risk of introducing avoidable vulnerabilities. For example, an organization with no cryptographic experience should not be creating their own cryptography.

The State of Software Composition 2017, published last week by Synopsys, analyzes 128,782 application uploads to the Synopsys software composition analysis (SCA) tool, Protecode SC. The report identifies 16,868 unique software components and versions, a majority of which were FOSS packages and libraries. Against these, the report identifies a total of 9,553 specific CVEs. And against those, it found there is almost always an updated version of the vulnerable component available.

The troublesome 10

The Synopsys report identifies the 10 most common software components—curl, dropbear, expat, libjpeg, libjpeg-turbo, libpng, linux kernel, lua, openssl, and pcre—where most of the observed versions in 2016 were outdated. For example, the report observes 727 distinct versions of Linux Kernel, with 710 versions being outdated and—perhaps more importantly—vulnerable to existing CVEs.

For each of the 10 there are newer, updated versions available. This suggests a number of issues:

  • The use of third-party repositories
  • The use of recycled code
  • A lack of awareness of newer versions
  • A lack of a way to update the software product once it has been released

Go to the source

Although, in most cases, a good SCA tool identifies the correct software version of a component, the State of Software Composition 2017 report finds a fair number of unknowns associated with each component. These are versions of a component that varied in some meaningful way from the original. Most likely these are forked versions that may contain additional (and unwanted) features. Sometimes there are logical reasons behind this.

Let’s say a project is on a deadline. Why look for new code when that package of OpenSSL worked in a previous software release? The same holds true with recycling old native code. Or say, as a developer, you frequent a third-party code repository where it is “one-stop-shopping” for all your software needs. The convenience simply outweighs the risk.

No update path

Let’s also say the FOSS in question is the most current version of that component at the time of release. What happens when another FOSS version comes along—perhaps addressing a new CVE? Not all applications and software today are designed for updates, which is a mistake. Software is that not static. It decays.

Even at the time of first release, almost every software product will likely have some vulnerabilities intentionally left unpatched. These vulnerabilities have been assessed by the development managers and determined they aren’t likely to introduce risk. Mostly likely the vulnerabilities are considered benevolent because they cannot (as implemented) be exploited. That threat assessment, however, will change over time, starting on day one.

Software decays

What happens when new vulnerabilities are disclosed? There is certainly a direct risk from the new CVEs. There is also a risk that these new CVEs may also combine with the existing vulnerabilities already in the code.

Not all CVEs are exploitable. Sometimes there needs to be more than one vulnerability for an exploit. This changing landscape demands that the software product has a path for updates. If an organization is unprepared to maintain its product, it could expose users to increased risk. It certainly will cost an organization extra money for the man hours necessary to rush out a patch.

software decays


Another reason organizations ban open source software is the unknowns of software licensing. FOSS is not always free. Although anyone can download it and adopt it into most any project, there are licensing distinctions that may require an organization to make their proprietary software source code public. A good SCA tool identifies the license associated with each component, and helps developers choose wisely.

While there are many different flavors of software licenses, here are the five most common software license models:

Public Domain

This is the most permissive model. It means that anyone can modify and use the software without any restrictions. Again, just because it is free and without any legal strings attached, you should always check to make sure it is secure before adding it to your own codebase.


A permissive software license contains minimal requirements regarding software modification or redistribution. Also known as “Apache style” or “BSD style,” this license is perhaps the most common and popular among free and open source software. Aside from Apache and BSD, another common variant is the MIT license.


The GNU Lesser General Public License (LGPL) is published by the Free Software Foundation (FSF). It allows developers and companies to use and integrate free and open source software into their own proprietary software. The catch here is that any end user of your software also has the right to modify the code. Therefore, you must make your own source code available. Exposing your source code may not be in the organization’s best interests.


The use of Copyleft allows the end user to freely modify and distribute new works based on your work with the requirement that any new works or adaptations of the original are bound by the same licensing agreement. For example, you might say the work is free to use and distribute for personal use only. Any derivative would also be limited to personal use only.


Of all the software licenses, this is the most restrictive model. The idea behind it is that all rights are reserved and is generally used for proprietary software where the work may not be modified or re-distributed.

Free and open source software guidelines

Organizations should not be afraid of FOSS. Instead of asking whether to include open source, consider asking what version of open source to include. Here are some guidelines:

In development
  • Adopt only trusted repositories for open source software, preferably from the source
  • Use only the latest stable release
  • Upon integration, perform SCA on all third-party code
  • Identify and remove any components whose license agreements fall outside company policy
  • Make SCA an active part of your software post-release life cycle
  • Use SCA to monitor the ongoing state of software decay
  • Update third-party software libraries as appropriate when necessary


Monitor the changing code libraries.
Get started