Member-only story
Scan Your Docker Images for Vulnerabilities
How to find security vulnerabilities before it’s too late
So you’ve crafted a Dockerfile, tested your container in your development workstation, and you’re waiting for the CI/CD to pick it up. Eventually, pre-prod is updated, integration tests passed and functional testers give the green-light. Is it now time to roll-out to prod? Not so fast.
Docker Image Layers Inheritance
Each batch of files added to an image end up creating a layer that is added to the image. Your Docker image is the concatenation of all these layers in the specific order in which they’ve originally been created.
The same principle applies when you create an image inheriting a parent image using the FROM directive in your Dockerfile. Your final image will include all the layers of your parent image, augmented with the layers you’ve created yourself.
What if you use a parent image that also uses another parent image, that may also use another parent image, that finally uses a base image like Ubuntu or Alpine? I guess you see where this is going: You end up inheriting multiple layers of content (i.e. files and executables) from upstream images that you have never seen (let alone controlled) yourself.
What if a security vulnerability is included in any of these upstream layers? We’ll look next at how to detect these. But first, what exactly is a security vulnerability?
Security Vulnerabilities
As you can see on the top-left part of the above figure (openjdk:8-jre image), there are multiple layers. On the right part, you can also visualise the files included in that image, courtesy of the Dive¹ tool. Many of those files are executables and, as with all source code we write, susceptible to security issues and vulnerabilities.
If those were files in your local filesystem you’d probably run a virus scan and, by all means, do so when feasible. In a broader sense, a virus could be regarded as a security vulnerability itself. However, a computer…
