Docker Makes Hardened Images Catalog Free: Security For Everyone

Hello HaWkers, Docker just made a significant move for the developer community: the complete Hardened Images catalog, previously a paid feature, is now completely free. This represents an important democratization of container security.

But what are Hardened Images and why does this matter to you? Let's explore.

What Are Docker Hardened Images?

Hardened Images are Docker images that have undergone a rigorous security hardening process. They are based on official images, but with additional layers of protection.

Differences From Regular Images

Regular Docker image:

May contain known vulnerabilities
Non-essential packages installed
Default configurations (not always secure)
Users with elevated privileges
Logs and debug enabled

Docker Hardened Image:

Known vulnerabilities removed
Only essential packages
Optimized security configurations
Non-privileged users (non-root)
Minimized attack surface

What Changed

Before this announcement, access to Hardened Images cost:

Previous pricing:

Docker Team: Included ($11/user/month)
Docker Business: Included ($24/user/month)
Docker Personal: Not available
Docker Pro: Not available

Now:

Free for all plans
Unlimited access to catalog
Automatic security updates
SBOMs (Software Bill of Materials) included

Available Catalog

Available hardened images:

Alpine Linux (minimalist base)
Ubuntu (various versions)
Node.js (LTS and Current)
Python (3.x)
Nginx
PostgreSQL
Redis
MongoDB
MySQL
Go
Rust
Java/OpenJDK

Why This Matters

The free availability has significant impacts:

Democratized Security

Before:

Only companies with budget had access
Startups and open source projects vulnerable
Individual developers without protection

Now:

Any developer can use it
Open source projects more secure
Overall reduction in vulnerabilities

Security Numbers

Vulnerability comparison (CVEs):

Image	Regular	Hardened	Reduction
node:20	147 CVEs	12 CVEs	92%
python:3.12	203 CVEs	18 CVEs	91%
nginx:latest	89 CVEs	7 CVEs	92%
postgres:16	156 CVEs	14 CVEs	91%
redis:7	67 CVEs	5 CVEs	93%

How to Use

Migrating to Hardened Images is simple:

Base Image Switch

# BEFORE: Regular image
FROM node:20-alpine

# AFTER: Hardened Image
FROM docker.io/library/node:20-alpine-hardened

# Or using the specific registry
FROM dhc.docker.com/library/node:20-alpine

# The rest of the Dockerfile stays the same
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Vulnerability Verification

# Scan regular image
docker scout cves node:20-alpine
# Output: 147 vulnerabilities found

# Scan hardened image
docker scout cves dhc.docker.com/library/node:20-alpine
# Output: 12 vulnerabilities found

# Compare SBOMs
docker sbom node:20-alpine > regular-sbom.json
docker sbom dhc.docker.com/library/node:20-alpine > hardened-sbom.json
diff regular-sbom.json hardened-sbom.json

Docker Compose Configuration

# docker-compose.yml
version: '3.8'

services:
  api:
    # Use hardened image
    image: dhc.docker.com/library/node:20-alpine
    build:
      context: .
      dockerfile: Dockerfile
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    user: "1000:1000"

  database:
    image: dhc.docker.com/library/postgres:16-alpine
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  postgres_data:

Container Security Best Practices

Besides using Hardened Images, consider these practices:

Secure Dockerfile

# Use hardened image as base
FROM dhc.docker.com/library/node:20-alpine

# Create non-root user
RUN addgroup -g 1001 appgroup && \
    adduser -u 1001 -G appgroup -D appuser

# Set working directory
WORKDIR /app

# Copy only necessary files
COPY --chown=appuser:appgroup package*.json ./

# Install dependencies as non-root user
USER appuser
RUN npm ci --only=production

# Copy source code
COPY --chown=appuser:appgroup . .

# Expose non-privileged port
EXPOSE 3000

# Use ENTRYPOINT instead of CMD for better security
ENTRYPOINT ["node"]
CMD ["index.js"]

# Healthcheck
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD node healthcheck.js || exit 1

Automatic CI/CD Scan

# .github/workflows/security.yml
name: Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Docker Scout
        uses: docker/scout-action@v1
        with:
          command: cves
          image: myapp:${{ github.sha }}
          sarif-file: sarif.output.json
          summary: true

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: sarif.output.json

Impact For the Ecosystem

Docker's decision has broad effects:

Benefits For Developers

Individuals:

More secure personal projects
Portfolio with best practices
Less risk in production

Companies:

Reduced security costs
Easier compliance
Fewer security incidents

Open Source:

Projects can adopt at no cost
Safer community
Best practices disseminated

Market Trend

This decision follows a security democratization trend:

Company	Feature	Before	Now
Docker	Hardened Images	Paid	Free
GitHub	Dependabot	Paid	Free
Snyk	Open Source Scan	Limited	Expanded
GitLab	SAST/DAST	Premium	Free tier

Recommended Migration

If you still use regular images, consider this migration strategy:

Step by Step

Phase 1 - Audit:

List all base images in use
Check current vulnerabilities
Identify hardened equivalents

Phase 2 - Test:

Replace in development environment
Run complete test suite
Validate application behavior

Phase 3 - Production:

Gradual deploy (canary)
Monitor metrics
Rollback if necessary

Conclusion

Docker's decision to make Hardened Images free is a milestone for container security. Now, there's no more excuse for running vulnerable containers in production.

If you haven't migrated yet, this is the ideal time. Your production environment's security depends on it.

For more content on DevOps and security, I recommend checking out: Node.js Security Updates: Critical Vulnerabilities December 2025 where we cover critical security updates.