In today’s blog we take a deep dive into a new capability in Twistlock 2.3 – per layer vulnerability analysis. I will start with a brief overview of Docker layering to highlight the value and risk of Docker layers. We will then explore this unique new 2.3 feature, showing you just how easy it is to discover, explore, and remediate vulnerabilities in your layered Docker images.

One of the things I love about our technology is just how easy it is to set up and utilize the Twistlock solution to mitigate risks across your entire Enterprise development operations, and this new feature is no exception.

Docker layered architecture

Docker containers are building blocks for applications. Each container is an image with a readable/writeable layer on top of a bunch of read-only layers. These layers, also called intermediate images, are generated when the commands in the Dockerfile are executed during the Docker image build. This layered approach is a mecca for reuse as each layer can be utilized by an unlimited number of containers – but what about risk?

If there is a vulnerability within a Docker layer, risk may be duplicated across an unlimited number of containers greatly increasing the attack surface caused by just one vulnerability. In addition, having information about what risk is added by each layer makes it much easier to remediate your custom image changes while providing unique insight into your base images as well.

With Docker layers, you magnify the goodness and the badness, and consequently layered vulnerability analysis is key to mitigating and remediating these expanded risks!

A layered-based view of vulnerabilities

Twistlock has always had a world class vulnerability scan for Docker images: the fastest, most comprehensive, and accurate scan available. With the advent of our newest release, Twistlock 2.3, Twistlock scans now include per layer vulnerability analysis.

For example, a developer adds a new package to an existing image in the latest sprint. Did they introduce new risks with that newly added package? Twistlock makes it easy to confirm and remediate issues from that new modification and stop those risks from being replicated in many other containers.

A real-world example

The Twistlock Platform is architected for automation and scale including auto detecting and scanning of images for all running containers and for all connected repositories. The great thing about this new feature is that you don’t have to lift a finger to enable it, all of the automated and any manual scans include per layer vulnerability analysis.

Consider the following Dockerfile:

############################################################
# Dockerfile for EnterpriseWebApp running on Tomcat
############################################################
FROM tomcat:8.5.15-jre8
MAINTAINER Matthew Barker, matthew@twistlock.com
# Update the Debian OS
RUN apt-get update
# Install openssh server
RUN apt-get install -y openssh-server
# Statically deploy the application war file
ADD package/target/WebApp-5.4.war /usr/local/tomcat/webapps

The Dockerfile uses a tomcat base image, updates it, installs openssh-server, and deploys a war-based application package to the web-server.

If you build this image and launch the container on a server protected by Twistlock, Twistlock will automatically scan the image and provide a full vulnerability report:

As you can see, there are 103 vulnerabilities of varying criticality in this image, but what layers contributed to these vulnerabilities?

One needs only click on the scan report line to bring up a detailed view of the image vulnerability scan – then select the “Layers” tab.

From this view, you can see the layers and vulnerability counts for the layers in the base image, tomcat:8.5.15-jre8. If you scroll down to the bottom of the layer view, you can see the layers your developer added in your Dockerfile and a breakdown of vulnerabilities by criticality.

By leveraging this new capability, you can easily see that the latest version of openssh-server contains fourteen vulnerabilities with nineteen vulnerabilities in the application war file, three of which are critical based on the dark red color.

If you are interested in details for these vulnerabilities, simply click the ‘+’ button next to the layer of interest to see the specific version of each component in the package and the component CVE’s; each CVE citation is also clickable so you can easily research any CVE’s of interest.

Our CVE data always includes combined vendor/package specific information; so if a fix is available from the vendor, that will be shown in the clickable CVE section as you can see below. For CVE-2016-8858, the vulnerability applies to all version of 6.X and all version of 7.X up to 7.3, information we get directly from our debian feed – what I would call the “authoritative” source for this CVE when openssh-server is deployed in a debian image.

Conclusion

Twistlock’s layered-based view of vulnerabilities gives you a unique break down of your docker images by giving you a view of all the layers and the CVE’s at each layer in your base image, as well as the same information for the layers added by your developers.

We make it easy to see the risk added by each line in your Dockerfile and, by including package/vendor specific CVE data, we give you the most accurate assessment of the CVE and remediation when available.

If you are interested in seeing this unique capability in your own Docker based applications, request a free trial of the Twistlock solution here.

← Back to All Posts Next Post →