The pros and cons of adding open source to your software

The State of Software Composition 2017 identified 16,868 unique software components and versions, a majority of which were FOSS packages and libraries. Clearly, open source is here to stay. So what are the pros and cons of using it?

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 Black Duck Binary Analysis, part of our software composition analysis (SCA) solution. 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.

Licensing

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 open source 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. Read more the different types of software licenses.

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.

Post-release

• 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 your changing code libraries.

Get started