VersionEye has open-sourced its eponymous continuous integration tool that helps with updated project dependencies. Coined "continuous updating", the tool provides update notifications, licence checking and security vulnerabilities information for many software libraries. By open-sourcing the software, VersionEye founder Robert Reiz intends to increase trust in and transparency of the code base for accessing private repos.
The tool is integrated with GitHub, Bitbucket, and Stash to search for outdated dependencies in projects written in Java, Ruby, Node.JS and other common programming languages with package managers. The most recent addition is support for .NET.
To start using VersionEye, users login with their repository account and the software will scan all projects, detect the corresponding dependencies and notify regularly on outdated libraries. With licence whitelisting, users can also define which licence type are appropriate in their projects and turn on security vulnerability alerting.
Popular libraries are expected to fix bugs and vulnerabilities in a timely fashion. According to Robert Reiz, founder and CEO of VersionEye, who is tracking the changes, over 1 million new versions are made available per year, 90% of which are minor or patch i.e. by definition not breaking the API. However, the benefits are of course only achieved by actually integrating the changes into dependent applications. Research suggests that following risks exist when using outdated dependencies:
- Security: A dependency may contain security vulnerabilities. When a dependency is not updated to patch such a vulnerability, the system may be at risk.
- Flexibility: Up-to-date dependencies allows the organisation to respond to change more quickly, because recent dependency versions are easier to update than older dependency versions. New functionality in dependencies is already available.
- Stability: Dependency updates often contain bug fixes, improving the stability and correctness of the overall system.
- Compatibility: External changes to the system’s environment may stop the system from functioning.
InfoQ had a chance to speak with Robert about the tool and going open source:
InfoQ: How can users benefit from dependency update notifications?
VersionEye continuously keeps an eye on around 1 million software libraries in different package managers and therefore knows what the current version a specific library has. It can monitor your package.json file on GitHub, for example, and notifies you on a daily basis about out-dated dependencies. The frequency of the email notifications can be defined for each project. The options are daily, weekly, monthly or never. VersionEye has support for 12 package managers such as Maven, NPM, PIP and understands their syntax.
InfoQ: Some software libraries are using copyleft licensing, that makes them harder to use in an enterprise setting. How does VersionEye help?
The VersionEye crawlers are collecting meta information to software licenses as well. Currently, we have license information for about 6 million software artifacts and growing. In the license tab VersionEye will list all the project dependencies and their licenses. In addition, there is a chart which displays the distribution of the different licenses in the project. Optionally, a license whitelist can be created to whitelist only certain licenses, for example MIT and Apache. If a license whitelist is assigned to a project VersionEye will check all the licenses which are used by the dependencies against the license whitelist and if there is a violation an email notification is triggered. With the VersionEye Maven Plugin it is even possible to break the build on the CI server if there is a license violation. Some of our enterprise customers are using it exactly that way.
InfoQ: How does security vulnerabilities checking work?
VersionEye is aggregating 5 security databases for Java, PHP, Ruby, Node.JS, and Python and is doing the matching from the security vulnerabilities to the corresponding artifacts of the package manager. With the right setup, for example the VersionEye Maven Plugin, VersionEye Gradle Plugin or VersionEye SBT Plugin, it is possible to break the build on the CI server if the project is affected by security vulnerabilities. Of course it is possible to mute security vulnerabilities per project if somebody decides that it is not critical.
InfoQ: Do I need to adapt my development process in order to use VersionEye effectively?
If your project is on GitHub or Bitbucket you can signup for free with your GitHub or Bitbucket account and simply select the project files which should be monitored by VersionEye. That way you will receive email notifications for your projects automatically and you don't have to do anything else.
If you want to take it one step further you will integrate VersionEye into your build and test lifecycle. Pretty much all major build tools have a native plugin for VersionEye, using the public VersionEye API. These plugins execute checks during build time for security and license violations and to break the build if wanted. That makes sense for large companies which have to ensure QA for many software projects and developers.
InfoQ: What led to your decision to open-source VersionEye?
We open sourced VersionEye because we want to get a higher distribution of the software and hope for contributions from the open source community.
Up to now, we sold the enterprise version of VersionEye as a VMWare image. The process of delivering and securing that image was time consuming and not enjoyable. It worked but it was hard to sell the software. Enterprises were concerned about transparency and security because they didn't know what exactly is happening in the black box which they would run on their infrastructure.
Now, we don't need to worry about securing VMWare images and keeping the code secret and our customers don't have to worry about black box software anymore. If everything is open source the whole distribution and maintenance becomes much easier and large companies get the transparency and trust they are looking for.
InfoQ: How does that change your business model?
Last year we sold software, now we sell access to the VersionEye API, hosted software and support. Everybody can grab the code from GitHub for free or the Docker images from Docker Hub. But if you start your own VersionEye instance your local database is empty. Your locale database can be up-to-date through a sync mechanism from the VersionEye API and that is something you have to pay for. Alternatively, you can run the Java crawlers on your own but so far nobody wants to maintain a whole crawling framework. It's much easier and cheaper to fetch the data from the VersionEye API.
