Security Vulnerabilities for JavaScript

VersionEye is aggregating data from different data sources, such as repository servers and security advisory databases. This week a new security database for JavaScript was integrated. Now VersionEye is matching security vulnerabilities from Retire.js with JavaScript modules from Bower.io. If you are using Bower.io to manage your JavaScript dependencies then VersionEye can automatically point out potential security issues in your dependencies.

Screen Shot 2017-08-11 at 10.09.13

Try out this new feature and leave a comment here if you wanna give feedback.

New Feature: Inventory Diff

VersionEye has an open source inventory list for every organisation. That list simply shows all unique dependencies of an VersionEye organisation. The inventory list can be filtered down by different criteria of course.

Now VersionEye can show you the difference between 2 inventory filters. On the new “inventory diff” page you can configure 2 different filters for your inventory and VersionEye will output the differences.

InventoryDiff.png

That is especially useful if you are tracking 2 different versions of a project in VersionEye and you want to see the changes in the dependencies. In the example above we can see the differences between Java projects in version 3.11.4 and 3.11.5. We can see that in version 3.11.5 the graph-api 0.9.1 was added and the testNg 6.11 dependency was removed.

Try out this new feature and leave a comment here if you wanna give feedback.

Ignore UNKNOWN licenses on pull requests

Since a couple months VersionEye can check your dependencies on each pull request on GitHub. That was described here. VersionEye will mark the status of the pull request as failed if:

  • a dependency has a 1 or more security vulnerabilities
  • the license of a dependency violates the license whitelist
  • the license of a dependency is UNKNOWN

An UNKNOWN license is as dangerous as a violation of your license whitelist. Simply because the maintainers of the dependency can come up with a dangerous license afterwards and that could harm your company. That’s why strongly recommend NOT to ignore UNKNOWN licenses.

However, some people want to simply ignore UNKNOWN licenses in their projects. That’s why we introduced this option now. On the license whitelist there is a new checkbox now.

Screen Shot 2017-07-22 at 12.42.22

If that option is checked and the license whitelist is assigned to the project, then UNKNOWN licenses will not cause a failed status on the pull request check. Use this checkbox wisely!

“fetching meta data for undefined” – Bug

If you are running your own VersionEye instance since more than 4 weeks then you might see a message like this in the UI:

“Meta information about the project dependencies are currently fetched from the public VersionEye API. Currently fetching meta data for undefined.”

“undefined” is NOT the name of a dependency! In some cases a variable in JavaScript is undefined. This UI bug is fixed in the newest VersionEye Docker images. Unfortunately the bug is related to some indexes on the database which are not valid anymore. To fix this permanently you have to drop “obj_type_id_index” index on MongoDB. That can be achieved with this commands on the VersionEye server:

 docker exec -it mongodb bash
 mongo
 use veye_enterprise;
 db.sync_statuses.dropIndex("obj_type_id_index");
 exit
 exit

That will remove the index and fix the problem permanently. A new index with the same name will be created automatically in the next 24 hours, from a background job.

Keep your global NPM modules up-to-date

npm can be used to install npm modules to packages (package.json), furthermore npm can be used to install npm modules globally with the command line flag "-g" for system wide usage. Usually this is the way to install „grunt“, „eslint“ or „npm“ itself.

These globally installed npm modules cannot be monitored. They are not updated with "apt-get" or any other system updates. This is usually not a problem on developer machines but it can lead to problems on servers without any interactive logins like Jenkins build server. „versioneye-update“ in the new version 1.4 can create a list of the globally installed npm modules and upload it as package file to VersionEye. The VersionEye server will send you a notification as soon as there is a new version of one of the globally installed modules available.

Read more about this cool feature at the Onwerk blog post. Onwerk is a small company in Mannheim / Germany, specialised in custom software development with Node.JS, JavaScript and .NET. They are very active in the local Node.JS & JavaScript community and they are very interested in working with cutting edge technology.

Perl Support

We just added support for the popular programming language Perl. Right now there are more than 41250 Perl packages in the VersionEye database.

Screen Shot 2017-07-12 at 20.29.14

The cpan.org API is crawled once a day to keep the VersionEye database up-to-date. You can follow any of the Perl packages and you will be notified as soon a new version of the followed package is released.

Screen Shot 2017-07-12 at 20.29.47.png

Beside that VersionEye can parse & monitor the file format “cpanfile”. A cpanfile describes the dependencies of a Perl project. VersionEye can actively monitor your Perl project on GitHub and notify you about out-dated dependencies.

Try out this new feature and feel free to give feedback.

Rust Security

Since today VersionEye has support for Rust security vulnerabilities. Altogether VersionEye is aggregating 8 security databases now. If a Rust package is vulnerable the security issue is showed directly on the Rust VersionEye page. Here an example:

Screen Shot 2017-07-12 at 13.56.56

If VersionEye is monitoring a Rust project for you and one of your dependencies is vulnerable you will get notified via email.

Try out this new feature and give us feedback. We would love to hear from you.