Image security scanning in Azure Container Registry

I was chatting with a customer last week about the Azure Container Registry. One of the questions that came up was image scanning. There is an integration between the Azure Container Registry and Azure Defender that will perform image scanning.

The goal of this blog post is to explore these capabilities and have a look at what this looks like in practice.

Why is image scanning important?

Container image scanning is important since the container image will form the basis of all running containers. If the image itself contains a vulnerability, then all running instances of that container will contain that vulnerability.

Azure Defender includes an option to scan images in an Azure container registry. Azure Defender uses Qualys under the covers to perform the scans. Once vulnerabilities are detected, you’ll get notified in the security center dashboard (with the ability to trigger automation via Logic Apps as well) and the score is included in your Azure secure score.

Images are scanned upon push, weekly (if they were used in the last 30 days) and on import (from an external registry). The pricing for Azure Defender for ACR is not based on scans, but is based on the amount of images in the resistry.

An important limitation right now is that Azure Defender can only scan container registries with public internet access, it doesn’t support registries deployed with a registry firewall or private endpoint.

Let’s have a look at what this looks like:

Enabling Azure Defender for Azure Container Registry

I have a persistent container registry in Azure called nfacr, that contains a number of images already. To enable defender for ACR for it, you need to go to the Azure Security Center, and configure ACR scanning, as shown in the image below:

As I enabled this functionality, it took a couple minutes before my images were getting scanned. I could see my container registry appear under the section on “Unverified registries” in the security center:

To trigger an additional scan, I decided to import an image from Docker Hub. As a candidate, I selected the Bellhop Engine (if you don’t know what Bellhop is, check out the GitHub repo as well as the Azure podcast episode about it).

az acr import \
  --name nfacr \
  --source docker.io/azurebellhop/engine:v0.4 \
  --image azurebellhop/engine:v0.4

Once the import finished, I could quickly see the image being scanned in Azure Security Center:

The scan finished in a matter of about a minute, and as I totally expected, there were three issues with the image:

The first one apparently isn’t fixable. There was no remediation mentioned for this security issue.

The second issue actually contained remediation steps. Check more details below:

I believe an extra step in the Dockerfile apt upgrade openssl might help resolve this issue. This will also help resolve the last alert, which is also related to openSSL:

Let’s try fixing these issues:

Fixing the findings

Fixing the two issues with remediation was relatively straightforward. It meant included two additional steps in the Dockerfile:

RUN apt update
RUN apt upgrade openssl bash -y

I added that to the Dockerfile and pushed a new image. Once this image was scanned, this resolved those two issues.

The bash issue didn’t have a fix. To avoid the ever-present alert for this alert, you can (optionally) in Azure Defender disable this finding. The screenshot below shows how you can disable certain rules:

It takes up to 30 minutes for this disabling to propagate. But this way, you have fewer false positives.

Summary

In this post we had a quick look at Azure Defender for Azure Container Registry. We explored how it scans images, and how it provides you with recommendations to improve your security posture.

Scanning container images is important. Since every running container will start from a container image, if the image contains security vulnerabilities,