You’ve probably built a container image, whether you cloned a repo and ran docker build && docker run, or thoughtfully crafted your own Dockerfile and build process. Developers are increasingly shipping code packaged as images deployed to the cloud.

The image is where all stakeholder inputs to an app converge

A container image is a handy, portable format for running your code that encapsulates the entire runtime environment from OS to app layer. It's also the most logical place to look at vulnerabilities.

The image is where all stakeholder inputs to an app converge. The base image you selected is underneath, the tools and libraries your app uses are layered on, and your application is baked on top. This is where it all comes together.  Scanning only the Git repo or base image can miss vulnerabilities added later and can show false positives that are fixed during the image build. Looking at the built image gives you an accurate picture because it represents the artifact that will be deployed and run.

During the recent log4shell CVE disclosures, we helped our users quickly determine which projects were vulnerable to the log4shell CVEs, and exactly how the vulnerable version of log4j was brought in — whether in the base image used, package adds/updates in the Dockerfile, or from the codebase in Git. This was possible because we scanned the images in their container registries, indexed the layers of packages and reported where and why the vulnerable version was present.

An example showing public images scanned by Atomist — identifies images where a vulnerable version of log4j was detected
An example showing public images scanned by Atomist — identifies images where a vulnerable version of log4j was detected

Why you might not be doing vulnerability detection or don’t find your current tools helpful

It’s becoming riskier and risker to avoid taking vulnerabilities seriously. It’s not just the really bad zero-days like log4shell that are worrisome, but the ever-increasing usage of open source packages and constantly changing container base images. Yet it’s understandable that many dev teams have not yet addressed the problem of dealing with vulnerabilities.

If you're not doing image vulnerability detection yet,  it might be because:

  1. You're too busy shipping. You just haven't gotten to it yet. You're working on shipping features and know that you need to eventually look at vulnerabilities, but don't have time for it yet or no one has taken the lead.
  2. Too much noise. Scanning can turn up a lot of vulnerabilities, which seem noisy, particularly when scanning entire container images. As a developer, you only want to see what is relevant to your work on the project.
  3. Unclear ownership. Who “owns” fixing a given vulnerability? Modern cloud applications have vulnerable packages that cross the boundaries of base image maintainers, CI/CD and developers. You need to know the provenance of a vulnerable package in order to know who should look at it.
  4. No access. Whether you're a developer writing code that ships as an image but that is downstream of your work, or you simply don't have access to the registry to scan, this can be a blocker.
  5. No process. Your team may be doing vulnerability scanning and you may see some alerts, but don’t have a clear process for how you're supposed to use that information and it may not be part of your workflow.

Thinking differently about vulnerabilities

There are a lot of scanners in the world already. We didn’t set out to build yet another scanner (we use several widely-available scanners). We set out to help people tackle the problems we kept hearing — that filtering out noise, prioritizing the right things to fix and making it work for dev teams were all difficult jobs.

We recently shipped image vulnerability support to address those needs for container vulnerabilities and to make it easier for dev teams to get started. See our free-to-use public image vulnerability database for a taste of how it works. Use it on your own private images by signing up.

Here’s what we do differently.

  • Show how vulnerabilities were brought in
  • Help you choose more secure images for your applications
  • Compare similar projects to get a relative sense of security health

Show how vulnerabilities were brought in

As images are built in layers via various Dockerfile directives like FROM base image or COPY and RUN commands that modify the composition of the image, by interpreting these layers and linking back to the Dockerfile instruction that created it, we help you better understand how a vulnerable package entered the image.

The apt-get update instruction in the example below brings in its own set of vulnerabilities. You can evaluate whether there is a different way to update those packages, whether they are needed at all in your image, or perhaps you need it and this is the least vulnerable version. Seeing the vulnerabilities broken out by layer gives you a better understanding.

Vulnerabilities by image layer, linked to Dockerfile instructions

This also makes it easier to understand who is responsible for addressing it. If it’s a base image vulnerability, perhaps you simply need to rebuild to get the latest base image digest, or consider a different tag of that particular base image, or the maintainer in your organization needs to address it if it’s a private base image.

Help you choose more secure images for your applications

By comparing vulnerabilities across tags, we show you which alternatives may have fewer vulnerabilities than others. If you’re using a given base image tag, this is a good way to compare the one you’re on to others. If you’re starting a new project, this view helps you pick a better starting image.

Compare similar projects to get a relative sense of security health

Use the base image filter to compare similar projects. For example, how do my node projects stack up against each other?  In the example below, I can see that ht-starter has more critical vulnerabilities than atomist-docker-tutorial.

Coupling this with the Base image / Image vulnerabilities toggle filters out vulnerabilities from the base image and lets you see which projects have more vulnerabilities brought in from the “application” and not the base image.

Scan better now

We all know we should be checking our containers for vulnerabilities. At Atomist we aim to make that much more informative, less noisy, and maybe even a little fun 😃 — there, I said it. If you’re ready to try it out on your own images, head on over to https://dso.atomist.com/user/signup to get started.

If you want to see this in action on public images, have a look at our searchable image vulnerability database at https://dso.atomist.com/ — it’s public and you don’t need to sign up to use it.