Jan Krutisch, Co-Founder at Depfu

Ever since we started working on Depfu, we knew that we wanted to add special handling of security updates. Security has always been one of Depfu’s main selling points: Only an up-to-date application is a secure application. But until now the Depfu robots didn’t have any idea if an update was actually important for the security of your application.

Today, we released our first version of flagging security relevant dependency updates. Here’s how that works:

As soon as Depfu notices that a certain gem update is due to a security vulnerability, we’ll try to make sure that you will get the update PR as quickly as possible, with the best fitting version and with all needed information to quickly patch your app.

Let’s break these down one by one.

As soon as possible

Timing around security vulnerability disclosures is usually messy. The main focus of the gem maintainers is, of course, to get the fixed code out. Only then will they write posts to the relevant security mailing lists and (maybe) add the vulnerability to the Rubysec database.

The Rubysec database, apart from commercial services, is the only data source that we can query automatically. This means that there’s a (sometimes multiple days) long gap between a gem version hitting rubygems.org (and thus starting the Depfu engines) and the Rubysec database entry that would allow us to flag the update as a security update.

While this sounds like a problem that makes security flagging useless, it turns out that in reality, it’s not so bad.

First of all, it is not unusual for Depfu pull requests to lie around for a bit - and usually this is not a huge problem. When we do get the information that an update is relevant for your app’s security, we immediately update the PR to include the security information which hopefully gives you the needed sense of urgency.

Jumping the queue

Second, teams with a larger number of outdated dependencies can sometimes run into our “update queueing”, which means that we won’t create new PRs on a project unless the number of open Depfu PRs falls below a certain number. This is a very helpful feature for busy teams, but of course it would be quite bad if an important security update would be stuck in that queue for too long.

Now that we can identify these scheduled updates as soon as a new security notice comes in, we can make them skip the queue so that you definitely will get the PR as fast as possible.

Best fitting version

We will also try to be smart about what exact version of a fixed gem to update to in the PR. For example, if you run example-gem 1.4.5 and updates for example-gem fix an important security issue in both example-gem 2.3.1 and example-gem 1.4.6, we will open up a PR for 1.4.6, as this is most likely the version that will fix the security issue on your project with the least hassle.

The pull request for a security update will contain all the relevant information on the vulnerability (as documented on the Rubysec database) which should give you a good idea about the urgency of the update:

Summary

This all, of course, does not make Depfu a full replacement for commercial security notice services or makes it less valuable to subscribe to the relevant mailing lists. If you run a large application with a huge attack surface, the Depfu mechanisms might be a tad too slow - but we hope that this feature will nevertheless help teams to keep their applications more secure with less work.

It’s also one important piece on our bigger mission to get much smarter about which updates to send you when, so we can reduce the noise for your team.

Oh, and by the way: We’ll be at Euruko 2017 and would love to talk to you. So if you see us in some bright blue t-shirts, come say hello!