What are secure base images?

In brief

Every image built on a base inherits its contents and vulnerabilities, and one base is reused across many services, so fixing the base removes inherited risk from every service that rebuilds on it.
A secure base image meets five criteria: verifiable provenance and rebuild model, a low CVE baseline with published patch windows, benchmark hardening, FIPS and distroless variants, and metadata your scanner reads correctly.
Make it stick by publishing approved bases to an internal registry and enforcing them at admission with Kyverno or OPA Gatekeeper.

A secure base image is a container base image that starts with few or no known vulnerabilities, comes from a verifiable source, is hardened to a benchmark such as the CIS Benchmarks or a DISA STIG, and is updated when fixes for newly disclosed CVEs become available. A base image is the container image an application image is built on; in a Dockerfile, the FROM instruction sets it. Every image built on top inherits the base image's contents, including its vulnerabilities, so inherited CVEs are present before any application code is added. This guide covers the five criteria to choose on, how the common distributions compare, and how to make the secure base the only one your teams can build on.

Why the base image sets your starting risk

The base image is where the operating system packages live, and every image built on it inherits those packages and their CVEs. A service that adds a runtime and a few hundred lines of application code to a full distribution image ships with every package in that base image, used or not. The same base is reused across many services, so one vulnerable base multiplies into every workload built on it. Fixing the base once removes the inherited share of the problem from every service that rebuilds on it.

Five criteria for a secure base image

There are five criteria, in the order to check them.

Provenance and rebuild model

Know who builds the image, from what, and what triggers a rebuild. Signed images let you verify origin and integrity: Sigstore lets developers sign artifacts and record signatures in a tamper-resistant public log, and its Cosign tool signs OCI containers. Provenance, in SLSA's terms, is an attestation describing how the outputs were produced. Signing proves origin; it does not show whether the image is free of vulnerabilities.

CVE baseline and patch windows

Scan the image before you adopt it and ask how new CVEs are fixed: the severity tiers, the time unit, when the clock starts, whether there is a separate window for CISA Known Exploited Vulnerabilities, and whether the commitment is contractual. The baseline tells you where you start; the patch windows tell you where you will be in six months. What is a near-zero CVE image?

Benchmark hardening

Ask whether the image is hardened against a named CIS Benchmark or DISA STIG for its distribution and version. For FedRAMP workloads, the FedRAMP Vulnerability Scanning Requirements for Containers (2021) require hardening, where applicable, in accordance with relevant benchmarks in the NIST National Checklist Program, defined by NIST SP 800-70. What are hardened container images?

FIPS and distroless variants

If your workloads require cryptography from modules validated to FIPS 140-3, ask whether a FIPS variant exists for your base. Ask also for a distroless variant where the service needs no shell or package manager. Hardened vs minimal vs distroless

For non-FIPS versions of base images and curated frameworks/language libraries, ask if they are PQC-ready (post-quantum cryptography ready).

Scanner readability

Run the image through your own scanner. Scanners disagree on the same image: in an IEEE SCAM 2024 study, Trivy and Grype disagreed on both the number of vulnerabilities and the vulnerability IDs found, and a scanner that matches on version strings can report a backported fix as unfixed. A secure base carries metadata and SBOMs that your scanner reads correctly.

Choosing between Ubuntu, Debian, Red Hat UBI and Alpine

Choose the distribution your application and its dependencies are already tested on, then check its support window. Ubuntu LTS releases arrive every two years and receive 5 years of standard security maintenance for packages in the Main repository. Debian LTS extends every stable release to at least 5 years. Red Hat Enterprise Linux has a 10-year life cycle, and Red Hat UBI is a freely redistributable base built from portions of it. Alpine makes a release branch each May and November; its main repository is typically supported for 2 years and its community repository until the next stable release, and it is built around musl libc, which has documented functional differences from glibc. The choice is about compatibility and support length, and the security comes from how the image is patched and configured.

Making the secure base image the only approved base

