What are hardened container images?

In brief

• Hardening changes what is inside an image and how it is configured. Patching fixes what is known to be vulnerable. A production base image needs both.
• Judge a hardened image on six things: where it comes from and how it is rebuilt, its CVE fix windows, the benchmark it follows, FIPS and distroless variants, how your scanner reads it, and whether it is a drop-in replacement.
• RapidFort Curated Images are hardened against their appropriate STIG or CIS Benchmark, when available, and are manually patched and rebuilt by RapidFort engineers, with up to 99.9% CVE elimination across distroless and full images.

A hardened container image is a container image that has been secured by removing components the application does not need and by applying a configuration standard such as the CIS Benchmarks or a DISA STIG. Hardening shrinks the attack surface: fewer packages, fewer binaries, fewer default settings an attacker can use. It does not, by itself, fix the known vulnerabilities in the software that remains; that takes patching, which is the difference between a hardened image and a near-zero CVE image.

This guide explains what hardening changes, why teams adopt hardened images, how they differ from minimal, distroless and near-zero CVE images, and the six checks to run before you make one your standard base.

How hardening changes a container image

Hardening changes what is inside the image and how it is configured. A standard distribution image ships with a shell, a package manager, documentation, locale files and dozens of utilities that most applications never call. A hardened image removes as much of that as the application allows, runs as a non-root user, drops Linux capabilities it does not need, and sets file permissions and defaults to a published benchmark.

