Building Secure Containers: Reducing Vulnerabilities With Clean Base Images

In today’s fast-paced development environment, containerized applications have become the go-to solution for many organizations. They offer scalability, portability, and efficiency. However, containerized environments also bring their own set of challenges, particularly when it comes to security vulnerabilities. One of the most effective ways to mitigate these risks is by focusing on the base images used for containers.

Why Base Images Matter

The base image serves as the foundation for every container. If the base image contains vulnerabilities, they are inherited by every container built on top of it. This can expose your application to potential attacks despite layers of security built into the infrastructure. Therefore, choosing clean, vulnerability-free base images is critical to securing your containerized applications.

Steps to Reducing Vulnerabilities in Base Images

1. Start With Minimal Base Images 

One of the most effective ways to reduce vulnerabilities is by using minimal base images. These are lean versions of operating system images that include only the essential components required to run your application. Limiting the number of packages and dependencies reduces the attack surface, inherently decreasing the chances of vulnerabilities creeping in.

Popular minimal base images include:

• Alpine Linux: Known for its lightweight nature, Alpine is often the go-to choice for minimalistic base images.
• Distroless Images: These images contain only the application and its runtime dependencies, offering an even smaller attack surface.
• Scratch: This is the smallest image available and contains no OS layers, offering the absolute minimum for running containers.

Example Using Scratch

The scratch base image is entirely empty, which eliminates the possibility of carrying over any vulnerabilities from operating system components. However, it requires you to compile your application and include all necessary dependencies statically.

Here’s an example of how to use scratch:

FROM scratch

COPY my-static-app /my-static-app

CMD ["/my-static-app"]

• In this example, the my-static-app application must be statically compiled with no dependencies. This setup significantly reduces the attack surface, as there is no underlying OS layer, thus preventing many types of vulnerabilities.

2. Use Official Images

Official base images provided by trusted repositories are more secure as they are maintained and regularly updated by large communities or trusted vendors. You risk introducing poorly maintained or malicious components into your system when using third-party or unofficial images.

Always verify that you are using the latest version of the base image, as older versions may contain outdated software with known vulnerabilities.

3. Scan Images for Vulnerabilities

Even with minimal and official images, vulnerabilities can still exist. Therefore, it’s crucial to scan your base images for known vulnerabilities regularly. Below are examples of how to use scanning tools like Clair, Trivy, and Anchore.

Example: Scanning With Trivy

Trivy is a simple yet powerful tool for scanning container images for vulnerabilities.

trivy image my-docker-image

Trivy will scan the image and provide a report showing the identified vulnerabilities along with their severity levels.

Example: Scanning With Clair

Clair is an open-source tool designed to integrate with Docker and Kubernetes to scan and monitor vulnerabilities in your container images. To scan an image using Clair, you need to first push it to a Docker registry and then trigger a scan:

clair push my-docker-image

clair report my-docker-image

This will output a vulnerability report based on the Common Vulnerabilities and Exposures (CVEs) database.

Example: Scanning With Anchore

Anchore is another powerful tool for vulnerability scanning, with deep integrations into CI/CD pipelines.

You can scan an image using Anchore's CLI:

anchore-cli image add my-docker-image

anchore-cli image vuln my-docker-image all

• Anchore will output a detailed report, showing both confirmed vulnerabilities and remediation recommendations.

4. Regularly Update Base Images

Vulnerabilities are constantly being discovered in software components. To stay ahead of potential threats, ensure that your base images are regularly updated. Automated tools and Continuous Integration/Continuous Deployment (CI/CD) pipelines can help automate the process of rebuilding containers with the latest, patched base images.

Regular updates should be part of your security workflow. It’s recommended to have a process in place that automatically notifies you when a new version of a base image is available and helps in rebuilding and redeploying your containers with the updated image.

5. Remove Unnecessary Packages

A common issue with base images is the inclusion of unnecessary packages that bloat the image size and increase the attack surface. Each additional package in a base image increases the risk of vulnerabilities being present. After selecting a minimal base image, audit it for unnecessary packages, and remove them to further harden the image.

Example With Alpine

FROM alpine:3.16

RUN apk --no-cache add bash

• This example demonstrates installing only the required software (bash) and using the --no-cache flag to ensure that no unnecessary data is left behind in the image, helping to keep it lean and secure.

6. Multi-Stage Builds

Multi-stage builds in Docker allow you to use multiple base images in the Dockerfile. This helps in keeping the final image clean by separating the build environment from the runtime environment. In other words, you can use a larger image with all necessary build tools during the build process but use a leaner, cleaner image in the final production stage, significantly reducing the number of components that need to be maintained or secured.

Example of Multi-Stage Build

# Stage 1: Build stage

FROM golang:1.20 as build

WORKDIR /app

COPY . .

RUN go build -o my-app

# Stage 2: Run stage with a minimal base image

FROM scratch

COPY --from=build /app/my-app /my-app

CMD ["/my-app"]

• In this example, the build is done in a larger Golang image, but the final runtime container uses the scratch image, which significantly reduces the size and attack surface of the final container.

Best Practices for Securing Base Images

1. Use Immutable Tags

When specifying base images in your Dockerfile, avoid using the latest tag. The latest tag can introduce unpredictability into your system because it can refer to different versions over time. Instead, use immutable tags (such as specific version numbers) that lock down your dependencies to known states.

2. Implement Security Policies

Use tools such as Open Policy Agent (OPA) or Kubernetes admission controllers to enforce policies that prevent developers from using images with known vulnerabilities. These policies can be integrated into your CI/CD pipelines to enforce secure practices across the development lifecycle.

3. Maintain a Trusted Image Registry

Use a trusted image registry, such as Docker Hub or your organization’s internal image registry. These registries provide signed images, which can ensure that the images you pull are not tampered with. Additionally, scanning images in your registry for vulnerabilities before deployment ensures they meet your security standards.

Conclusion

Reducing vulnerabilities in base images is a foundational step toward building secure, containerized applications. By starting with minimal and official images, scanning for vulnerabilities, and regularly updating your base images, you can greatly reduce the risks associated with container vulnerabilities. When combined with best practices like multi-stage builds, scratch base images, and immutable tags, you are well on your way to creating a secure, robust container environment.

By implementing these strategies, organizations can strengthen their security posture, reduce their exposure to risks, and maintain a safer development pipeline.