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:
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.
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:
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.
This is just the first integration step with Snyk. There will be an even deeper integration with snyk.io in the future 😉
Now VersionEye is aggregating 7 security databases and more are coming soon!
We just added a new source to our security crawlers. Now VersionEye is using the public API from nodesecurity.io to leverage their database for Node.JS security vulnerabilities. More security databases will be integrated into VersionEye in the next days.
VersionEye is aggregating different security databases and notfies you about security vulnerabilities in your projects. Sometimes one of your dependencies is affected by a security vulnerability but it’s not relevant to you because maybe your application is not exposed to the Internet. In that case you don’t want to receive the same security notification from VersionEye again and again. That can be annoying! That’s why you can mute security vulnerabilities now.
In the security tab below each security vulnerability there is a “mute” button now. If you click on it a modal dialog shows up where you can type in a reason why this is not relevant for you. The first security vulnerability in the above image is muted and the reason is displayed directly next to it.
If all security vulnerabilities in the project are muted you will not receive any security notifications anymore for that project.
We hope this new feature is useful to you.
Maybe you know already the License PDF export feature at VersionEye. Now there is PDF export available for the security tab as well. You find the download link in the project detail view in the security tab.
This PDF export contains a list of ALL dependencies from the project and sub projects with their security status and the date of export. Here you can see how the PDF looks like on my pet project.
At the bottom of the document all vulnerable dependencies are listed with their security vulnerabilities and according links.
This is a very new feature. If you find a bug or you have an idea how to improve it, please let me know. Leave a comment here or contact VersionEye at Twitter.
A couple months ago VersionEye started to track security vulnerabilities for PHP packages. A couple weeks ago the feature was rolled out for Ruby & Node.JS dependencies as well. And now it’s rolled out for Java & Python!
Now you will see the security tab in your Java & Python projects as well. Just like in the example here.
If you click on the dependency link above you will come to the package detail page where more details to the security issues are visible.
If your project dependencies are affected the dependency badge turns to “insecure”, showing everybody that some of the dependencies have security issues.
The security feature is available via the VersionEye API as well. You can filter by language and prod_key. Feel free to build your own integration on it 🙂
VersionEye notifies you about security vulnerabilities independently from the version & license notifications. The security notification emails are going out on each Tuesday.
Currently VersionEye is crawling 6 different security sources for this feature. For Java & Python we are using the victims db, which claims to have 0 false positives. Please contribute to this db if you know about a Java or Python security vulnerability and help to make the world a safer place.
Do you know more good security databases which you would like to see integrated with VersionEye? If so contact me on Twitter please.
Since a couple weeks VersionEye shows security issues for PHP projects. Now this feature works the same way for NodeJS and Ruby packages. If VersionEye is monitoring a Gemfile for you, then you will see the “Security” tab in the project view. Just like here in this example.
In the “Security” tab all known security vulnerabilities are listed for your 3rd party dependencies. If there is a security issue the dependency badge turns red! By clicking on the package name the package detail page comes up with a more detailed description of the security vulnerability.
On the detail the page a detailed description of the security vulnerability shows up and a link to the original source. That way it’s easy to reproduce the security vulnerability.
Now there is now reason not to use VersionEye. You get notifications about:
This feature is pretty new, but already good tested through the PHP community. Your feedback is anyway welcome either here in the comments or on Twitter.
Since a couple weeks VersionEye shows security issues for PHP projects. Now this feature works the same way for NodeJS / NPM packages. If VersionEye is monitoring a package.json for you, then you will see the “Security” tab in the project view. Just like here in this example.
In the “Security” tab all known security vulnerabilities are listed for your 3rd party dependencies. By clicking on the package name the package detail page comes up with a more detailed description of the security vulnerability.
In most of the cases it is recommended to fix the issue by updating to the current version of the software package.
This feature is pretty new, but already good tested through the PHP community. Your feedback is anyway welcome either here in the comments or on Twitter.
Since a couple days VersionEye is showing security vulnerabilities for PHP. If VersionEye is monitoring a composer.json/composer.lock file for you you will see a security tab in your project detail view, there all the known security vulnerabilities are displayed. The problem with that is that you still have to go into the project and into the security tab to see that. If you have many projects, that can be time consuming. It would be great to see directly in the project overview which of your projects are affected. And now it works like that. Now the vulnerable projects are marked completely red in the project overview.
That way you can see immediately which of your projects are affected and how many known security vulnerabilities are assigned to your project dependencies.
Now VersionEye has notifications for security vulnerabilities! This new feature currently only works for PHP. Right now we have 118 security vulnerabilities in our database which affects some of the most used PHP frameworks and libraries. The security vulnerabilities are fetched from the SensioLabs security database. VersionEye is displaying the security vulnerabilities directly on the VersionEye detail pages. Here is an example.
VersionEye is displaying at least 1 link to an article where the security vulnerability is documented in great detail. Beside that the affected versions are displayed as well.
But that’s not all. If VersionEye is monitoring your PHP project directly on GitHub/Bitbucket or Stash, you will see a “Security” tab in your project view. Here is an example.
In the “Security” tab we display known vulnerabilities for your project. If there are any security vulnerabilities for your project the dependency badge turns red to “update!”.
This feature is strongly based on locked versions. If VersionEye has access to your composer.lock file it knows exactly which version you are using in production and it can assign security vulnerabilities 100% accurate. If VersionEye has only access to your composer.json file, but not to your composer.lock file it doesn’t know which versions exactly you are using in production. In that case VersionEye assumes that all version expressions are resolved to the newest version. But because we don’t know it for sure, it doesn’t affect the dependency badge. For composer.json files we display that hint in the security tab.
If you want to take full advantage of this feature you should commit your composer.lock file to your git repository and give VersionEye access to it. That is anyway best practice.
This feature is very new and we heavily rely on your feedback. Please try it out and let us know if you find anything odd.
Open Source License Compliance & Security 