Two benchmarks define "hardened" in practice. The CIS Benchmarks are prescriptive, consensus-based configuration recommendations for operating systems, containers and cloud services (https://www.cisecurity.org/cis-benchmarks). A DISA STIG is a configuration standard from the US Defense Information Systems Agency, based on Department of Defense policy, for a specific product and version (https://csrc.nist.gov/glossary/term/security_technical_implementation_guide). NIST SP 800-190, the Application Container Security Guide, sets out the image, registry, orchestrator, container and host risks that hardening addresses (https://csrc.nist.gov/pubs/sp/800/190/final).

Why teams adopt hardened container images

Teams adopt hardened images because most of the risk in a container is inherited, not written. A base image is the image a Dockerfile's FROM line builds on (https://docs.docker.com/reference/dockerfile/#from), and every image built on top inherits its contents, including its vulnerabilities, before any application code is added. Starting from a hardened base removes a large share of that inherited exposure for every service built on it.

Three outcomes follow. Scanners report fewer findings, so engineers spend less time triaging vulnerabilities in packages the application never runs. Audits go faster, because the benchmark the image is hardened to is the one auditors ask about: FedRAMP's container requirements call for hardening "in accordance with relevant benchmarks listed in the National Checklist Program and defined by NIST SP 800-70" (https://www.fedramp.gov/resources/documents/Vulnerability_Scanning_Requirements_for_Containers.pdf). And an attacker who lands in a container with no shell and no package manager has fewer tools to move with, so an incident does less damage.

Hardened images and near-zero CVE images are not the same thing

A hardened image reduces what can be attacked; a near-zero CVE image also fixes what is known to be vulnerable. Hardening removes packages and tightens configuration, but the packages that remain still carry whatever CVEs their versions carry. A near-zero CVE image takes the further step of patching or backporting every CVE for which a fix exists, rebuilding when new fixes land, and publishing how fast that happens.

The distinction matters when you read a vendor's page. "Hardened" tells you the configuration was tightened. It does not tell you whether the OpenSSL or glibc inside it is patched, how quickly a new critical CVE will be fixed, or from which date that clock starts. The next section gives the questions that surface those answers. What is a near-zero CVE image?

Six questions to ask before you adopt a hardened image

Six questions separate a hardened image you can standardize on from one that will cost you later. Put them to the vendor, and to your own platform team if you build images in house.

Where did it come from, and how is it rebuilt?

Ask which distribution the image is built on, who maintains it, and what triggers a rebuild. An image built on an LTS distribution inherits that distribution's security maintenance: Ubuntu LTS releases receive 5 years of standard security maintenance (https://ubuntu.com/about/release-cycle), Debian LTS extends each stable release to at least 5 years (https://www.debian.org/lts/), and Red Hat Enterprise Linux has a 10-year life cycle (https://access.redhat.com/support/policy/updates/errata). Alpine does not use the LTS label; each release is supported for about 2 years (https://alpinelinux.org/releases/).

How fast are new CVEs fixed, and from which clock?

Ask for the fix window by severity, the time unit, when the clock starts, whether there is a separate window for CISA Known Exploited Vulnerabilities, and whether the commitment is in the contract. A "7 days" statement means different things if the clock starts at CVE publication, at KEV listing or at upstream patch availability. The CISA KEV catalog lists vulnerabilities with reliable evidence of active exploitation (https://www.cisa.gov/known-exploited-vulnerabilities), and under CISA Binding Operational Directive 26-04, issued June 10, 2026, KEV entries carry federal due dates of 3 or 14 days (https://www.fedramp.gov/notices/0014/).

Is it hardened to a benchmark, and which one?

Ask which CIS Benchmark or STIG the image is hardened against, and whether that is stated per image or as a general claim. Benchmarks are version-specific, so the answer names the distribution and the version.

Does it come in FIPS and distroless variants?

Regulated workloads need cryptography from validated modules, and FIPS 140-3 is the US government standard for cryptographic modules (https://csrc.nist.gov/pubs/fips/140-3/final). Ask whether a FIPS variant exists for the images you run. Ask also whether a distroless variant exists: distroless images contain only the application and its runtime dependencies, with no package manager or shell (https://github.com/GoogleContainerTools/distroless). Hardened vs minimal vs distroless

Does your scanner read it correctly?

Run the image through the scanner you already use before you commit. Scanners disagree: a 2024 IEEE study of 927 Docker images found that Trivy and Grype reported different vulnerability counts and different vulnerability IDs for the same images (https://conf.researchr.org/details/scam-2024/scam-2024-new-ideas-and-emerging-results/3/Deciphering-Discrepancies-A-Comparative-Analysis-of-Docker-Image-Security). A scanner that matches on version numbers can also report a backported fix as unfixed (https://access.redhat.com/security/updates/backporting). Ask what metadata the image carries so scanners recognize patched packages, and whether SBOM and VEX statements are available.

Will it break your application?

Ask whether the image keeps the same distribution, tags, environment variables and paths as the image it replaces, or whether it requires a move to a different operating system. Switching between a glibc-based distribution and Alpine, which is built around musl libc (https://alpinelinux.org/about/), can change how software behaves even when the application code has not changed. A drop-in replacement keeps your Dockerfile's FROM line pointing at the same distribution and tag.

Rolling hardened images out across teams

Publish the approved hardened images to an internal registry and make them the only base images development teams can build on. Enforce it at deployment: Kubernetes admission controllers intercept requests to the API server before a resource is saved (https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/), and policy engines such as Kyverno (https://kyverno.io/docs/introduction/how-kyverno-works/) and Open Policy Agent Gatekeeper (https://open-policy-agent.github.io/gatekeeper/website/docs/) run as admission controllers that can allow images only from approved registries. Start with the base images shared by the most services, since those carry the same inherited risk into every service built on them.

What hardened images do not do

Hardened images do not remove the need for scanning, because new CVEs are disclosed in the packages that remain. They do not remove the need for runtime security, because production changes after deployment: packages are updated, processes change and unauthorized modifications can occur. And hardening alone does not patch known vulnerabilities; it reduces the number of places they can sit.

How RapidFort Curated Images answer the six questions

RapidFort Curated Images are drop-in replacement container images with near-zero CVEs from day one. They are not just hardened: RapidFort engineers manually patch and rebuild them, and every image is continuously patched to eliminate all CVEs for which a patch is available. Against the six questions:

• Origin and rebuild: built on all major LTS releases of Ubuntu, Debian and Red Hat, plus Alpine, including minor and older versions, with tens of thousands of images from base operating systems to popular open source applications.
• Fix windows: the RapidFort Support and Availability Policy, part of the RapidFort Master Subscription Agreement, sets target resolution times for the images in a subscription. For CISA KEV vulnerabilities the target is 1 calendar day from the date an applicable patch is available. For other CVEs, measured from the date an applicable patch is publicly available, the targets are 7 calendar days for Critical and High, 21 for Moderate and 28 for Low, and RapidFort uses commercially reasonable efforts to meet them.
• Benchmark: hardened against their appropriate STIG or CIS Benchmark, when available.
• Variants: FIPS and standard variants are available unless an image does not need a FIPS variant or upstream license restrictions prevent one, and every image comes as a distroless and a full image, with up to 99.9% CVE elimination across both.
• Scanners: rich metadata built in, compatible with every major scanner, and registry flexible.
• Compatibility: pin-for-pin compatible with no re-baselining; the same distributions and tags, with environment variables and paths unchanged. Swap the image tag in your build and deploy with your existing pipelines.

One dated example: curating Red Hat UBI9 images with RapidFort produced 93.3% fewer CVEs

Frequently asked questions

Are hardened images the same as minimal or distroless images?

No. A minimal image reduces what is installed, a distroless image also removes the shell and package manager, and a hardened image applies a configuration standard such as a CIS Benchmark or STIG. An image can be all three. None of the three removes known CVEs in the packages that remain. Hardened vs minimal vs distroless

What is a CIS hardened container image?

A CIS hardened container image is a container image configured to a CIS Benchmark, the Center for Internet Security's consensus-based configuration recommendations for a given Linux distribution or for Docker. Benchmarks are version-specific, so a CIS hardened image states which benchmark and version it follows, and the configuration can be checked with a benchmark scanner such as OpenSCAP.

Do I still need a vulnerability scanner with hardened images?

Yes. New CVEs are disclosed in the packages that remain, and scanning is how you see them and how you verify a vendor's claims with your own tooling. Hardened and near-zero CVE images reduce what the scanner reports; they do not replace it.

Can we build hardened container images ourselves instead of buying them?

Yes. The steps are documented and the tooling is open source. The ongoing cost is the operating model: tracking upstream advisories, backporting fixes, rebuilding, testing and distributing images for every base you run, continuously, with a fix window your team can sustain. Teams with a small number of bases and dedicated engineers do this in house; teams with many bases compare that cost against a vendor catalog.

Will switching to a hardened base image break my application?

It depends on what changes. A drop-in replacement that keeps the same distribution, tags, environment variables and paths needs the same testing as any base image update. A move to a different distribution, especially between glibc and musl, needs a full test pass because library behavior can differ.

How often should hardened images be rebuilt?

Rebuild when a security fix is available for a package in the image, when a new distribution release lands, and on a stated schedule in between. The schedule matters less than the fix window: what you need to know is how many days pass between an upstream fix and the rebuilt image.

Can hardened images satisfy FedRAMP container requirements?

They are part of it. FedRAMP's 2021 container requirements call for hardening in accordance with benchmarks in the NIST National Checklist Program (SP 800-70) and allow only containers from images scanned within a 30-day window to run in production (https://www.fedramp.gov/resources/documents/Vulnerability_Scanning_Requirements_for_Containers.pdf). RapidFort supports FedRAMP container requirements: RapidFort Curated Images are hardened against their appropriate STIG or CIS Benchmark, when available; both benchmark families are listed in the NIST National Checklist Program that the FedRAMP requirements reference.