Publish the approved images to an internal registry and make them the only base images development teams can pull. Then enforce it where workloads are admitted: Kubernetes admission controllers intercept requests to the API server before a resource is saved, and policy engines such as Kyverno and Open Policy Agent Gatekeeper run as admission webhooks that can allow images only from approved registries, or only signed images (Kyverno verifyImages rules; Gatekeeper through an external data provider). Golden images, in Red Hat's definition, are intentionally configured snapshots of a system that can be used to deploy new instances; in container terms, your approved base images are the golden images.

Switching base images without breaking builds

Change the FROM line and keep everything else, when the new image keeps the same distribution and tags. Pin by digest, rebuild, run the test suite you run for any base image update, and scan before and after to confirm the CVE drop. When the switch changes distribution, especially between glibc and musl, plan a full rebuild and regression pass. Roll out base by base, starting with the base shared by the most services.

A drop-in switch changes one line and keeps the tag family, so the application sees the same distribution, paths and environment variables:

# Before: public base image, mutable tag
FROM python:3.12-slim

# After: the approved secure base from your registry, same distribution and tag family, pinned by digest
FROM registry.example.internal/approved/python:3.12-slim@sha256:<digest>

Replace the registry path and digest with your own.

How RapidFort Images meet the criteria

RapidFort Images are drop-in replacement base images with near-zero CVEs from day one. Replace your base images and eliminate inherited vulnerabilities before development even begins: select the image for your distribution, swap the image tag in your build, and build and deploy with your existing pipelines, with the same distributions and tags and with environment variables and paths unchanged. Against the five criteria:

Provenance and rebuild model: RapidFort engineers manually patch and rebuild them, and every image is continuously patched to eliminate all CVEs for which a patch is available.
CVE baseline and fix windows: CISA KEV 1 day, Critical and High 7 days, Moderate 21 days, Low 28 days, from when a patch is available.
Benchmark hardening: hardened against their appropriate STIG or CIS Benchmark, when available.
FIPS and distroless variants: FIPS and standard variants are available unless an image does not need a FIPS variant or upstream license restrictions prevent one, and the catalog comes in full and distroless variants, with up to 99.9% CVE elimination across distroless and full images.
RapidFort non-FIPS versions of base images and curated frameworks/language libraries are now PQC-ready (post-quantum cryptography ready).
Scanner readability: rich metadata built in, compatible with every major scanner, and registry flexible, so you pull them from the RapidFort registry or your own.

The catalog holds tens of thousands of images, from base OS images to popular open source applications, across all major LTS releases of Ubuntu, Debian and Red Hat, plus Alpine, including minor releases. End-of-life versions can be supported on request; patching covers the open source packages when an upstream fix can be backported. Following the approach in the RapidFort white paper A Disciplined Approach to Container Supply Chain Security, platform teams publish the images to an internal registry as the only approved base images and enforce them with a policy engine such as Kyverno or Gatekeeper.

Frequently asked questions

What is the difference between a base image and a golden image?

A base image is whatever the FROM line names. A golden image, in Red Hat's definition, is an intentionally configured snapshot of a system that can be used to deploy new instances. When a platform team publishes approved secure base images to an internal registry and enforces them, those base images are the golden images.

Can one secure base image serve both development and production builds?

Yes, when the base comes in two variants: a full variant with a shell and package manager for development and debugging, and a distroless variant for production, so teams build against the same distribution and patch state in both. RapidFort Images are available as distroless and full images, with up to 99.9% CVE elimination across both.

How many base images should an organization standardize on?

As few as the applications allow: one per distribution family and language runtime your services need. Each additional base is another image to patch, rebuild, test and enforce, and the admission policy grows with it. Start by counting the distinct FROM lines across your repositories; that number is the size of the problem.

Can I keep using an end-of-life distribution version?

End-of-life versions of RapidFort Images can be supported on request; patching covers the open source packages when an upstream fix can be backported.

How do I enforce approved base images in Kubernetes?

Run a policy engine as an admission controller. Kyverno and OPA Gatekeeper both evaluate workloads before they are admitted and can reject images from registries other than your approved one; Kyverno can also reject images without a valid signature, and Gatekeeper can do so through an external data provider.