Containers have grown increasingly popular in the software engineering world in recent years, and for good reason. They’ve given developers the ability to quickly and easily build and deploy software applications — while consuming minimal computing resources and allowing for the separation of processes.

Container images play an integral role in the container ecosystem. Container images are read-only software packages that have everything an application needs to run. They are comprised of multiple files that include things like dependencies, application code, system libraries, and settings. (The container itself is essentially a running instance of the container image.)

Unfortunately, containers and container images have also attracted quite a bit of attention from cybercriminals. For example, a recent report revealed that over two million container images hosted on the Docker Hub repository are afflicted with at least one critical vulnerability.

In this post, we'll explore today’s container image security landscape along with strategies organizations can use to fend off cyber threats, such as container vulnerability scanning and the use of digital signatures.

An Overview of Container Images

Container images consist of a series of layers. There’s the parent (or base) image, which serves as the foundation for all other layers of the image. Ubuntu, Alpine, Linux, and BusyBox are a few examples of commonly used base images. The next layer might be a package like MySQL, and so on.

The relationship between container image layers is also worth highlighting. Each layer depends on the layer immediately beneath it, which is why it’s recommended to place the layers that change most frequently toward the top of the stack. (Otherwise, a lot of development time may go into rebuilding the image.)

Container images come in all different flavors. Categories range from analytics (i.e. the Sematext Agent, which provides “real-time performance tracking and visualization of your infrastructure and application metrics”) to DevOps tools (i.e. Jenkins) and plenty in between.

Developers can build their own container image, or they can pull them from a public registry a la Docker Hub.

Finally, a quick note on the popularity of containers and container images. Gartner predicts that over 75% of global organizations will be running containerized applications in production by 2022, and that approaching 15% of enterprise applications will run in a container environment by 2024.

The Container Image Security Landscape

Unfortunately, cybercriminals have taken notice of the widespread use of containers, targeting them with a variety of attacks. For the purposes of this blog, however, we’ll focus narrowly on threats related to container images themselves.

Here are a few of the bigger reasons why container image security is a challenge for organizations today.

  • It’s not uncommon for container images to be quite large. Overstuffed images aren’t necessarily a security problem on their own, but images with a large volume of files (libraries, tools, agents, settings, etc) can complicate efforts to conduct thorough vulnerability scanning and maintain proper configuration.
  • Even container images hosted on well-known and trusted registries are susceptible to vulnerabilities. For example, a recent analysis of 4 million Docker Hub images revealed that a staggering 51% had exploitable vulnerabilities. There’s also been a widespread problem with cryptojacking; it’s estimated that users have downloaded malicious cryptomining images on Docker Hub north of 20 million times.
  • Bad actors have targeted public registries with an attack known as image-squatting. This is a spin on typo-squatting, where cybercriminals target users who input incorrect URLs into their web browsers. In the case of image squatting, bad actors upload malicious images with names that are very similar to legitimate images.
  • There’s been a significant spike in the volume of attacks targeting the container environment. A new report revealed a 600% increase in attacks in the second half of 2020 compared to the second half of 2019, with image-squatting and credential stuffing fueling the rise.
  • Given that container technology is still in its (relative) infant stages, some organizations may lack clear control measures in place around the use of images. These include processes for confirming image authenticity, modifying images, and approved lists of container registries.

Container Vulnerability Scanning: A Security Best Practice

Because containers are built from images and each image can either be fully downloaded from a remote source or can at least contain open source components, it's essential to have routine inspections of every new image that's deployed. Otherwise, it’s hard to be confident that the third-party code doesn't contain security vulnerabilities.

The best way to do this is to use a scanning tool that will inspect every new image for possible security issues against an up-to-date database such as NVD. It’s also wise to select a tool that’s backed by a dedicated research team, which can help ensure the vulnerability database is as comprehensive and accurate as possible.

Container vulnerability scanning works by analyzing a container image and producing a report that includes:

  • Basic component metadata, such as component name, version, package manager, and description
  • Known vulnerabilities associated with the component

