In a world where application dependency graphs are deeper than ever, secure engineering means more than securing your own software: tracking vulnerabilities in your dependencies is just as important.
We’ve greatly simplified this process for Enclave users with a recent feature release: Docker Image Security Scans. This is a good opportunity to take a step back, review motivations and strategies for vulnerability management, and explain how this new feature fits in.
Popular dependencies are very juicy targets for malicious actors: a single vulnerability in a project like Rails can potentially affect thousands of apps, so attackers are likely to invest their resources in uncovering and automatically exploiting those.
One infamous (albeit old) example of this is CVE-2013-0156: an unauthenticated remote-code-execution (RCE) vulnerability in Rails that’s trivial to automatically scan for and exploit. Among others, Metasploit provides modules to automatically identify and exploit it.
As an attacker, a vulnerability like CVE-2013-0156 is a gold mine. The exploit can be delivered via a simple HTTP request, so all an an attacker needed to do to compromise vulnerable Rails applications was send that request to as many public web servers as they could find (finding all of them is much easier than it sounds).
In other words: when it comes to vulnerabilities in third-party code, you’re actively being targeted right now, even if no one has ever heard of you or your business.
Now that we’ve established that vulnerability management matters, the question that remains is: what can you do?
Modern apps depend on a number of dependencies that come from diverse sources ranging from OS packages to vendored dependencies. Fundamentally, there’s no one-size-fits-all approach to track of vulnerabilities that affect them.
So let’s divide and conquer: from a vulnerability management perspective, there’s a useful dichotomy between two categories of third-party software.
The easiest dependencies to look after are those that you installed via a package manager, so let’s start with them.
Package managers helpfully maintain a list of the packages you installed, which means you can easily compare the software you installed against a vulnerability database, and get a list of packages you need to update and unfixed vulnerabilities you need to mitigate.
Ideally, you want to automate this process in order to be notified about new vulnerabilities when they come out, as opposed to hearing about them when you remember to check. Indeed, remember that when it comes to vulnerable third party dependencies, you’re actively being targeted right now, so speed is of the essence.
There’s a number of open-source projects and commercial products you can use for this type of analysis. A few popular options are Appcanary (which Aptible uses and integrates with), Gemnasium, and Snyk.
They often work like this:
That simple!? Almost: you’re probably using multiple package managers in your app, which means you may have to mix and match analyzers to cover everything. Indeed, for most modern apps, you’ll have at least two package managers:
So, what you need to do here is locate the list of installed packages for each of those, and submit it to a compatible vulnerability analyzer.
Now’s the right time to tell you about this new Enclave feature I mentioned earlier in this post.
When you deploy your app on Enclave, we have access to its system image. Last week, we shipped a new feature that lets us extract the list of system packages installed in your app, and submit it to Appcanary for a security scan.
This can work in two different ways:
To summarize: Enclave with Appcanary can now handle vulnerability monitoring for your system packages, and it’s really easy for you to set up!
However, for app-level packages, you still have to do a little bit of legwork to find and integrate a vulnerability monitoring tool that works with your app. Note that Appcanary does support scanning Ruby and PHP dependencies, so you might be able to use them for app-level scanning too.
Not quite: we still have to look at third-party code you didn’t install via a package manager. Here are a few examples: software you compiled from source, binaries you downloaded directly from a vendor or project website, and even vendored dependencies.
For these, there is — unfortunately! — no silver bullet. Here’s what we recommend:
This time, that about wraps it up! Or does it? Engineering is turtles all the way down, so even if you covered all your bases in terms of software you installed, there’s still the underlying platform to account for.
That being said, unless you’re hosted on bare metal on your own hardware, this is largely out of your control. At this point, your best strategy is to choose a deployment platform you can trust (if you read this far, hopefully you’ll consider Enclave to be one).