What is Docker Hardened Images and Why should you use it?

Docker is the most widely used application runtime for hosting applications in production environments. Organizations of all sizes from startups to large enterprises rely on Docker to build, ship, and run their applications.

However, Docker images are not secure by default. They do not include built-in vulnerability (CVE) scanning or compliance checks. To address this, teams often rely on third-party tools such as Trivy or Grype to perform regular security and compliance scans.

But what about the base image itself? Even Official Docker Images are not fully secure by default. They often include unnecessary packages and run with root privileges, which increases the attack surface and the risk of exploitation.

To tackle these issues, Docker introduced Docker Hardened Images. In this blog, we will explore what Docker Hardened Images are and why you should consider using them.

What is DHI?

Docker Hardened Images (DHI) are secure, minimal, and pre-configured container images designed to significantly reduce vulnerabilities (near-zero CVEs) and simplify compliance requirements.

Docker Hardened Images are particularly useful for teams running production workloads in regulated environments such as finance, healthcare, or government systems, as well as organizations aiming to reduce operational overhead related to vulnerability management.

Before DHI

Before the introduction of Docker Hardened Images, it was the developer's responsibility to create a secure container image. This included not only building the image securely but also maintaining it throughout its entire lifecycle to protect against emerging cybersecurity threats.

With Docker itself introducing and maintaing Hardened Images, I believe it's a strong initiative by Docker to reduce attack surfaces and help organizations better defend against cyber attacks.

Below are the key points that differentiate Docker Hardened Images (DHI) from traditional container images. These points help explain why DHI is needed and how Docker provides additional benefits through this approach.

Distroless Approach

Traditional images come with a full OS base. You can easily start a shell and install any debugging tools you want. However, this approach comes with a problem. If an attacker gains access, they can easily execute unwanted commands inside the container.

Containers are meant to be fixed assets. They should not be treated as mini operating systems. Once a container starts, it should only execute the application code and nothing else.

DHI images do not contain shells, compilers or interpreters, package managers, or any debugging tools such as curl or wget. This minimizes the attacker surface, as the container only includes:

The application binary
Its runtime dependencies (e.g., libc, Java, Python)
Any explicitly required configuration or metadata

Image Hardening

A hardened base image reduces the attack surface of the software and makes it a harder target for attackers. This is achieved by removing unnecessary dependencies, functionalities, and components. A hardened Docker image achieves this by:

Removing shells, compilers, package managers, or any debugging tools from the base image.
Running the container as a non-root user
Reducing the writable layers
Ensuring immutability

These images are built to be:

Minimal: This directly reduces the attack surface
Immutable: Once an image is created, no additional dependencies can be installed at runtime
Non-root by default: Containers run only as a non-root user
Purpose-scoped: With tags such as -dev, -sdk, or production-specific images, teams can leverage appropriate images for different environments

Image Provenance

Each DHI contains the metadata that helps in tracing back to its origin like who created the image, where did it come from, has it been tampered with?

This introduces transparency and trust about the image to the user.

Continous, Automated Patching

As CVEs are continuously evolving and newly discovered, it is important for container images to evolve alongside them. This means a one-time–created DHI is not enough to protect against emerging vulnerabilities. To address this, Docker continuously updates and patches Docker Hardened Images to keep them up to date with the latest CVEs.

Docker updates and patches vulnerabilities in Docker Hardened Images within 24 hours.

One example of continuous updating can be seen when the Go project published two new CVEs that were critical for applications using SSH functionality. Docker took immediate action.

As soon as the CVE data became available, Docker Scout began ingesting vulnerability information from upstream sources such as GitHub Security Advisories and the National Vulnerability Database.
Scout then identified which Docker Hardened Images were affected based on its comprehensive SBOM database.
The patching process was then initiated, either automatically or through manual review where required.
Once the Go package build was successful, the system proceeded to rebuild all dependent packages and images.
Customers using Docker Scout immediately received notifications about the vulnerabilities and the availability of patched versions.

This demonstrates how Docker updates images in near real time rather than relying on one-time hardening alone.

Comprehensive SBOM

Each DHI comes with SBOM list. This list includes all the details about the components, dependencies or libraries that the image contains.

Enhanced transparency: SBOMs enables organizations to identify and assess risks associated with third-party libraries and dependencies.
Regulatory compliance: Many regulations and industry standards now require organizations to maintain control over the software components they use. An SBOM facilitates compliance by providing a clear and accessible record.
Improved incident response: In the event of a security breach, an SBOM enables organizations to quickly identify affected components and take appropriate action, minimizing potential damage.

You can also lists SBOM of the DHI yourself, using the following command:

docker scout sbom dhi.io/<image-name>:<tag>

docker scout sbom dhi.io/<image-name>:<tag>

Building a Complaince-Ready Production Environment

Apart from the key points discussed above, Docker also helps in creating a regulatory and compliant-based environment while using these images in production.

Each DHI are attested. It means that it contains verifiable information about an image such as how it was, what's inside it and what security checks it has passed.
In-built FIPS Complaince implementation. This is crucial for financial or healthcare softwares. (Note: This is only available for DHI Enterprise)
Introducing immutability in the images prevents any dependecy installation during container runtime.
Each DHI is cryptographically signed and complies with the SLSA Build Level 3 standard, ensuring verifiable build provenance and integrity.

How to start using DHI?

It's a very simple process. You can just replace your base image with the DHI or have to make little changes in your existing Dockerfile.

To use DHI, you would have to:

Create an account in DHI Sign Up Page.
Then login using the cli

docker login dhi.io

docker login dhi.io

Enter your username and password.

Then simply start pulling the images you want to use.

docker pull dhi.io/<image-name>:<tag>

docker pull dhi.io/<image-name>:<tag>

Using DHI in Dockerfiles:

# Traditional
FROM node:18
RUN apt-get update && apt-get install -y curl
# DHI
FROM dhi.io/node:18-prod
USER nonroot

# Traditional
FROM node:18
RUN apt-get update && apt-get install -y curl
# DHI
FROM dhi.io/node:18-prod
USER nonroot

For every application that is hosted on Docker, DHI should be an integral part of the container. They reduce operational burden and shift container security from reactive scanning to secure-by-design foundations.

Thank you for reading!🌟

Contents