Tigera Logo

Guides: Container Security Scanning

What Is Container Security Scanning?

Container security scanning is the automated process of analyzing container images, configurations, and running containers to detect vulnerabilities, malware, exposed secrets, and compliance violations. It ensures secure software supply chains by shifting security left into the CI/CD pipeline.

Container images are templates used to create new containers, and an image passes on its vulnerabilities to every container built from it. Cybercriminals can exploit these vulnerabilities to compromise containers and the applications running on them, steal data, or break out of the container to gain control of the host machine. Continuous scanning ensures that bugs and security vulnerabilities are not carried into production, making image security a key part of a DevSecOps environment.

Docker container monitoring complements scanning by continuously observing running containers for anomalous behavior and threats after they reach production.

Container security scanning spans three primary layers:

  • Image scanning: Inspects container layers for outdated OS packages, vulnerable dependencies, and hardcoded API keys or credentials.
  • Configuration scanning: Examines Infrastructure as Code (IaC) templates, Dockerfiles, and Kubernetes manifests to ensure best practices such as least privilege are met.
  • Runtime scanning: Monitors active containers for anomalous processes, suspicious file access, or intrusion attempts during execution.

Scanning is applied across the container lifecycle:

  • Pre-build and build: Inspect the Dockerfile and scan the base image before it is published.
  • Registry: Scan images continuously as they are pushed to or pulled from container registries.
  • Deployment: Automate policy checks so vulnerable deployments are blocked or flagged for remediation.
  • Runtime: Track container behavior and enforce compliance with benchmarks such as CIS and NIST in production.

In this article:

Common Container Vulnerabilities

Here are some of the main types of vulnerabilities affecting containerized systems.

Vulnerabilities in Container Images

A container image is designed to be immutable. Once you build an image, you cannot change its contents. It is very common for images to contain vulnerabilities, due to the use of outdated packages and libraries. Even if an image uses up-to-date software components at the time it is created, inevitably, the image and its components will at some point become out of date, and will be exposed to security vulnerabilities.

A vulnerability scanner can help identify vulnerable images. While the image cannot be updated, you can fix the vulnerabilities and roll out a new version of the image. You can use this updated image to create new containers going forward.

Container Privilege Escalations

A common attack vector is privilege escalation. Attackers attempt to escalate privileges to “break out” of a container and gain control of the root operating system.

Privilege escalation attacks exploit vulnerabilities or defects in the Linux kernel or container runtimes. runC is a low-level container runtime that carries out much of the heavy-duty work for containerd, CRI-O, and Docker. In a recent exploit, a compromised container permitted cybercriminals to overwrite host runC libraries and achieve root access to the host of the container.

In a separate example, the outdated Linux kernel vulnerability CVE-2017-7308 was used to modify the existing process’s namespaces into those of process 1, as well as the host’s namespaces. This was done by requesting a Linux kernel system call, which enabled an escape to the host.

Cryptojacking

Cryptojacking attacks use malicious scripts to steal the computational resources of a device. The goal is to use stolen resources to mine cryptocurrencies. This type of vulnerability can affect a variety of technologies, including containers.

For example, a Docker vulnerability, referenced as CVE-2018-15664, enables attackers to gain root access to the host of a machine, letting attackers use the CPU and GPU resources of the host to mine crypto. It also lets attackers steal sensitive credentials, launch phishing campaigns, and carry out Denial of Service (DoS) attacks.

Malicious container images can provide threat actors with root access to an entire container. Additionally, if a Docker container API endpoint is publicly accessible across the internet without any password protection or security firewalls, it may also be vulnerable to attacks.

Types of Container Security Scanning

Here are several types of container security scanning technologies:

  • Image scanning – Inspects container layers for outdated operating system packages, vulnerable dependencies, and hardcoded API keys or credentials.
  • Configuration scanning – Examines Infrastructure as Code (IaC) templates, Dockerfiles, and Kubernetes manifests to ensure security best practices such as least privilege are met.
  • Runtime scanning – Monitors active containers for anomalous processes, suspicious file access, or intrusion attempts during execution.
  • Network configuration – Scans your Docker image port as well as the network configuration in order to detect issues.
  • Identity and access management – Enables you to prevent containers from gaining complete access to all resources. For example, these tools let you assign specific roles and responsibilities to your Docker containers as well as enforce and monitor predefined roles.
  • User-defined policies – Tools that allow you to define and enforce custom security policies in containers.
  • Open-source tools – Offered for free under a certain license and can often easily integrate with other open-source tools, including frameworks, integrated development environments (IDEs), and operating systems.

