What is container security?

In brief

• NIST SP 800-190 groups container risks by five core components: images, registries, orchestrators, containers and host operating systems.
• Common risks are inherited CVEs in base images, containers running as root, embedded secrets, unverified images, over-permissioned service accounts and runtime drift.
• A container security tool has to do more than report: confirm which findings apply, remove inherited risk, enforce policy at admission, monitor production and produce audit evidence.

Container security is protecting containerized applications across their lifecycle, from the images they are built on to the environments where they run. It covers securing base images and dependencies, scanning and hardening images, controlling registries, enforcing policy at deployment, and monitoring running containers for drift or tampering. NIST SP 800-190, the Application Container Security Guide, analyzes the major risks for five core components of container technologies: images, registries, orchestrators, containers and host operating systems. Because containers are built from shared images and open source components, much of container security is software supply chain security.

What container security covers: the five core components

NIST SP 800-190 names five core components, each with its own countermeasures.

Images

The image is the package: a standardized, immutable bundle of the files, binaries, libraries and configuration needed to run a container. Image security means a trusted base, only the packages the application needs, known vulnerabilities patched, no embedded secrets, and a signature and SBOM so the image can be verified.

Registries

A registry is the centralized service that stores and shares images. Registry security means controlling who can push, serving only approved images to production, and keeping stale images from being reused.

Orchestrators

Kubernetes and similar systems decide what runs where. Orchestrator security means access control, admission policy that admits only approved images, security contexts that prevent root and privilege escalation, and network policy between workloads.

Containers

A container is an isolated process with all of the files it needs to run, and containers on a host share the same kernel. Container security at runtime means least privilege, read-only filesystems, resource limits, and monitoring for processes and changes that were not in the image.

Hosts

Containers share the host kernel, so a kernel or runtime vulnerability on the host affects every container on it (NIST SP 800-190). Host security means a hardened, patched operating system and a current container runtime.

Why containers are hard to secure

There are four reasons. Containers share the host kernel, so isolation is a kernel boundary rather than a hardware one, and container escapes are a documented class of vulnerability (NIST SP 800-190). Images inherit everything in their base image, including its vulnerabilities, before any application code is added. Images are reused widely, so one vulnerable base travels into every service built on it. And production changes after deployment: new CVEs are disclosed, packages are updated, and unauthorized modifications can occur after an image has passed its original checks. For threats at runtime, NIST SP 800-190 recommends container-aware runtime defense tools: a dedicated container security solution capable of preventing, detecting and responding to threats aimed at containers during runtime.

Six common container security risks

Each of the six below maps to risks that NIST SP 800-190 describes, such as image vulnerabilities, embedded clear text secrets, use of untrusted images and unbounded administrative access.

1. Vulnerable base images, which carry inherited CVEs into every workload.
2. Misconfiguration: containers running as root, with unnecessary capabilities, writable filesystems or no resource limits.
3. Excessive privilege at the orchestrator, such as broad service account permissions.
4. Secrets embedded in images or environment variables.
5. Unverified images pulled from public registries without signature or provenance checks.
6. And runtime drift, where a running container no longer matches the image it started from because packages were updated or files were changed.

Containers vs virtual machines: which is more secure?

They draw the boundary in different places, and NIST SP 800-190 states that the level of isolation provided by container runtimes is not as high as that provided by hypervisors. A virtual machine has its own kernel, so the isolation boundary is the hypervisor. A container shares the host kernel, so isolation relies on kernel namespaces, with control groups limiting resources, and a kernel vulnerability affects every container on the host. Containers are replaced rather than changed in place: NIST SP 800-190 says updates are made upstream in the images, which are then redeployed. The practical answer is to harden both layers: the host and the image.

Container security best practices

1. Start every service from a secure base image on the distribution it is tested on. What are secure base images?
2. Keep images minimal: only the packages the application runs. What is container hardening?
3. Scan on every build and read findings for what applies, not just what is installed; in a study of 927 images, Trivy and Grype disagreed on both the number and the IDs of vulnerabilities in the 865 images that had vulnerabilities (IEEE SCAM 2024).
4. Fix known CVEs on a stated timeline, with a shorter window for vulnerabilities in the CISA Known Exploited Vulnerabilities catalog. To better handle the backlog, prioritize based on BOD 26-04.
5. Run as non-root, drop capabilities, and use read-only filesystems.
6. Keep secrets out of images; inject them at runtime from a secrets manager.
7. Sign images and attach attestations; verify both before deployment.
8. Serve production from a controlled registry and enforce it with an admission controller, such as Kyverno or OPA Gatekeeper.
9. Apply network policy between workloads and limit what each container can reach.
10. Monitor running containers for new vulnerability disclosures, drift and tampering, and keep audit evidence current.

What a container security tool must do

A container security tool has six jobs, in lifecycle order. Scan images across pipelines, registries and clusters and produce an SBOM. Confirm which findings apply, separating vulnerabilities in code that runs from vulnerabilities in packages that are installed but never execute. Eliminate risk rather than only report it: replace vulnerable bases and remove unused components. Enforce policy at admission. Monitor production for new disclosures, drift and tampering. And compile the evidence auditors ask for against the benchmarks they ask about. A tool that only reports leaves the backlog where it was.

How RapidFort covers container security end to end

RapidFort is one end-to-end platform across three stages, Intake, Build and Runtime, with no gaps between them. At Intake, risk is eliminated before entry with drop-in RapidFort Images and malware-scanned open source libraries from RapidFort Curated Libraries. At Build, RapidFort Analyzer creates an SBOM and confirms whether a vulnerability truly applies to the image, RapidFort Optimizer removes unused components to reduce CVEs and attack surface without code changes. RapidFort Profiler generates an RBOM® showing what actually runs, identifying the real attack surface. At Runtime, environments are continuously monitored and protected, with drift detection, RapidFort Continuous Compliance can help you prioritize your CVE backlog using BOD 26-04 live clocks, and RapidFort CART compiles security benchmarks into audit-ready evidence for ATO, NIST, FedRAMP and CMMC.

The result is up to 99.9% CVE elimination and up to 90% attack surface reduction, without code changes, operating system changes or pipeline modifications: CVEs are removed from your stack, not added to a backlog.

Frequently asked questions