The use of containers for applications and services has a number of advantages. For example, containers are portable, can be built on a system and deployed to servers and cloud systems. Containers are lightweight compared to virtual machines (VM) because they share the host kernel and do not have their own guest operating system. A container is a runtime instance of an image. Several containers can be deployed at the same time on several platforms from one image. An image contains the code of the application(s), tools and libraries as well as the configuration and environment variables. An image should only contain the components that are needed to run the application.

The same security requirements apply to container images as to virtual machines and physical systems. Therefore, vulnerability and patch management processes should also include images. There is a risk that an image is created once, shared many times but never maintained again. When using a container registry, it should be carefully managed who is allowed to upload images in which environment. While the development environment may be open, the test and production environment should be managed restrictively. The versioning by tags of the images also plays an vital role.

In this article we discuss the scan of container images. There are many solutions, including Anchore, JFrog Xray, OpenSCAP, or Docker Scan. We have developed the script Invoke-ContainerKitty, which orchestrates scans of images based on Docker Scan.

ContainerKitty

Manual scanning of many container images is repetitive and not efficient. We have developed ContainerKitty to automate image scanning and simplify the process. No server infrastructure is required for ContainerKitty, the script can be used on any Windows system with Docker. ContainerKitty is publicly available in our GitHub Repository.

The script builds a list of container images from a GitLab repository. It is also possible to use a list from another source. This list should contain one image per line, for example registry.example.com/dev/example-image:4.2.0. ContainerKitty fetches the images from the registry into the local Docker instance and then runs the scan. The results are saved as a JSON file per image. The report function parses all JSON files and provides a summary as well as a CSV file for further processing. All steps can be logged if required.

Docker Desktop for Windows is necessary for using Container Kitty. A Docker ID must be registered for scaning images. Docker Scan uses the free version of the vulnerability database snyk.io. The free version allows 100 container scans per month.

ContainerKitty in Action

Docker and ContainerKitty can be run without administrator rights. The requirement for Docker is that the user belongs to the local group docker-users. Before ContainerKitty is used for the first time, the PowerShell session must be authenticated with Docker. After installing Docker, the scan engine should also be registered with snyk.io. Now, ContainerKitty can be used:

PS C:\> docker login
PS C:\> docker scan --login --token SNYK_AUTH_TOKEN
PS C:\> Import-Module -Force .\Invoke-ContainerKitty.ps1

The modules of ContainerKitty can be combined with each other. In the following example, ContainerKitty creates a list of all images of the user with the ID 5 from GitLab and then pulls the images from the registry into the local Docker instance. Afterwards, it scans the images and analyses the results:

PS C:\> Invoke-ContainerKitty -BuildList https://gitlab.example.org -BuildId 5 -BuildIdType User -Scan -Report -ReportDirectory .\reports\ -Log

      =^._.^=
     _(      )/  ContainerKitty 0.2.0-1623130424

[*] 6/8/2021 7:32:51 AM - Starting ContainerKitty
[*] 6/8/2021 7:32:51 AM - Start API calls
[*] 6/8/2021 7:32:51 AM - ContainerKitty needs a private token to build the container list. This token will not be stored.
[$] 6/8/2021 7:32:56 AM - List of container images is finished: .\containerkitty_container_list-20210608-0732.txt
[*] 6/8/2021 7:32:56 AM - API calls done
[*] 6/8/2021 7:32:56 AM - Start pulling container image ubuntu:xenial-20210429
...
[$] 6/8/2021 7:32:58 AM - Pulling container image ubuntu:xenial-20210429 done
[*] 6/8/2021 7:32:58 AM - Start scanning container image ubuntu:xenial-20210429
[*] 6/8/2021 7:34:11 AM - Scanning container image ubuntu:xenial-20210429 done
[*] 6/8/2021 7:34:11 AM - Start creating the report .\containerkitty_report-20210608-0734.csv
[!] 6/8/2021 7:34:14 AM - docker-image|ubuntu (Tag: xenial-20210429): 368 vulnerable dependency paths / Unique count: 47
[*] 6/8/2021 7:34:28 AM - Creating report .\containerkitty_report-20210608-0734.csv done
[*] 6/8/2021 7:34:28 AM - ContainerKitty is done

