CIS benchmarks were built for persistent, long-lived systems. Containers are neither.
This post explains how CIS benchmarks apply to container images, where the guidance holds, where it does not, and what practical CIS alignment for container images actually looks like.
The Center for Internet Security (CIS) publishes consensus-based configuration guidelines for operating systems, cloud platforms, and software. These benchmarks define specific, testable controls like: disable unused services, enforce file permissions, and configure audit logging. They're organized by severity and implementation difficulty.
These benchmarks are widely trusted, because they're developed through a community process involving security professionals, vendors, and government agencies. They're recognized across enterprise risk programs, regulatory frameworks, and government procurement.
A CIS hardened image is a container image that has been built and configured in alignment with the relevant CIS benchmark, with unnecessary packages removed, permissions locked down, and known vulnerabilities addressed before deployment.
If your organization undergoes a security audit, participates in SOC 2 or FedRAMP programs, or sells to enterprise customers with formal vendor security assessments, CIS compliance will appear somewhere in that process. CIS images and the benchmarks behind them are an agreed-upon starting point for what "reasonably hardened" means.
CIS benchmarks are organized into two implementation levels, and understanding the difference matters when deciding how to harden a container image.
CIS Level 1 defines a baseline set of controls that are broadly applicable, low-risk to implement, and unlikely to interfere with normal system operation. For most container images, CIS Level 1 is the starting point: it covers the configurations that should be in place across virtually every workload.
CIS Level 2 goes further. It applies to environments with stricter security requirements and includes controls that may affect performance or require more careful implementation. CIS Level 2 is appropriate for sensitive workloads, regulated industries, or environments where a more aggressive security posture is justified.
In practice, most container hardening starts at CIS Level 1 and applies CIS Level 2 selectively based on the sensitivity of the workload and the requirements of the environment.
Traditional CIS guidance assumes a persistent system. A server is provisioned, hardened, and runs for months or years. Containers break this model in three ways.
Containers are short-lived. A container image built today may run for minutes or hours before being replaced. CIS hardening must happen at image build time, not at runtime.
You don't log into a running container to apply a fix. You rebuild the image, push it through a pipeline, and redeploy. CIS compliance controls need to live in the build process.
Containers share the host OS kernel. Many CIS configuration controls around kernel hardening and OS-level settings apply at the host or Kubernetes node level, not at the container image level. Responsibility for those controls shifts to the platform or infrastructure team.
A container image team cannot satisfy all CIS controls on their own. Some controls belong to the image, some to the runtime configuration, and some to the underlying node or cluster. Achieving a strong CIS baseline requires a clear separation between all three layers.
Several categories of CIS guidance either don't apply to containers or require significant reinterpretation.
Controls around service management assume a full OS with a service manager. Minimal container images typically run a single process with no init system, so these controls are either irrelevant or automatically satisfied.
Controls around user account management, password policy, and SSH access assume persistent user accounts. Most CIS images built for production don't run SSH and don't require user accounts in the traditional sense.
Audit logging controls often assume OS-level frameworks like auditd. Container logging is typically handled by the container runtime or a sidecar, not an audit subsystem inside the container.
While these security concerns are different in containerized environments,that doesn’t mean they disappear. They need to be addressed at a different layer of the stack, and your CIS compliance documentation needs to reflect where those controls actually live.
Here’s how several CIS hardening practices apply directly and meaningfully to container images.
CIS benchmarks consistently emphasize removing unnecessary software. In a container context, that means starting from a minimal base image and including only what's required to run your workload.
A Node.js application doesn't need curl, wget, a package manager, or a shell in its production image. Every unnecessary package is an additional attack surface. Using distroless and purpose-built minimal base images, like those from Minimus, is a good way to implement this, because minimal images include only what the application needs to run.
CIS compliance requires that known vulnerabilities be identified and addressed within defined timeframes. For CIS hardened images, that means integrating vulnerability scanning into the build pipeline and treating scan results as blocking criteria, not advisory notifications. An image with critical CVEs in its base OS is not CIS-compliant, regardless of how well it's configured.
CIS guidance on software integrity maps to image signing and provenance. Teams should be able to verify that the image running in production is exactly what was built. Software Bill of Materials (SBOM) generation provides a documented inventory of each image's contents, supporting both vulnerability tracking and audit evidence.
Containers should run as non-root users wherever possible, with file system access limited to what's required. Kubernetes pod security settings and Linux security profiles (seccomp, AppArmor) provide the runtime enforcement layer that complements CIS hardened image baselines.
Even teams that start with a solid CIS baseline find that compliance degrades over time. The causes are predictable, and so are the failure points when teams try to manage them manually.
When different teams pull from different base images, different distributions, different versions, different maintainers, enforcing a consistent CIS baseline becomes impossible.
As applications grow, their dependencies grow. Libraries accumulated at build time bring CVEs with them. Without active dependency management, vulnerability counts tend to increase over time.
If hardening steps are applied by hand, the process doesn't scale and isn't repeatable. Different engineers apply different controls, documentation is inconsistent, and there's no reliable way to verify the state of any given CIS image.
New CVEs are published continuously. Without an automated process to detect when a base image or dependency introduces a new vulnerability, CIS compliance gaps surface during audits rather than normal operations.
CIS compliance evidence should be generated as a byproduct of normal build and deployment operations, not assembled manually before an audit. Assembling audit evidence after the fact produces point-in-time snapshots rather than continuous assurance. It doesn't tell you whether your CIS images are currently running in a compliant state, whether drift has occurred since the last scan, or whether a CVE published this morning has changed your posture. The value comes from using CIS baselines as a continuously maintained foundation, not a periodic certification target.
Minimus images start CIS compliant from day one and make audits easy with automated vulnerability monitoring, built-in SBOM generation, and audit-ready compliance reporting. No manual overhead, no compliance drift. Get a demo to see how Minimus works.
.svg)
.svg)
.svg)
.svg)