For example, here is what a container vulnerability scanning report might look like.

Keeping with the shift-left security ethos, it’s best to scan all image layers (and built images) as early as possible in the software development lifecycle. In practical terms, this generally means:

  • Scanning any images from public registries as soon as you download them
  • Scanning fully built images as part of the CI/CD pipeline

Organizations that use containers extensively may also want to create their own internal registry of pre-approved base images that's already been scanned and vetted. Base images tend to come from external registries, but companies may not want their developers to download them ad-hoc for security reasons. (It’s worth noting, however, that organizations should consider periodically re-scanning images in these pre-vetted registries. Vulnerabilities are frequently found and added after the release of a specific image, so it makes a lot of sense to rescan images.)

From there, they can have their developers scan their built images as part of CI/CD to capture vulnerabilities that may be introduced by their own development process.

If you have found vulnerabilities following an image scan, there are several ways to mitigate or at least reduce the risk.

  • Check if upgrading to a newer version helps mitigate the issue. Sometimes security issues are fixed in newer versions.
  • Use details like severity/score to determine the threat posed by the vulnerability and make plans to address it based on your ideal security posture.
  • Uninstall or otherwise delete the affected component if it's unused.

Another benefit of container scanning is that it can help inform a comprehensive software bill of materials — something that’s traditionally been a challenge for advanced container users.

Other Strategies for Container Image Security

Implementing container vulnerability scanning is an important part of the container image security toolkit, but it’s not the only effective strategy.

Apply Control Measures

It’s helpful to adopt an organization-wide policy around the acquisition, maintenance, and use of container images. Policies may govern areas like version control (i.e. using image tags), approved registries, the modification of images, and more. They also might cover hardening methods like:

  • Avoiding running containers as root
  • Using Apparmor
  • Allocating minimum viable resources to docker or a container

Keep Base Images Minimalistic

If and where possible, it’s helpful for our base image to be as small as possible and contain only what we need for our application code. For instance, if we need to use Python for our app code, we can choose between those two images (among others):

Python (886 MB) | Python:slim-buster (115 MB)

If we choose the smaller one, it uses less code, has fewer dependencies, and hence has a smaller attack surface. Likewise, we can minimize the amount and use the slim version of middleware: i.e., frameworks (let’s say Django/Flask) and OS tools (pip, easy_install).

Use Signatures to Improve Container Image Security

Finally, our discussion of container image security wouldn’t be complete without mentioning image signing and verification. This gives development and security teams the ability to confirm that the image comes from a trusted source and hasn’t been unexpectedly modified. The way the container ecosystem operates — where many images are open sourced and stored in public registries — places additional emphasis on the trust factor.

Different container platforms have different approaches to image signing, but, generally, they are based on the concept of a digital signature. There’s a private key (used by the image builder) and a public key (for the image user to confirm its authenticity).

For example, Docker Content Trust (DCT) users can get trust data on the Alpine image by entering the following command

$ docker trust inspect alpine:latest

This query produces results that include whether the image is signed, name of the signers, and a list of keys.

A related note: Docker has built in several badges that enable users to learn more about the authenticity of some of the more popular images. These include “Verified Publisher” (i.e. the image is published and maintained by a commercial organization) and “Official Images” (which Docker describes as “a curated set of Docker open source and "drop-in" solution repositories.”)

Container Image Security: The Bottom Line

Containers are the current industry standard in packaging, deploying, and running software code. They’ve helped transform application deployment, improving speed, scalability, and portability. However, containers come with potential vulnerabilities as well.

The cornerstone of securing containers is securing the container image. And, this can be best accomplished by integrating an image scanning tool like FOSSA into your CI/CD pipeline. Container vulnerability scanning tools help organizations by identifying dependencies and vulnerabilities in container images — and then providing actionable guidance to support remediation of any issues.

For more information on how FOSSA can help your organization identify and remediate container image vulnerabilities, get in touch with our team today.