Each module can also be run individually. Thus, a scan can be started directly by providing ContainerKitty a manually created list of images. It is also possible to only run an analysis on JSON files created by Docker Scan. The report creates a CSV file with the following information:

• Id and Id Snyk
• Image and version (tag)
• Affected package and its version
• Vulnerability title
• Description of the vulnerability
• Countermeasure and statement whether an upgrade/patch is available
• CVSS score and specification according to CVSSv3.1
• References

This data can then be further analysed. However, there are some points to consider when assessing vulnerabilities and scanning in general.

The Challenge of Vulnerability Scanning

There are a few challenges to be addressed before a vulnerability scan should be performed on a regular basis. This starts with the management of images, the evaluation of the scanning solution and the risk classification of the identified vulnerabilities.

Versioning

Even before a vulnerability scan is performed, the first challenge is: Which images will be scanned? It must be defined whether all existing images or only the current version should be scanned. A versioning concept is essential, for example semantic versioning. All projects should follow the same scheme and the current version should be easily identified. If no version is specified, Docker Scan uses the tag latest.

Manual Package Installation

Most scanners use the image’s package manager to determine the installed packages and their version. This means that manually installed applications can be missed in a scan. There is no easy solution to this issue. When creating images, it is important to ensure that only the package manager is used and that exceptions are documented.

Vulnerability Database

Scan results differ depending on the vulnerability database. An essential point is the link between a vulnerability in a package and the version of the corresponding Linux distribution. If this mapping has not been done, the vulnerability scanner will not be able to correctly map a vulnerability. Since Docker Scan uses the free version of snyk.io, we manually examined the scan results and found some gaps:

• The vulnerability CVE-2021-3541 in libxml, which exists in the free database of snyk.io but has not been linked to Alpine Linux. Therefore, this vulnerability is not identified during a scan of an Alpine image.
• The vulnerability CVE-2021-24032 in libzstd, which also exists in the free database pf snyk.io but has no mapping to Red Hat Linux. Therefore, this vulnerability is not detected in a Red Hat image.

When evaluating a vulnerability scanning solution, it is worth comparing and analysing which solution offers the best coverage for the container images used.

Risk Assessment

Images often have a high number of vulnerabilities. These vulnerabilities were classified by a severity level. As Tomaso Vasella pointed out in the article Severity and Risks , the severity level should not be assumed as risk without further analysis. In the risk assessment, attention should focus on whether the vulnerability can be exploited (remotely) and whether an affected function in a library or package is used in the application. This must be analysed and coordinated with those responsible for the image and the containers.

Conclusion

Containers offer advantages over traditional methods such as virtual or physical machines. However, the security requirements remain and can be addressed with well-known concepts and methods.

We have developed a publicly available solution for automated image scanning that can be easily used on a Windows system to efficiently scan many images. We welcome feedback and suggestions for improving ContainerKitty.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://anchore.com/opensource/
• https://docs.docker.com/docker-for-windows/install/
• https://docs.docker.com/engine/scan/
• https://github.com/scipag/ContainerKitty
• https://hub.docker.com/
• https://jfrog.com/xray/
• https://semver.org/
• https://snyk.io/
• https://snyk.io/vuln/search?q=CVE-2021-24032&type=any
• https://snyk.io/vuln/search?q=CVE-2021-3541&type=any
• https://vuldb.com/?id.170727
• https://vuldb.com/?id.175254
• https://www.alpinelinux.org/
• https://www.redhat.com
• https://www.redhat.com/sysadmin/container-vulnerabilities-openscap