Unless you are a developer who enjoys reinventing the wheel (and spending countless hours or weeks developing functionality that already exists), it’s likely that you use open source dependencies in your projects. While it is great being able to easily incorporate functionality that you didn’t write into your application, such as user management, it does not come without risks.
Two of the major risks are licensing and security vulnerabilities, both of which are exacerbated when an application grows. When developing an application, your transitive dependencies (which are dependencies that your direct dependencies require) are increasingly hard to track down because there can be many layers of dependencies. Finding all of them can be an onerous task as they are often hidden inside packages.
Considering your direct dependencies rely on transitive dependencies, this is a serious concern for developers using open source. In this piece, we will explain why improving open source software visibility is critical for managing the risk associated with licensing and security vulnerabilities.
Licensing of open source software may seem like a simple task when only a few dependencies are being used, but this task can quickly turn into a nightmare when you dig into the details. Not only does one need to keep track of all the direct and transitive dependencies in the product, but one also needs to determine what license is associated with every dependency, which is no easy feat.
Maintaining this list of dependencies and licenses is a tedious task, made even harder by the fact that finding the license for a dependency is rarely straightforward. Based on our own experience with our internal tool, we have come across several problems with this approach.
For instance, finding all direct dependencies along with transitive dependencies requires effort in maintaining scripts that ensure every dependency gets recognized. Then, once a list of dependencies is established, carrying out due diligence of each license can be a laborious endeavor because:
- Not all bundles have licenses included in the package or stated within the included files
- Other packages have multiple, sometimes conflicting, licenses
- Other packages can be downright confusing, such as when a different license is stated in the bundle than what it is in the source code e.g. we have seen cases when the reported license is Apache 2.0, while the source code contains references to GPL 2.0…
Incorrect licensing can have significant effects on a commercial product, since a copyleft license such as GNU General Public License 2 without any exceptions can require the product’s source code to be freely available. So for instance, if you incorrectly report a package to be licensed under Apache 2.0, but it turns out that it was GPL 2.0, you can suddenly find yourself managing an open source software that was previously a commercial product. So ideally we want to discover the dependencies with unacceptable licenses and replace them as soon as they are added to the product.
Solving licensing issues
One tool that enables easy management of dependencies, their licenses and their known security vulnerabilities is Sonatype’s Nexus IQ Server. IQ Server is a web application that automatically recognizes components, or parts of components, included within a product and provides information regarding licenses and security vulnerabilities for the discovered components. The application allows for easy bookkeeping of dependencies along with observed and declared licenses, as reported by IQ Server, and licenses that are deemed to be the correct or effective by the user.
Furthermore, policies can be set on IQ Server to define which licenses are acceptable and which unacceptable, allowing developers to be notified as soon as a product containing unacceptable licenses is scanned. IQ Server’s policies thus allow for the automation of dependency approval, and diminish the need for developers to remember which licenses are to be avoided.
As important as licensing is for the success of a product, the success of a product also depends on minimizing the security vulnerabilities contained within it. Security vulnerabilities could, among others, lead to access to sensitive data, user impersonation, or denial of service, which could have detrimental effects.
Prior to using IQ Server, we would spend time looking up Common Vulnerabilities and Exposures (CVE’s) for dependencies included in our product by hand. However, with IQ Server the process has become much simpler. IQ server collates research from several sources including their own research team, providing detailed vulnerability information and suggested upgrades to avoid the vulnerability.
Not only does the application give information on confirmed CVE’s for the current version of the component, it also shows a record of CVEs for other versions of the component, allowing you to pick a version with less vulnerabilities. As with licensing, policies can also be set up for security vulnerabilities, notifying developers immediately when a dependency with a high severity security vulnerability is introduced.
IQ Server provides an elegant solution to keeping track of dependencies along with their licenses and security vulnerabilities, but together with Tasktop Integration Hub it can provide instant notifications on changes in the license status of dependencies or updates in policies.
Currently, IQ Server provides web hook functionality for four event types:
- Policy Management Event
- Application Evaluation Event
- Security Vulnerability Override Management Event
- License Override Management Event
When events such as updating of a policy, completion of an evaluation, or changes in the license status of a dependency occur, using Tasktop Integration Hub, they can be easily converted into JIRA tasks or passed on to any other connectors serviced by Tasktop.