Speed up container fixes with Snyk’s new automated parent image detection

Shipping your apps in containers gives you the freedom to build upon the work of others. You can pick from a variety of ready-to-use container images that will run nearly any code or framework you have. Snyk Container already helps users manage their parent images and provide guidance when there are better options available — images with few vulnerabilities, or a smaller footprint overall, or both. We’re excited to announce our latest update to our image management capabilities: automatic base image detection.

Simplified image security workflows

Prior to this release, Snyk Container identified the parent image of your scanned container image by analyzing your Dockerfile at the same time as the container image was tested using the --file=/path/to/Dockerfile option. This is great if you have the Dockerfile readily available, and if you remember to add the Dockerfile as part of the scans. But, let’s face it — adding the Dockerfile is an extra option and it’s quite different from how other image scanners work. We wanted to make our base image management easier and provide base image recommendations the very first time someone scans with Snyk, so we made base image detection automatic! Simply scan your container images with Snyk, and we’ll take care of the rest.

In the example above, I’ve scanned a demo app that runs in a container based on node:10, which is exceedingly old. During the scan, Snyk Container detects the usage of the node:10 parent I’m using and recommends better alternatives that will clear up over 520 of the vulnerabilities in the image I’ve built. Nearly every list of container best practices says to select smaller base images to reduce your attack surface, and when you run a container vulnerability test you quickly see why that’s the case: many vulnerabilities are introduced when bigger or outdated images are used. Often, selecting a newer, slimmer image has the biggest and fastest impact on reducing vulnerabilities. Conversely, trying to address every container vulnerability one-by-one or sift through hundreds of base image options in public repositories is generally not a good use of anybody’s time, so Snyk Container does this work for you for the most popular images on Docker Hub.

In the example below, I’ve scanned another app that uses ruby:2.6-slim as its base image. Unlike my Node image, this image is a decent choice with relatively few vulnerabilities -- or at least it would be if I had built my container image recently. Instead, my image was built roughly 7 months ago. So instead of alternative base images, I’m alerted that my Ruby image is outdated and I should rebuild to fix vulnerabilities. Note that I used the --json option here to show the machine-readable JSON output, for those who like to feed the Snyk results into other tools.

Supporting more container build options

There’s another reason automatic detection of base images is important: there are a growing number of container tools that do not use a Dockerfile to build containers. Thankfully, the Open Container Initiative(OCI) container image standards are widely adopted by these tools which means your container tools and runtimes should be able to run these containers. Tools like Jib, Buildah and Cloud Native Buildpacks all provide means of creating OCI-compliant containers without writing a Dockerfile.

Snyk Container was always able to scan these containers and now, with our automatic base image detection capabilities, we can provide base image guidance for these alternative build workflows. We’ll be publishing blogs on Jib and Cloud Native Buildpacks in the coming weeks, but if you can’t wait, simply build a container with your tool of choice and scan it!

How base image detection works

With this feature we now have two methods of detecting your containers’ base image and providing recommendations:

1. Inspect the Dockerfile during the scan: If you’re already using this method, it still works and you can continue using it. Snyk Container will work as it always has. We’ll use the Dockerfile as the source to derive the base image details instead of the auto detection method.

2. Inspect the image layers: By analyzing the layers in an image when we scan it we can determine which base image is in use. Snyk Container analyzes the most popular Docker official images published on Docker Hub and we track the layer data for those images so we can match your scanned image layers against those records.

Today we focus on the most popular official images published on Docker Hub. This includes base images that are just a Linux distribution like Debian, Alpine, and Ubuntu; images with language and framework packages built-in like Python, Node, or OpenJDK; and images with pre-built app components like NGINX, WordPress, Mongo, and MySQL. There are far more images and we continue to add to the list so if you have something you’d like us to cover, let us know!

Why you should still scan your Dockerfile

It might seem like you could skip scanning the Dockerfile, now that Snyk Container automatically detects base images. However, there are still good reasons to include the Dockerfile (if you’re using one) in your secure development practices:

1. Early warning: If you import Git repos to Snyk, one of the things we look for is a Dockerfile. We do this to provide the earliest possible alert that there might be a better base image you can use. Plus, because we’re integrated with your source repos, we can even automate the base image fixes through pull requests.

2. Provenance: When you use Snyk Container to scan both the Dockerfile and the container images created from it, you can link those results. This is useful for tracing where images are coming from in your environment and for connecting your running production containers back to their source.

3. Completeness: Scanning the Dockerfile from Git provides early warning about base image selection, but it’s limited to only providing base image recommendations. This is because any image built from that Dockerfile will vary based on when the image is built, since Linux packages and base images are updated frequently. The Dockerfile alone can’t tell you what actually exists in an image you’ve already built. Plus, the Dockerfile is often stored alongside the code that’s running in the container so there’s additional context gained by seeing vulnerabilities and code issues at the same time as the container issues.

By scanning both the Dockerfile and the images, you get the full picture of vulnerabilities, whether they’re from your base image or other layers of the image plus the ability to go straight to the source file and quickly make fixes.

How to get started

If you’d like to see Snyk base image detection capabilities and guidance for yourself it’s easy to get started and it works for users on all plans, including our Free plan. Simply build an image on top of one of Docker’s popular official base images and scan it with Snyk Container. As long as you’re using version 1.677 or later of the Snyk CLI you should get automatic base image recommendations. You can also scan images in your CI/CD pipelines and container registries, or, if you’re on a Snyk Business or Enterprise plan, you can scan your running containers in your Kubernetes clusters and all will provide the same base image detection and guidance.