What is container image security?

In brief

• Image risk enters at three points: the base image and its operating system packages, the dependencies the application adds, and the build and distribution path where an image can be substituted or tampered with.
• Seven steps secure an image: a secure base, only what the application runs, scanning with verification of what applies, signing and provenance, a controlled registry, a stated rebuild cadence, and enforcement at admission.
• Scanning is necessary and has blind spots: it shows what is installed rather than what runs, it can misreport backported fixes, and two scanners can disagree on the same image. Pair it with an SBOM, VEX and runtime evidence.

Container image security is the practice of ensuring that the images you build and run are free of known vulnerabilities and malware, come from a verifiable source, and stay that way after they ship. It covers the base image, the packages added on top, the build itself, the registry the image is stored in, and the cadence at which it is rebuilt when new vulnerabilities are disclosed. Image security is the part of container security that happens before a container runs. What is container security?

What is inside a container image, and where its risk comes from

A container image is a standardized package that includes all of the files, binaries, libraries and configurations to run a container, and it cannot be modified once created. It is built in layers, starting from the base image named in the Dockerfile's FROM instruction. Risk enters at three points: the base image and its operating system packages, which carry inherited CVEs; the dependencies the application adds, which can carry vulnerabilities or malicious code; and the build and distribution path, where an image can be substituted or tampered with if it is not signed and pinned.

Image security and container security cover different components

Image security is about the artifact; container security is about the artifact plus everything around it at runtime. NIST SP 800-190 analyzes major risks for the core components of container technologies as image, registry, orchestrator, container and host OS risks. A secure image can still be run insecurely, as root with a writable filesystem and broad permissions, and a well-configured container built from a vulnerable image is still vulnerable. Both are needed; image security comes first in the lifecycle.

How to secure a container image: seven steps

1. Choose a secure base image

Start from a maintained base on the distribution your application is tested on, with few or no known vulnerabilities and a published patch window. What are secure base images?

2. Add only what the application runs

Use multi-stage builds, leave build tools out of the final image, and prefer a distroless variant where no shell or package manager is needed. How to harden a container image?

3. Scan, and verify what applies

Scan every build. Then separate findings in code that executes from findings in packages that are installed but never run; both are real, but they carry different exploitability. Scanners also disagree: a study of 927 Docker images presented at IEEE SCAM 2024 found that, among the 865 images with vulnerabilities, Trivy and Grype disagreed on both the number of vulnerabilities and the vulnerability IDs.

4. Sign the image and record provenance

Sign images so consumers can verify who produced them and that they have not changed. Sigstore records signatures in a tamper-resistant public log, and Cosign signs OCI containers and other artifacts. Provenance, in SLSA's definition, is an attestation describing how the outputs were produced. Signing proves origin and integrity; it does not show whether the image is free of vulnerabilities.

5. Store in a controlled registry

Serve production from a registry you control, and allow only images from a trusted set to run. Prune stale and vulnerable images from the registry so they are not reused.

6. Rebuild and repatch on a stated cadence

An image that passes scanning today can fail tomorrow, as new CVEs are disclosed in its packages. Rebuild when a security patch lands, and know the patch window of whoever maintains your base: the severity tiers, the time unit, when the clock starts, and whether there is a separate window for vulnerabilities in the CISA Known Exploited Vulnerabilities catalog. What is a near-zero CVE image?

7. Enforce at admission

Use a Kubernetes admission controller to reject images that are unsigned, come from an unapproved registry, or fail policy. Kyverno, a policy engine that can enforce policies as a Kubernetes admission controller, checks image signatures with verifyImages rules. OPA Gatekeeper, an admission webhook that enforces Open Policy Agent policies, can require images to come from a list of allowed repositories and checks signatures through an external data provider.

What container image scanning misses

Container image scanning inspects an image to inventory its packages and check them against known vulnerabilities, malware or misconfiguration. It is necessary and it has three blind spots. It shows what is installed, not what runs, so results include CVEs in code the application never executes. It can misreport backported fixes: a scanner matching on version strings may flag a patched package as vulnerable. And its results depend on its vulnerability database, which is one reason two scanners can disagree on the same image. The remedy is to pair scanning with an SBOM, VEX statements that record whether each finding applies, and runtime evidence of what executes.

Prioritizing image vulnerabilities

Prioritize with four signals, then reduce the backlog by removing rather than ranking. CVSS, from FIRST, scores severity from 0.0 to 10.0. EPSS, also from FIRST, estimates the probability that a CVE will be exploited in the wild in the next 30 days. The CISA KEV catalog lists vulnerabilities with reliable evidence of active exploitation. KEV entries added since CISA issued Binding Operational Directive 26-04 on June 10, 2026 carry federal due dates of 3 or 14 days. Runtime evidence shows whether the vulnerable code executes in your workload. Prioritization focuses effort, but the backlog stays until vulnerabilities are fixed or the components carrying them are removed.

How RapidFort secures container images

RapidFort addresses the base image, what the image contains, scanning, and the patch window. The base: RapidFort Images give workloads near-zero CVEs from day one, on all major LTS releases of Ubuntu, Debian and Red Hat, plus Alpine, manually patched and rebuilt by RapidFort engineers, with up to 99.9% CVE elimination across distroless and full images. Patch windows: CISA KEV 1 day, Critical and High 7 days, Moderate 21 days, Low 28 days, from when a patch is available.

Scanning and what applies: RapidFort Analyzer scans container images across CI/CD pipelines, registries and Kubernetes environments, enumerates all files, packages and configurations within container images, not just those reported by package managers, confirms whether a vulnerability truly applies to the image, and exports SBOMs in SPDX, CycloneDX, JSON and CSV. RapidFort Profiler generates an RBOM®, a continuously updated record of components actually executed during runtime, and distinguishes active code paths from dormant layers to reduce vulnerability triage noise. Removal: RapidFort Optimizer uses RBOM® runtime intelligence to identify components that never execute and safely remove them while preserving application functionality. Lastly, RapidFort Runtime continuously tracks what is running in production, detects what changes, and identifies and addresses new risks before they become incidents.

Frequently asked questions