ECR .NET Core Clair

Docker image vulnerabilities in .NET Core

AWS ECR recently rolled out a new feature called Scan on push which makes it very easy to scan for docker image vulnerabilities once your images are pushed to an ECR repository. The results of those using .NET Core docker images might be very surprising, or not?! :)

TL;DR;

Use Alpine docker images for .NET Core, these are the only ones vulnerability-free for any .NET Core version.

ECR Scan on push

In this announcement AWS introduced Scan on push feature to perform security analysis to find docker image vulnerabilities in the images you push to ECR. There is also On-demand scan option. AWS use Clair to search for known vulnerabilities and point you to the right CVE. This helps to address security issues in your images.

The exercise

To explore the feature better, and test the images provided by Microsoft, I’ve created a little exercise containing the following .NET Core docker images for Linux using the latest available SDK/Runtime and OS versions:

.NET Core 2.1
Debian 9 (default)
Ubuntu 18.04
Alpine 3.10

.NET Core 2.2
Debian 9 (default)
Ubuntu 18.04
Alpine 3.10

.NET Core 3.0
Debian 10 (default)
Ubuntu 19.04
Alpine 3.10

.NET Core 3.1 (released 3/12)
Debian 10 (default)
Ubuntu 18.04
Alpine 3.10

Even though a console app could run using .NET Core runtime only, however for the sake of the exercise I am using aspnet runtime. Web APIs seem to be more common to use.

Running the exercise app

Source code of the exercise available on my GitHub here.

ECR Scan on push feature enabled

I’ve created an ECR repo with Scan on push flag enabled and used AWS profile for authentication in AWS CLI. To set environment variables (region, profile, ecr repo url) you can use the following CMD:

setx AWS_REGION "eu-west-1"
setx AWS_PROFILE "your-profile"
setx ECS_REPOSITORY "111111111111.dkr.ecr.eu-west-1.amazonaws.com/scan-on-push-dotnet-vulns-testing"

If you are having issues setting up environment variables or configuring AWS authentication, this blog post might help.

And to run the exercise app I was using cake build script:

powershell -ExecutionPolicy ByPass -File build.ps1 -target="Build"

The cake build script builds, tags, and pushes docker images to an ECR. After running the script, I had 12 docker images pushed to ECR, and scanned for vulnerabilities.

Docker image vulnerabilities

The matrix table below indicates what vulnerabilities have been found for each .NET Core version in different Linux distributions.

Alpine 3.10Debian 9Debian 10Ubuntu 18.04Ubuntu 19.04
.NET Core 2.1H: 8
M: 5
n/a H: 0
M: 9
n/a
.NET Core 2.2 H: 8
M: 5
n/a H: 0
M: 9
n/a
.NET Core 3.0 n/a H: 2
M: 5
n/a H: 0
M: 7
.NET Core 3.1 n/aH: 2
M: 5
H: 0
M: 9
n/a

The table above uses following marks:

  • ✔ – no vulnerabilities found at all.
  • H – number of high severity vulnerabilities
  • M – number of medium severity vulnerabilities
  • n/a – distribution version is not available for .NET Core version as of writing this blog post.e

Key points to summarize the table:

  1. Only Alpine version didn’t have any vulnerabilities in all versions of .NET Core docker images.
  2. Ubuntu had only medium severity vulnerabilities, however 19.04 version which is newer and slightly more secure is only available in .NET Core 3.0
  3. The default docker image OS is Debian which has high severity vulnerabilities in all the .NET Core versions.
Docker image vulnerabilities - .NET Core 3.1 Debian 10
The latest .NET Core 3.1 Debian 10 image has 2 high severity vulnerabilities

Any easy fix?

IMPORTANT. Easy option to keep your apps secure is to use Alpine docker images, this has a nice side effect of smaller image size also. If you need features provided by Ubuntu/Debian you could consider either installing additional packages into your Alpine image during the build, or manually addressing security issues in your Ubuntu/Debian images.

Conclusions

The official Microsoft docker images are used by millions of the users around the world, and it’s really surprising that security vulnerabilities in the images haven’t been addressed already. If Microsoft keeps similar approach going forward, I wonder if we can be sure to keep having Alpine images free of known vulnerabilities? :)