Best Practices for Container Image Scanning

Image scanning processes analyze the contents as well as the build process of each container image. The goal is to detect vulnerabilities, bad practices, and security issues. Here are several best practices that can help you effectively scan container images.

Related content: Read our guide to general container security best practices

Scan at Every Stage of the Container Lifecycle

Effective scanning is not a one-time gate at build. Apply automated checks across each stage of the container lifecycle:

  1. Pre-build and build – Inspect the Dockerfile for misconfigurations and scan the base image before it is published.
  2. Registry – Scan images continuously as they are pushed to or pulled from container registries.
  3. Deployment – Automate policy checks in your pipeline so vulnerable deployments are blocked or flagged for remediation.
  4. Runtime – Actively track container behavior and enforce compliance with regulatory benchmarks such as CIS and NIST in production.

Scan for Third-Party Library Vulnerabilities

Applications often use a vast amount of libraries, which may add up to more lines of code than those created by your team. Be sure to scan for vulnerabilities not only in your code, but also in all dependencies. If you are using a scanner that scans third-party libraries, you can use it to track vulnerabilities in libraries using the same feeds employed to warn about operating system vulnerabilities.

Related content: Read our guide to container security tools

Embed Image Scanning in the CI/CD Pipeline

Be extremely careful when building container images and scan each image before publishing it. To ensure efficiency, you can add image scanning into your CI/CD pipeline as another phase in the cycle. Instead of directly publishing your image to production once it is built, you should push it to a staging repository and then run your image scanner.

A container security scanner can provide a report that details all detected issues, while assigning specific severities to each one. Use your CI/CD pipeline to check the results of the image scanning process. If there are critical issues, you can simply fail the build—before it reaches production. You can automate the container scanning process to ensure you catch vulnerabilities before any can enter the registry or production.

Use Minimal Base Images

Strive to build the lightest possible image. The lighter the image, the faster your builds and scans. As a result, the image also has fewer dependencies that may contain potential vulnerabilities.

Typically, new Docker images are built by using, or adding a layer over, an existing base image. A base image is defined through the FROM statement located in the image Dockerfile. This process creates a layered architecture design, which saves a significant amount of time.

However, if you scan a base image only once and the parent image is vulnerable—any other images you build on top of it remain vulnerable, too. To mitigate this issue, use scanning tools to actively track vulnerability feeds for any known vulnerable images. The tool will let you know if you are using any of the known vulnerable images.

Use Distroless Images When Possible

Distroless images are base images that do not contain shells, package managers, or any programs running in a standard Linux distribution. A distroless image lets you package only the application and its dependencies within a lightweight container image. Essentially, it enables you to restrict what is allowed within your runtime container and minimize the attack surface.

Optimize the Ordering of Layers

To optimize container images, pay special attention to the RUN commands in your Dockerfile. The order of your RUN commands significantly impacts the finalized image, because it determines the order of the layers that make up the image.

To optimize your Docker cache usage, you can place bigger layers (typically invariant) first, and place the most variable files (the compiled application) at the end. This helps prioritize reusing existing layers, accelerate image building, and also indirectly speed up the image scanning process.

A range of tools can automate container security scanning, from open-source scanners to comprehensive commercial platforms.

  • Trivy – A popular, comprehensive open-source tool from Aqua Security that scans container images, filesystems, and Git repositories for vulnerabilities and misconfigurations.
  • Clair – An open-source, API-driven engine designed to index and continually scan container images for known vulnerabilities (CVEs).
  • Grype and Syft – Open-source tools from Anchore that specialize in generating Software Bills of Materials (SBOMs) and scanning images and filesystems for vulnerabilities.

Container Security with Calico

Calico Cloud offers active build, deploy and runtime security for containers and Kubernetes.

  • Build – With Calico’s Image Assurance, DevOps teams can secure the build pipeline with an integrated Image Scanner, an admission controller to automatically block vulnerable images from being deployed, and a runtime view of high-risk workloads in the application to prioritize remediation activities.
  • Deploy – Detect configuration violations and misconfigurations in the Kubernetes environment to prevent breaches. Calico can generate CIS benchmark reports to conform to security best practices.
  • Runtime – Protect container workloads from network-based and container-based threats with zero-trust workload access controls, malware protection, and identity-based microsegmentation. Calico uses machine learning and global threat feeds to detect anomalies and zero-day threats in containerized applications.

Visit our container security solutions page to learn more about Calico Cloud’s container security features.

Next Steps

X