CIS Container Image Hardening¶
Overview¶
The Center for Internet Security (CIS) is a non-profit organization dedicated to improving global cybersecurity resilience. Through its CIS Controls and CIS Benchmarks, the organization provides practical, consensus-based guidance for securing modern IT systems, including containerized workloads.
The CIS Docker Benchmark defines security best practices for container images, build processes, and runtime configuration. These recommendations focus on reducing attack surface, preventing misconfiguration, and improving operational security through defense-in-depth.
Our container images and deployment configuration follow the relevant CIS Docker Benchmark recommendations applicable to container image creation, build pipelines, and runtime configuration.
The goal is not a theoretical checklist, but a practical, auditable, and continuously enforced hardening baseline suitable for production environments.
Scope and Applicability¶
This documentation covers:
- Container image build hardening
- Secure handling of secrets
- Supply chain integrity controls
- Container runtime configuration
- Operational guardrails enforced at deployment time
Out of scope:
- Host operating system hardening
- Kubernetes cluster-level CIS benchmarks
- Network perimeter security controls
Image Hardening and Build Controls¶
Our images are built following CIS Docker Benchmark Section 4 recommendations applicable to container images and Dockerfiles.
Implemented Controls¶
| ID | Description | Implementation |
|---|---|---|
| 4.4 | Ensure images are scanned and rebuilt to include security patches | Images are rebuilt regularly and scanned in CI using automated vulnerability scanners. Each release includes cryptographically verifiable security attestations documenting the build process, scan results, and applied security controls. |
| 4.5 | Ensure Content Trust for Docker is enabled | Images are cryptographically signed and verified during the release process. |
| 4.8 | Ensure setuid and setgid permissions are removed | No unnecessary SUID/SGID binaries are present; findings are explicitly reviewed. |
| 4.9 | Ensure COPY is used instead of ADD in Dockerfiles | Dockerfiles exclusively use COPY for predictable and auditable file inclusion. |
| 4.10 | Ensure secrets are not stored in Dockerfiles | No secrets are embedded in images or Dockerfiles. Secrets are injected at runtime. |
| 4.11 | Ensure only verified packages are installed | Only required packages are installed during build. Package managers, network utilities (such as curl or wget), debugging tools, and other non-essential binaries are removed from runtime images to reduce attack surface and prevent misuse.. |
| 4.12 | Ensure all signed artifacts are validated | Image signatures and SBOMs are validated as part of the supply chain controls. |
Secrets Management¶
Secrets are handled according to the principle of least exposure.
- Secrets are never embedded in container images
- Secrets are not stored in Dockerfiles
- Secrets are not persisted in writable application directories
- Secrets are injected at runtime using file-based secret mounts
- Application configuration references secrets via explicit
*_FILEpaths
This approach reduces accidental disclosure via logs, environment dumps, or debugging tools and aligns with CIS recommendations for sensitive data handling.
Container Runtime Configuration¶
At runtime, containers are deployed with restrictive defaults in accordance with CIS Docker Benchmark Section 5.
Implemented Controls¶
| ID | Description | Implementation |
|---|---|---|
| 5.4 | Ensure Linux kernel capabilities are restricted | All capabilities are dropped by default; only explicitly required ones may be added. |
| 5.5 | Ensure privileged containers are not used | Containers are never started in privileged mode. |
| 5.6 | Ensure sensitive host directories are not mounted | No sensitive host paths are mounted into containers. |
| 5.7 | Ensure sshd is not run within containers | No SSH daemon or remote login service is included in any image. |
| 5.8 | Ensure privileged ports are not mapped | Containers do not bind privileged ports unless explicitly required and justified. |
| 5.9 | Ensure only needed ports are open | Only required application ports are exposed. |
| 5.10 | Ensure the host’s network namespace is not shared | Host networking is not used. |
| 5.11 | Ensure container memory usage is limited | Memory limits are explicitly defined at deployment time. |
| 5.12 | Ensure CPU priority is set appropriately | CPU limits and quotas are configured per service. |
| 5.13 | Ensure the container’s root filesystem is read-only | Root filesystem is mounted read-only with explicit tmpfs mounts for writable paths. |
| 5.16 | Ensure the host’s process namespace is not shared | Containers run in isolated PID namespaces. |
| 5.17 | Ensure the host’s IPC namespace is not shared | Containers run in isolated IPC namespaces. |
| 5.18 | Ensure host devices are not exposed | No host devices are passed through to containers. |
| 5.20 | Ensure mount propagation mode is not shared | Shared mount propagation is not used. |
| 5.21 | Ensure the host’s UTS namespace is not shared | Containers do not share host UTS namespace. |
| 5.22 | Ensure the default seccomp profile is not disabled | Default Docker seccomp profile is enforced. |
| 5.26 | Ensure containers cannot acquire additional privileges | no-new-privileges is enabled for all containers. |
| 5.32 | Ensure the Docker socket is not mounted | Docker socket is never mounted into containers. |
Non-Root Execution Model¶
- All application containers run as non-root users
- File permissions are explicitly set during build
- Writable paths are restricted to explicitly defined directories
- Root filesystem is immutable at runtime
This significantly reduces the impact of potential application-level vulnerabilities.
Continuous Verification¶
Compliance is continuously validated through:
- Automated image hardening scans
- Configuration policy checks during CI/CD
- Reproducible builds with SBOM generation
- Signed and verifiable release artifacts
- Documented exceptions with explicit justification where applicable
Compliance Statement¶
Our container images and runtime configuration are designed to meet the relevant CIS Docker Benchmark recommendations applicable to container image hardening and runtime configuration.
Compliance is achieved through technical enforcement, automated verification, and documented operational practices, rather than manual or one-time assessments.
Disclaimer¶
CIS compliance depends on the full deployment context, including host configuration and orchestration platform settings. This document describes the controls implemented within the container image and its intended runtime configuration.