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.
The VersionEye API is heavily used! In the mean white the VersionEye API is serving more HTTP requests then the web application. That’s why made it even more awesome đ
For almost 2 years we didn’t update the swaggerUI, shame on us! The old swaggerUI was a bit buggy. Many times it did not submit input fields to the API, that was specially the case if there was another input field with the same name, higher up on the page. That and many other small issues are solved now with the newest swaggerUI. Beside that the new swaggerUI shows for every request the corresponding CURL command, which is super awesome because that way you can run the commands directly in the command line.
We added a new API Endpoint for sessions/login. Now you can send your user/email and password via HTTP POST to this Endpoint and you will receive back your user object with your user API key. With the user API key you can then use other Endpoints of the API.
That is especially useful if you want to build a login screen for a mobile App like iOS or Android đ
We added a whole bunch of new Endpoints just for the organisation object.
With “/organisations” you get back a list of all organisations where you are in the Owners team. The response includes the organisation API key as well.
With this Endpoint you get back a list of all the teams in the organisation and some basic information about team members …
…Â and projects which are assigned to the team.
With this Endpoint you get back a list of all projects of the organisation. The list contains basic information about the projects. The more detailed information about projects please use the “/projects” Endpoint.
This Endpoint returns the dependency inventory of the organisation. That is a list of all used dependencies overall projects in the organisation.
More information about the data structure can be found here and here is another blog post about the inventory feature.
Leave a comment here if you have questions to this new API Endpoints or if you need another one đ
Version 3.11.1 of the VersionEye Maven Plugin is out and here are the change logs. This release brings a couple improvements and BugFix!
Assume you have a Maven multi module project with 3 modules. Now you add the VersionEye Maven Plugin to the parent pom and run mvn versioneye:create. That will create a new project with subprojects in VersionEye. Now on your CI system on each build you run maybe this goal: mvn versioneye:securityAndLicenseCheck. That will always update the VersionEye project with the current dependencies from your Maven project and check them for security vulnerabilities and license violations. Everything works so far.
Now you are adding a new Maven module to your Maven reactor build and the next execution of mvn versioneye:securityAndLicenseCheck will fail, because it will try to update an non existing module on the VersionEye server.
This bug is fixed now! Version 3.11.1 of the VersionEye Maven Plugin can handle newly added Maven modules. If a new module is added it will automatically create a new subproject for that on the VersionEye server.
For Maven multi module projects one project is created for the parent pom and for each module a project is created on the VersionEye server and merged into the project for the parent pom. This merging process was working through the GAV coordinates of the parent pom. That was leading to problems if the same project was monitored twice on a VersionEye server. The new merge mechanism is independent from the GAV coordinates, it only relies on the project ID from the VersionEye API.
The VersionEye Maven Plugin is resolving all dependencies locally and only sends a pom.json file to the VersionEye API, which contains only the needed information. Now this pom.json file also contains the license from the pom.xml file and the project license is displayed in the web interface.
VersionEye is monitoring more than 1.2 Million open source projects by now. You can follow any of those OS projects at VersionEye and as soon a new Version of the followed package is release you will receive an email notification.
The notifications which are created and send out to you are available in the web interface as well, but it was a bit hidden up to now. In the current version new notifications count is displayed with a red banner in the main menu. Just like you know it from Facebook and other social networks. Here an example:
Directly next to “Organisations” in the main menu you can see a red 1. That means you have 1 unread notification. If you click on it you get to the notification view and the red notification count disappears.
That way you see immediately if there are new releases out there. Even before you get the email đ
The notifications for new artefacts you are following are available via the public VersionEye API as well. It works exact the same way. If you have unread notifications the API will return a list of notification entities and each of the unread notifications will have the flag “read = false”. If you fetch the same resources again the “read” attribute will be on “true”.
Beside that the API also returns the information if the notification was already send out vial email or not.
By the way. There is a new VersionEye – Slack connector which is already using this API Endpoint. With that you can receive the notifications directly into your Slack channel!
Leave a comment here if you have feedback.
We have some exciting news for our community – VersionEye is now open source, licensed under MIT!
VersionEye is a popular platform for software developers, which notifies you about out-dated dependencies, security vulnerabilities and license violations in your software projects. This makes your agile software development more productive, reduces problems, risks and ensures compliance. Currently VersionEye supports 12 package managers and is well integrated with GitHub, Bitbucket and Atlassian Stash. GitLab support is coming soon!
Our SaaS solution is used by thousands of software developers every day and the number of visitors and users is growing constantly. For VersionEye Enterprise we have a handful big installations at well known DAX companies where itâs used as on prem. solution, successfully integrated with LDAP and private Git & Maven repositories.
I talked with many people about open sourcing VersionEye. Some of them recommended to do it and others not. Like everything in life it has pros and cons. But in the end, I decided to open source it to provide more transparency because many of our users care a lot about privacy and transparency. Specially big insurance companies in Europe have to follow very strong privacy laws. Up to know VersionEye Enterprise was a black box delivered as VMWare image without any root access for the customer.
For many big companies this is an issue because they don’t know whatâs really happening inside of the black box. As more and more big companies are rebuilding their entire infrastructure with open source components like Linux, Archiva, CoreOS, Docker, Kubernetes and GitLab, as less they want to have proprietary black box software. Now VersionEye is open source under MIT license and everybody can use the software for free, just like CoreOS, Docker and GitLab!
Nobody has to unjustifiable fear any longer that VersionEye is doing any unauthorised action like copying source code, exposing confidential data or causing any harm. You can simply go to GitHub and do a code review by yourself! Being an open source project means to be fully transparent and trustable. Since VersionEye is open source nobody is questioning statements to privacy anymore. It adds a lot of trust to the project because every change on the code base is public and everybody can review whatâs going on.
Until now the biggest part of VersionEye was closed source and the only way to contribute was to open a ticket in our public ticket system and wait until somebody from the VersionEye team implemented it. In the last couple years ~ 800 tickets have been opened from the community and we could close most of them. But now itâs different. If you know how to code you donât have to wait for the VersionEye team anymore. You can implement new functionality by yourself and send back a pull request to VersionEye.
The VersionEye API is online since 3 years and the open source community created already a lot of AddOns & Plugin on top of it. For all major build tools there is a native VersionEye plugin, there are several command line tools, Slack connectors and even a native Mac OS X app for VersionEye. All build on top of the public VersionEye API. This is awesome because all this work is coming from volunteers. Nobody paid them to do this work. They did it in their free time because they wanted to use this tools for themselves and they shared it with the community. You guys are all awesome and by the way you created an ecosystem around the VersionEye platform! Many Thanks for that!Â
In the meanwhile the VersionEye API is processing more requests than the web servers! That shows me that the people are using the VersionEye platform strongly customised in their own tool chain and in their component lifecycle management. They use VersionEye through native plugins, AddOns and other tools which are based on the VersionEye API.
Now we take it to the next level. Now versioneye-core, versioneye-api and versioneye-www is open source as well and everybody is enabled to add new features to the product and I hope to get a lot of contributions from the open source community.
As the software itself is published under MIT license, we canât charge Money for VersionEye Enterprise anymore. MIT license means everybody can use the software for free, even for commercial purposes. The software is provided âAS ISâ and âWITHOUT ANY WARRANTIESâ. The cloud offering at VersionEye.com remains the same of course. You can still pay us for the hosted version if you don’t want to maintain the VersionEye software by yourself.
If you spin up your own VersionEye instance with Docker Compose your database is empty, of course. That means you can upload a package.json to your VersionEye instance but in the project report all your dependencies will be displayed as unknown because the database is empty and your local installation doesnât has any information about NPM packages.
With an empty database the software isnât much fun đ
Luckily there is a âsyncâ mechanism build into VersionEye Enterprise and as soon there are new project dependencies in the system, the local installation will fetch the missing meta information from the public VersionEye API. The access to the VersionEye API requires an API key and is limited to 50 requests per hour by default. For more requests a paid account is required.
Of course, anyone could run and maintain their own crawling framework but this neither an easy nor  a cheap thing. We are constantly improving and monitoring our crawling framework. In addition to that we run regularly data repair jobs to improve the quality of the data and we do a lot of manual edits as well.
If an Enterprise customer is using an old JAR file which doesnât provide a license in the pom.xml file we are opening the JAR file and try to find a license inside of it. If that fails too, we are looking up the contact details of the core committers and ask them via Email about the license of their software.
If an NPM module on GitHub doesnât provide the license in the package.json, we add it and send back a pull request. If the GitHub repo of the NPM module doesnât has a license at all we are opening a ticket and asking for the license.
That are just a few examples we do to improve the quality of the VersionEye service.
If you think you have a serious issue with VersionEye you can now study the source code and try to fix the problem by yourself, which might create some effort. But if you have a service/support contract with VersionEye GmbH you can just post into our Slack channel or send us an email and you will get a response in hours and in most of the cases we can fix your problem asap.
Maybe you want to have custom reports, custom emails or you want to have support for your self-developed package manager? This are all things you can implement by yourself, but obviously we can implement it faster and more economical than anybody else as we do know the VersionEye code inside-out đ
If you want to have a custom feature feel free to contact us at support @ versioneye.com.
Since almost 3 years VersionEye is running on Docker!
Now the VersionEye Docker repositories on Docker Hub are public. Every time we do a deployment to production a new Docker images gets published on Docker Hub. In this GitHub repository there is small tutorial how to spin up the VersionEye Docker containers with Docker Compose: https://github.com/versioneye/ops_contrib.
If something is unclear feel free to open a ticket or to send a pull request đ
Plase see the comments at Reddit.
Many software companies are leveraging open source software as part of their business models and solutions. The reasons for doing so are simple: Open source software usually does not carry license fees, has high quality and can be easily accessed.
So let us talk about how commercial software vendors are using open source components as part of commercial software. Despite the opportunities and advantages open source provides, there are important development operations aspects, like updating open source components, and risks like security vulnerabilities that have to be managed. So let us look a little deeper into each of these aspects.
Development operations issues
On average, software products usually contain between a few and a few hundred open source components (source: hippocmms.com/software). The complexity gets even worse when we consider the fact that open source components themselves often contain numerous other open source components.
While it is easy for a developer to follow the community for one component, it is hard to follow the communities of dozens or hundreds of open source components. Getting notice of updated and improved versions of many open source components is often impossible. So the usage of numerous open source components leads to high effort maintenance work for developers which lowers productivity. Fortunately, tools like VersionEye allows you to manage and update these components continuously and lets you leverage developer capacity for innovation instead of looking for updates of open source components
Risks
One key source of risk of open source besides license compliance are security vulnerabilities, that are not fixed. To determine security vulnerabilities is a high effort activity. Fortunately, many people in the open source community test, collect and fix open source security vulnerabilities. The developer only needs to get notice of these activities.
Nowadays, many updates of open source components are related to fixing security vulnerabilities. Missing a security update is critical. If a developer misses an update, he exposes products and their customers to a hacker attack. Hackers know that a vulnerability exists in an old version of the open source component. Fortunately there are tools like VersionEye that track security vulnerabilities for you and alert you regarding those vulnerabilities and about security related security updates of open source components.
New book on open source best practices
There is a new a book that has all the necessary background information. It provides an overview of business models, processes and tools relevant for commercial software vendors leveraging open source software and open source communities, no matter if the company participates in open source development or not. The one of a kind combination of academic and pragmatic information, from researchers, practitioners and tool vendors like VersionEye make this book a must have for all people in the software industry.
The book is called âBest practices for commercial use of open source softwareâ and it is available in all major online and offline bookstores, in Google Play, iBooks and on Kindle. ISBN 3738619097
This is a guest from Dr. Karl Popp, Senior Director Corporate Development M&A @ SAP.
Dr. Karl Popp is all about corporate development and mergers and acquisitions in the software business, from successful partnerships to successful mergers and acquisitions. He loves to share his wisdom in books and other media like http://www.drkarlpopp.com.
Last week I did a talk about Dependency & License Management at the Eurostaff Connect(s) – Berlin Developer Group. I was not able to do the trip to Berlin, that’s why we did the talk remote via Skype screen sharing.
I recorded everything with ScreenFlow, but unfortunately the recording was without sound. That’s why I did the presentation again and recorded it this time with sound đ Here is the presentation on YouTube:
And here are the slides on SlideShare:
Feel free to ask questions here in the comments.
Assume VersionEye is monitoring a Gemfile for you on GitHub and now a new version of webmock was released. Your project on VersionEye maybe looks like this.
Webmock is marked red because version 1.20.3 is requested in the Gemfile, but the newest version is 1.20.4. Now let’s say, for what reason ever, you want to ignore version 1.20.4 of webmock. Maybe it includes a bug or it’s just not compatible with your current application. But VersionEye is checking your Gemfile every day and you receive every day an email with the information that your webmock is out-dated. And you know it and you are annoyed of the email!
In that case just click the little green “mute” icon on the left side in the row. That will mute the current version of the dependency and the row turns green!
Now you will not receive email notifications to that anymore. The “mute” mode will be reseted if the next newest version comes out. Let’s say version 1.20.5 of webmock comes out. In that case the row will be red again and you receive an email notification. Now you can update or mute again!
The mute feature even effects the project dependency badge. But keep in mind that the dependency badges are cached for 24 hours for performance reasons.
Let me know what you think about this new feature! Either here in the comments or on Twitter.
Find out how Continuous Updating can really help you.
VersionEye founder & CEO, Robert Reiz, will talk about âContinuous Updatingâ on August 22nd at the “meet the cloud” meet & greet, presented by open it berlin.
All software developers who want to know how they can keep their software projects up to date, and want to find out quickly and easily what dependencies are out-dated, should learn more about our convenient SaaS solution. Using VersionEye you will be informed about new versions of your open source software libraries to be always up to date.
We are looking forward to seeing you there! The participation is free of charge, but please send an email to Michael Stamm for your registration: stamm@tsb-berlin.de or register here: http://www.open-it-berlin.de/veranstaltungen/meet-greet-mit-open-it-berlin-meet-cloud
date: August 22, 2013
time: 3 pm to 6 pm
location: TSB Innovationsagentur Berlin GmbH, Ludwig Erhard Haus, 5. OG, Fasanenstr. 85, 10623 Berlin
Open Source License Compliance & Security 
