Open Source Component Inventory

If you are working in a big company with many software projects it’s very likely that you are using many open source components as dependency. But how do you keep track of it? How many components are you using in different version of multiple projects? You don’t know? This are questions VersionEye can answer you in seconds.

If VersionEye is monitoring your projects you can take advantage of the “inventory” feature. Simply click on the “inventory” link in your organisation and VersionEye will show you ALL the open source components your organisation is using over all the projects which are monitored by VersionEye. That can look like this.

Screen Shot 2016-10-19 at 22.21.53.png

It’s long list of all the components and below each component you can see which of you projects are using it in which version. If a project is using an out-dated version of the component the line is marked yellow.

Here is another screenshot with some comments to the meaning.

Screen Shot 2016-10-19 at 22.21.53 2.png

That’s already pretty cool because this open source inventory list is generated in real time, it always shows you the current status of your projects. But the really cool thing is that you can filter the inventory by different criteria like:

  •  Teams
  • Language
  • Project Version
  • Duplicates

Let’s make an example. Assume you don’t wanna see the full list of components, you are only interested in open source components which are used in 2 or more different versions over different projects. In that case you would select “All teams”, “All languages”, “All versions”, “only duplicates” and hit the “Filter” button. The result would like similar to this.


In the example above you can see that the component “versioneye-core-j” is used in 2 different versions over 4 different projects.

Now let’s say you only want to see duplicate open source components in the “developers” team. For that you would select the team “developers” in the first field and hit the “Filter” button. Here is an example.


In the example above not ALL projects in the organisation have been analysed. In this example only the projects which belong to the “developers” team have been analysed and now we can see that testng is used in 2 different version over 2 Java projects and capybara is used in 2 different versions over 3 projects.

Now let’s say you want to see the open source dependencies of a team over all projects, but if a dependency is used by another team as well you want to see that as well. For that you would select for example “Team: developers”, “All languages”, “All versions”, “Show duplicates” and hit the “Filter” button.


Now all the dependencies from the “developers” team have been analysed and in this example we can see that the component “versioneye-maven-plugin” is used by 2 projects in the “developers” team AND in addition to that in the last 2 rows we can see that this dependency is used by 2 other projects as well which are in a complete different team.

I hope this new filter options are helpful for your daily work. Leave a comment here if you have feedback.

Vagrantfile for VersionEye

The VersionEye software is bundled in Docker images. Every time we do a deployment to production a new Docker image is build and published to Docker Hub. As we do several deployments per day there are new VersionEye Docker images every day. The whole software stack includes 8 Docker images currently and in the versioneye/ops_contrib repository it is described how to start and manage them.

To make it even easier to get started we published a Vagrantfile for it. Simply clone the versioneye/ops_contrib repository and run this command:

vagrant up

That will create a new Vagrant box and install & configure all the VersionEye Docker images on it. Depending on your internet connection it can take a while. If everything is done the VersionEye web interface can be reached under this address in the browser

It was never easier to start your own VersionEye instance🙂

Pull request support for GitHub

77% of all our signed up users are coming from GitHub and they use VersionEye to monitor their GitHub repositories. For a while now there is a VersionEye service hook in GitHub which calls back the VersionEye API on every git push event and updates the corresponding project in VersionEye with the latest dependencies from GitHub. But now you can use VersionEye to test your changes directly in a Pull Request and see the results of those changes in the GitHub Pull Request UI. This way you can even enforce rules that would prevent a Pull Request merge if a dependency is blacklisted or it is flagged with a security vulnerability.

Given that GitHub is moving away from Service Hooks towards native WebHooks, we changed our integration to do the same. If you are logged in to VersionEye with your GitHub account you can simply click the link “Create from GitHub” and navigate to a repository where you will see all supported project files and the corresponding branches. To monitor a project file simply flip the switch directly next to it.

Screen Shot 2016-08-16 at 14.05.48

In the example above the Gemfile in the develop branch is monitored by VersionEye and it works like this: Every time a new project file is imported from GitHub, VersionEye will automatically create a web hook on that GitHub repository, which will call back the VersionEye API on each “git push” event and if the monitored files are affected, VersionEye will re-parse the files and update the view in VersionEye immediately.

