Secure your Container with Docker Desktop Tools

Now that our Images are in Docker Hub, and we know they contain vulnerabilities, we can use the Docker CLI to scan the images with Snyk and bring that vulnerability count down.

Step 1: Scan your Image for vulnerabilities with Snyk

Use docker scan to scan for vulnerabilities. It's a best practice to pass the Dockerfile used to build the image with --file to get more robust results that include vulnerabilities from Dockerfile instruction and base image upgrade guidance.

# Scan the docker-goof image and passing the Dockerfile
docker scan $DockerId/docker-goof --file=Dockerfile

Check out the Docker Scan documentation for all possible CLI options.

When finished, results are displayed in the Terminal, along with remediation guidance.

Step 2: Review Vulnerability Scan Results

Vulnerabilities are broken up into sections, based on how they were introduced:

Vulnerable Base Image Packages

Vulnerabilities introduced by the container's base image can be identified by the presence of the Introduced by your base image line. (Line 9 below)

✗ High severity vulnerability found in curl/libcurl3
Description: Buffer Overflow
Introduced through: curl@7.38.0-4+deb8u11, curl/libcurl4-openssl-dev@7.38.0-4+deb8u11, git@1:2.1.4-2.1+deb8u6
From: curl@7.38.0-4+deb8u11 > curl/libcurl3@7.38.0-4+deb8u11
From: curl/libcurl4-openssl-dev@7.38.0-4+deb8u11 > curl/libcurl3@7.38.0-4+deb8u11
From: curl@7.38.0-4+deb8u11
and 2 more...
Introduced by your base image (node:10.4.0)
Fixed in: 7.38.0-4+deb8u16

User Instruction Vulnerabilities

Some vulnerabilities are introduced by User Instruction in the Dockerfile. Snyk highlights the command that introduced the vulnerability, with the Introduced in your Dockerfile by line. (Line 9)

✗ High severity vulnerability found in bzip2/bzip2
Description: Out-of-bounds Write
Introduced through: bzip2/bzip2@1.0.6-7+b3, dpkg/dpkg-dev@1.17.27, bzip2/libbz2-dev@1.0.6-7+b3, imagemagick/libmagickcore-dev@8:, meta-common-packages@meta
From: bzip2/bzip2@1.0.6-7+b3
From: dpkg/dpkg-dev@1.17.27 > bzip2/bzip2@1.0.6-7+b3
From: bzip2/libbz2-dev@1.0.6-7+b3
and 2 more...
Introduced in your Dockerfile by 'RUN apt-get install -y imagemagick'
Fixed in: 1.0.6-7+deb8u1

Vulnerable App Dependencies

The last kind of vulnerability your images might contain are introduced by your application dependencies. Snyk highlights the package manifest Target File that introduced it. (Line 14)

Issues to fix by upgrading:
Upgrade @tryghost/members-api@0.8.2 to @tryghost/members-api@0.24.1 to fix
✗ Remote Code Execution (RCE) [Medium Severity][] in bunyan@1.8.12
introduced by ghost-ignition@3.1.0 > bunyan@1.8.12 and 8 other path(s)
Upgrade @tryghost/members-ssr@0.7.1 to @tryghost/members-ssr@0.8.3 to fix
✗ Remote Code Execution (RCE) [Medium Severity][] in bunyan@1.8.12
introduced by ghost-ignition@3.1.0 > bunyan@1.8.12 and 8 other path(s)
Organization: demo-inc
Package manager: yarn
Target file: /var/lib/ghost/versions/2.37.2/package.json
Project name: ghost
Docker image: docker-goof-app

Step 3: Review Base Image Recommendations

Snyk's remediation guidance helps developers spend less time remediating, and more time developing! One way to tackle vulnerabilities is by choosing a more secure base image. By providing the Dockerfile to docker scan , Snyk can suggest other Base Images that can be used in the Dockerfile's FROM statement to bring down those vulnerability counts.

These are grouped by how likely they are to be compatible with your application:

  • Minor upgrades are the most likely to be compatible with little work,

  • Major upgrades can introduce breaking changes depending on image usage,

  • Alternative architecture images are shown for more technical users to investigate.

These suggestions are not a substitute for proper integration testing. They are intended to help you narrow down potential base image choices.

Organization: demo-inc
Package manager: deb
Target file: Dockerfile
Project name: docker-image|$DockerId/docker-goof
Docker image: $DockerId/docker-goof
Base image: node:10.4.0
Licenses: enabled
Tested 382 dependencies for known issues, found 459 issues.
Base Image Vulnerabilities Severity
node:10.4.0 951 451 high, 480 medium, 20 low
Recommendations for base image upgrade:
Minor upgrades
Base Image Vulnerabilities Severity
node:10.22 498 53 high, 48 medium, 397 low
Major upgrades
Base Image Vulnerabilities Severity
node:14.13 497 53 high, 47 medium, 397 low
Alternative image types
Base Image Vulnerabilities Severity
node:14.13-buster-slim 51 9 high, 4 medium, 38 low
node:14.12.0-slim 70 17 high, 7 medium, 46 low
node:14.11.0-stretch-slim 70 17 high, 7 medium, 46 low
node:14.13.1-buster 254 31 high, 30 medium, 193 low

Step 4: Apply a more Secure Base Image

Let's choose a more secure base image for docker-goof. We'll do this by applying the Minor upgrade recommended by Snyk. Change the FROM statement in the Dockerfile:

# Comment out the old FROM Statement
# FROM node:10.4.0
# Write in the new one
FROM node:10.22
RUN apt-get install -y imagemagick

Now build the new Image, and push it to Docker Hub. To see results side-by-side with the previous scan, we'll specify a different tag when building the image.

docker build -t $DockerId/docker-goof:v2 -f Dockerfile .

Step 5: Log in to Docker Hub to see the new results

Once pushed, you can see the results in Docker Hub. The base image we used in our v2 tag has significantly reduced the number of vulnerabilities present in docker-goof!

Continue this cycle of build-scan-push until you're running the most secure base image.

Recap and Next Steps

We hope you enjoyed this Lab! Applying a more secure base image is a great first step toward making your images more secure. As noted above, vulnerabilities can come from your application dependencies and Dockerfile user instructions as well.

Check out the other courses in the Snyk Academy to learn how Snyk helps you fix those vulnerabilities and further reduce the vulnerability counts for your images in Docker Hub.

As we continue to evolve our Partnership with Docker, we'll keep adding new capabilities that help developers build their container images securely and deploy with confidence. Try out this workflow on your own applications, and let us know what you think!