Network Time Security
How to scan images with ContainerKitty
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.
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.
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:
This data can then be further analysed. However, there are some points to consider when assessing vulnerabilities and scanning in general.
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.
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
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.
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:
When evaluating a vulnerability scanning solution, it is worth comparing and analysing which solution offers the best coverage for the container images used.
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here