The cool thing is that this also works with pull requests! Assume somebody is forking your project, adding new dependencies and sends back a pull request. In that case the VersionEye web hook kicks in and checks if some of the dependencies have security vulnerabilities or unknown licenses.  For those cases, VersionEye will respond to the pull request with  a “failed” status message  and you can see the result directly on the GitHub Pull-Request tab, like this:


By clicking on the “Details” link you can see a more specific report at VersionEye for that pull request.


A report like this is generated on every new commit which is added to the existing pull request. It’s similar to a build at TravisCI. Now you can still merge the pull request if you like but at least you are informed about security vulnerabilities and license issues.

In the VersionEye UI you will find a new sub menu “Pull requests” in the organisation view. Here are all commits from all pull requests are listed which belong to your organisation.

Screen Shot 2016-08-16 at 14.22.50

The interesting part here is how VersionEye is combining dynamic and static analysis. Your project is checked for security vulnerabilities and licenses on each commit and each pull request but also regularly independent from that. Even if there are no commits and no pull requests for a couple days, VersionEye will check your project once a day by default and send you an email if a new security vulnerability was found for one of your dependencies.

With this new feature the developers are getting instant feedback to their changes. In real time the dependencies are analysed and the developers informed. That saves a lot of Time & Money. We think it’s important to run this kind of analysis as early in the development process as possible. If your software is already bundled and published to a binary repository it’s too late for this kind of analysis because your software might be distributed already to a high number of devices/clients. Run your analysis as early and as often as you can😉

And by the way, that’s all open source😉 You can run the software on your own infrastructure and it works well together with GitHub Enterprise🙂

This is a pretty new feature. If you find a bug or you have some kind of feedback, simply open a ticket here.

Improved proxy settings

We just improved the proxy settings in VersionEye again. If you spin up your one instance of VersionEye, you have to activate your instance with an API key. That step can already fail if you are behind a Proxy. Now in the newest version you can enter proxy setting already on the activation page.

Screen Shot 2016-08-15 at 14.07.49

If your instance is activate and you are logged in as admin you can change the proxy settings in the settings area.

Screen Shot 2016-08-11 at 09.48.50

Let us know how that works for you.

Proxy Settings for VersionEye Enterprise

If you run the VersionEye Docker Containers on your own Infrastructure, then it might be that you are behind a Proxy. Especially in big companies there is always a central Proxy between all internal machines and the Internet. Now there is a new form in VersionEye there you can configure your Proxy settings. If you are logged in as admin you will see a new menu entry in the settings “/settings/proxy”.

Screen Shot 2016-08-11 at 09.48.50

Here you can configure your Proxy settings. That is especially important for the daily sync to the public VersionEye API. If you VersionEye instance can’t reach the public VersionEye API in the Internet the sync mechanism will fail and your local database remains empty.

Integration with Snyk.IO is a new StartUp in the security field. Their goal is not just to find new security vulnerabilities, but also to fix them automatically. Currently the Snyk team is focused on security vulnerabilities for Node.JS/NPM packages. We work close together with the Snyk team and just finished the first integration. Now the Snyk security database is available through VersionEye as well. Here is an example how a Snyk security vulnerability looks on a VersionEye page:

Screen Shot 2016-08-04 at 13.25.56

Of course the new security vulnerabilities are available for your private Git projects as well. VersionEye can monitor your Node.JS project on GitHub or Bitbucket and notifies you about security vulnerabilities in your 3rd party dependencies.

Screen Shot 2016-08-04 at 15.12.34

This is just the first integration step with Snyk. There will be an even deeper integration with in the future😉

Now VersionEye is aggregating 7 security databases and more are coming soon!

VersionEye Maven Plugin 3.10.2

Today we released the VersionEye Maven Plugin 3.10.2. This patch release is fixing a bug which occurred on big multi module projects, where sometimes the project_id couldn’t be found. Beside that the logging is improved. Now the plugin will log out at which places it is looking for the project_id. That way it’s easier do debug if something goes wrong.