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.
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.